• Unraid OS version 6.7.0-rc6 available


    limetech

    Lots of base package updates, other fixes.  Hopefully one of the last -rc's before stable release.

     

    Version 6.7.0-rc6 2019-03-25

    Base distro:

    • adwaita-icon-theme: version 3.32.0
    • at-spi2-atk: version 2.32.0
    • at-spi2-core: version 2.32.0
    • atk: version 2.32.0
    • bash: version 5.0.003
    • ca-certificates: version 20190308
    • coreutils: version 8.31
    • curl: version 7.64.0 (CVE-2019-8907, CVE-2019-3822, CVE-2019-3823)
    • dhcpcd: version 7.1.1
    • dnsmasq: version 2.80
    • docker: version 18.09.3
    • e2fsprogs: version 1.45.0
    • ethtool: version 5.0
    • file: version 5.36 (CVE-2019-8906, CVE-2019-8907)
    • freetype: version 2.10.0
    • git: version 2.21.0
    • glib2: version 2.60.0
    • glibc: version 2.29
    • glibc-solibs: version 2.29
    • glibc-zoneinfo: version 2018i-noarch-1
    • gnutls: version 3.6.6
    • gtk+3: version 3.24.7
    • infozip: version 6.0 (CVE-2014-8139, CVE-2014-8140, CVE-2014-8141, CVE-2016-9844, CVE-2018-18384, CVE-2018-1000035)
    • iproute2: version 4.20.0
    • iputils: version 20180629
    • jemalloc: version 4.5.0
    • jq: version 1.6 (rev2)
    • kernel-firmware: version 20190314_7bc2464
    • kmod: version 26
    • libaio: version 0.3.112
    • libcap-ng: version 0.7.9
    • libgpg-error: version 1.36
    • libjpeg-turbo: version 2.0.2
    • libpsl: version 0.20.2
    • libssh2: version 1.8.1 (CVE-2019-3855, CVE-2019-3856, CVE-2019-3857, CVE-2019-3858, CVE-2019-3859, CVE-2019-3860, CVE-2019-3861, CVE-2019-3862, CVE-2019-3863)
    • libvirt: version 5.1.0
    • libwebp: version 1.0.2
    • libwebsockets: version 3.1.0
    • libxkbfile: version 1.1.0
    • libxml2: version 2.9.9
    • libxslt: version 1.1.33
    • libzip: version 1.5.2
    • libXcomposite: version 0.4.5
    • libXcursor: version 1.2.0
    • libXdamage: version 1.1.5
    • libXdmcp: version 1.1.3
    • libXext: version 1.3.4
    • libXft: version 2.3.3
    • libXmu: version 1.1.3
    • libXrandr: version 1.5.2
    • libXxf86dga: version 1.1.5
    • lvm2: version 2.02.177
    • lzip: version 1.21
    • mcelog: version 162
    • mozilla-firefox: version 66.0 (CVE-2018-18500, CVE-2018-18504, CVE-2018-18505, CVE-2018-18503, CVE-2018-18506, CVE-2018-18502, CVE-2018-18501, CVE-2018-18356, CVE-2019-5785, CVE-2018-18511, CVE-2019-9790, CVE-2019-9791, CVE-2019-9792, CVE-2019-9793, CVE-2019-9794, CVE-2019-9795, CVE-2019-9796, CVE-2019-9797, CVE-2019-9798, CVE-2019-9799, CVE-2019-9801, CVE-2019-9802, CVE-2019-9803, CVE-2019-9804, CVE-2019-9805, CVE-2019-9806, CVE-2019-9807, CVE-2019-9809, CVE-2019-9808, CVE-2019-9789, CVE-2019-9788)
    • mpfr: version 4.0.2
    • ncompress: version 4.2.4.5
    • ncurses: version 6.1_20190223
    • nghttp2: version 1.37.0
    • ntp: version 4.2.8p13 (CVE-2019-8936)
    • oniguruma: version 6.9.1 (CVE-2017-9224, CVE-2017-9225, CVE-2017-9226, CVE-2017-9227, CVE-2017-9228, CVE-2017-9229)
    • openssl: version 1.1.1b (CVE-2019-1559)
    • openssl-solibs: version 1.1.1b (CVE-2019-1559)
    • p11-kit: version 0.23.15
    • pcre: version 8.43
    • php: version 7.2.15
    • pixman: version 0.38.0
    • rsyslog: version 8.1903.0
    • sqlite: version 3.27.2
    • sudo: version 1.8.27
    • sysvinit: version 2.94
    • sysvinit-scripts: version 2.1-noarch-26
    • talloc: version 2.1.16
    • tar: version 1.32
    • tdb: version 1.3.18
    • tevent: version 0.9.39
    • ttyd: version 20190223
    • util-linux: version 2.33.1
    • wget: version 1.20.1
    • xprop: version 1.2.4
    • xtrans: version 1.4.0

    Linux kernel:

    • version: 4.19.31
    • CONFIG_X86_MCELOG_LEGACY: Support for deprecated /dev/mcelog character device
    • OOT Intel 10Gbps network driver: ixgbe: version 5.5.5

    Management:

    • fstab: mount USB flash boot device with 'flush' keyword
    • rc.sshd: only copy new key files to USB flash boot device
    • rc.nginx: implement better status wait loop - thanks ljm42
    • smartmontools: update drivedb and hwdata/{pci.ids,usb.ids,oui.txt,manuf.txt}
    • webgui: Per Device Font Size Setting
    • webgui: Syslog: add '' entry in local folder selection
    • webgui: Syslog: included rsyslog.d conf files and chmod 0666
    • webgui: Syslog: added log rotation settings
    • webgui: Open link under Unraid logo in new window
    • webgui: Use cookie for display setting font size
    • webgui: prevent dashboard bar animations from queuing up on inactive browser tab
    • webgui: Replace string "OS X" with "macOS"
    • webgui: Updated Unraid icons
    • webgui: Switch plugins to a compressed download
    • Like 2
    • Upvote 1



    User Feedback

    Recommended Comments



    1 hour ago, cybrnook said:

    Today, however, I went into the basement and noticed that the display was in sleep mode.

    There was a small change introduced in a package update that set the console to blank after 15 min and then poweroff after 60 min of inactivity.  Maybe this is what you are seeing.

    • Upvote 1
    Link to comment
    1 hour ago, limetech said:

    There was a small change introduced in a package update that set the console to blank after 15 min and then poweroff after 60 min of inactivity.  Maybe this is what you are seeing.

    That sounds like it would be exactly it. Is there anything I can do to disable/adjust this? If it goes to sleep, can I just tap the keyboard to wake up?

    Link to comment
    8 hours ago, mrbilky said:

    I may have spoke to soon for the 6.7.0 rc6 update I started having issues with dockers updating so I looked at fix common problems and it was complaining of these issues

    image.thumb.png.2743e7b220462bcf1613152541f0506f.pngScreen Shot 2019-03-27 at 6.32.29 PM

     

    so I rolled back to 6.7.0 rc5 and all seem to be good I updated dockers with no problem and FCP found no issue so I captured diags of before and after for those good at reading the tea leaves anyone else having anything like this? It actually affected Plex updating metadata thought that was weird I went so far as resetting my router but that was no help only rolling back corrected it

     

    homenas-diagnostics-20190327-2221.zip

    homenas-diagnostics-20190327-2228.zip

     

    I had the exact same happen yesterday. The fix common problems plugin reported exactly the same. @limetech I usual only have 1 physical nic in use with the standard br0 and virbr0. A couple days ago I had set up a bridge on a second ethernet port without a cable connected and an fixed ip 192.168.0.6/24 No issues on RC5. Dockers worked as usual and no errors in FCP. I only used that new bridge on one single VM for testing but reverted back to br0. I forgot to remove the br2 again. On RC6 yesterday I tried to ping 1.1.1.1 from the console and the the target couldn't be reached. Unraid tried to connect to the internet via that second port I had configured. "192.168.0.1 no answer" I removed the bridge and all went back to normal. 

    Link to comment

    Update from rc5 to rc6 went smoothly and no anomalous behaviour noted so far after the upgrade.

    Link to comment

    I'm having the exact same issue. After updating to RC6 the Server is unable to communicate with the outer world. Reverted back to RC5 all good again.

    Link to comment

    I wonder if the time out changes happened in Unraid or are being screwed up due to old plugins or something.

    Link to comment
    5 hours ago, Higgins12 said:

    I'm having the exact same issue. After updating to RC6 the Server is unable to communicate with the outer world. Reverted back to RC5 all good again.

    I had the same issue on both servers, then i downgraded back to RC5. Eventually I upgraded both servers again to RC6 but I deleted the /boot/config/network.cfg file and rebooted the servers & after that all was working fine.

     

    There was a long list of troubleshooting including reseting my switch & fine tuning my pfsnese.

    Edited by PSYCHOPATHiO
    Link to comment
    9 hours ago, bastl said:

    I had the exact same happen yesterday. The fix common problems plugin reported exactly the same. @limetech I usual only have 1 physical nic in use with the standard br0 and virbr0. A couple days ago I had set up a bridge on a second ethernet port without a cable connected and an fixed ip 192.168.0.6/24 No issues on RC5. Dockers worked as usual and no errors in FCP. I only used that new bridge on one single VM for testing but reverted back to br0. I forgot to remove the br2 again. On RC6 yesterday I tried to ping 1.1.1.1 from the console and the the target couldn't be reached. Unraid tried to connect to the internet via that second port I had configured. "192.168.0.1 no answer" I removed the bridge and all went back to normal. 

    Your network configuration is wrong. Interface eth2 (br2) has the wrong gateway defined.

     

    br0 (correct)

    IPADDR[0]="192.168.1.206"
    NETMASK[0]="255.255.255.0"
    GATEWAY[0]="192.168.1.1"

    br2 (wrong)

    IPADDR[2]="20.20.20.10"
    NETMASK[2]="255.255.255.0"
    GATEWAY[2]="192.168.1.1"

    Restarting the server may have given gateway[2] a lower (better) metric and effectivily blackholing all your internet traffic.

    Link to comment
    6 hours ago, Higgins12 said:

    I'm having the exact same issue. After updating to RC6 the Server is unable to communicate with the outer world. Reverted back to RC5 all good again.

    So how does your network configuration looks like?

    It is very unlikely that rc6 has a network issue. See also my answer above.

     

    Link to comment
    39 minutes ago, PSYCHOPATHiO said:

    I had the same issue on both servers, then i downgraded back to RC5. Eventually I upgraded both servers again to RC6 but I deleted the /boot/config/network.cfg file and rebooted the servers & after that all was working fine.

    Do you still have your original network configuration?

    What is your network setup?

    Link to comment
    7 minutes ago, bonienl said:

    Your network configuration is wrong. Interface eth2 (br2) has the wrong gateway defined.

     

    br0 (correct)

    
    IPADDR[0]="192.168.1.206"
    NETMASK[0]="255.255.255.0"
    GATEWAY[0]="192.168.1.1"

    br2 (wrong)

    
    IPADDR[2]="20.20.20.10"
    NETMASK[2]="255.255.255.0"
    GATEWAY[2]="192.168.1.1"

    Restarting the server may have given gateway[2] a lower (better) metric and effectivily blackholing all your internet traffic.

    I quoted another user and that diagnostics weren't mine. But as the other user before I had a second bridge defined for a second physical nic. That nic I never plugged in a cable or used it for anything than for 2 VMs (Pfsense, Windows) to test if I can use that bridge for the VM to prevent any access to my physical lan and completely separate that Windows VM from Unraids network. Nothing else was set to use br2. I forgot to remove that bridge which caused the above issue. Somehow with RC6 Unraid started routing traffic to that second bridge. Removed it and the FCP hints for wrong DNS settings are gone. 

    Link to comment
    2 hours ago, bonienl said:

    Do you still have your original network configuration?

    What is your network setup?

    1st pfSense box with physical LAN "10.0.0.0/24 and 2 VLANs "10.0.1.0/24" "172.16.1.0/24"

    2nd pfSense box with 1 VPNLAN "10.0.5.0/24"

    L2 Switch with 2 connected pfSense boxes and 3 VLANS in total.

     

    Server 1 has an intel i350 Quad GBe (Balance xor) "LAN" 10.0.0.3 & a built in 1GBe "SLAN" 10.0.1.3

    Server 2 has 2 built in NICs "LAN 10.0.0.4 & "SLAN" 10.0.1.4 

     

    The issue mainly was a mis-configured VPNLAN port that was able to get into the routing table 10.0.5.1 via br0

    Edited by PSYCHOPATHiO
    Link to comment

    I have exact problem.  Networking from the host works locally, but not across a router.  The Virtual machines networking does work fine though.  Only happened after RC6 upgrade.

    Edit - During boot I see that it is complaining it can't find Eth2, which I didn't know existed and certainly doesn't exist according to the GUI.

    Edited by Marshalleq
    Link to comment

    I just followed the example above and deleted the network config, then rebooted, stopped the array, edited the Network Settings, where it lost access because it does that when you edit Unraid network settings on mine every time, then rebooted and it's working.  Oddly, every docker image said it had an update after that, and the update downloaded 0B in ever case.  But otherwise all good.  Glad I didn't have a complicated network setup!

    Link to comment
    2 hours ago, Marshalleq said:

    I just followed the example above and deleted the network config, then rebooted, stopped the array, edited the Network Settings, where it lost access because it does that when you edit Unraid network settings on mine every time, then rebooted and it's working.  Oddly, every docker image said it had an update after that, and the update downloaded 0B in ever case.  But otherwise all good.  Glad I didn't have a complicated network setup!

    This sounds like you had interface "eth2" at some point in time and this was included in the configuration settings, but it was removed later on?

    Can you post your diagnostics.

    Link to comment
    On 3/27/2019 at 10:37 PM, cybrnook said:

    That sounds like it would be exactly it. Is there anything I can do to disable/adjust this? If it goes to sleep, can I just tap the keyboard to wake up?

    Just to confirm, tapping a key on the keyboard does wake the monitor back up.

    Link to comment

    #Kernel Bug#

     

    unRAID kernel: nvme 0000:08:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000d4696000 flags=0x0000]

     

    AMD-Vi: Event logged [IO_PAGE_FAULT device=08:00.0 domain=0x0000 address=0x00000000d4693000 flags=0x0000]

     

    It has filled my log with error's like this.

     

     

    https://bugzilla.kernel.org/show_bug.cgi?id=202665

     

    4.19.32 has the fix.

     

    Will wait for next RC or final.

     

    Should be fixed.

     

    Edited by Dazog
    Link to comment

    Cosmetic issue that I've had before but couldn't work out (it's quite specific)...

     

    • Browser window about 1280px wide
    • On the plugins page
    • Have multiple notifications
    • Have updates to multiple plugins
    • Close each notification one by one until all closed

     

    The notification container (jgrowl?) is still on the page and obscures most of the "update all plugins) button.  Guessing the wrapper div would be on the top right on every page and needs hiding when last notification closed.  Page refresh sorts it.

    Link to comment

    The console font appears to have changed.  In GUI mode with my monitor attached directly to the server, the web interface font is so large I have to reduce the screen to 30% to get the icons to appear for logoff, reboot, etc...

     

    20190330_061234.jpg

    20190330_061249.jpg

    20190330_061303.jpg

    20190330_061320.jpg

    20190330_061406.jpg

    Link to comment
    2 hours ago, RGauld said:

    The console font appears to have changed.  In GUI mode with my monitor attached directly to the server, the web interface font is so large I have to reduce the screen to 30% to get the icons to appear for logoff, reboot, etc...

    webgui: Per Device Font Size Setting

    Each device (including the local) can have it's own font-size set via Display Settings.  Try changing the font-size.

    Link to comment

    Hi all,

     

    I think I have a bit of an odd one.

     

    Once I replaced my faulty usb many of my stability issues went away how ever after updating every so often I seem to loose my shares but every thing else seems to be working.

     

    Ie Dockers seem fine and dispite the attached image I know Emby is running as I am watching it right now.

     

    I can not get the syslog to show any thing (it is a blank page) and diags will not generate.

     

    Any thoughts ie is the the RC or another issue ?

     

    Thanks

     

    T

     

    Edit. Managed to get access to the syslog once I rebooted. That reboot had to be done from the console as it would not work from the web interface.

     

    Crfs uninitialised was in the log towards the end so I will have a look in the forum.

    Screenshot_20190330-192737.png

    Edited by ccsnet
    Link to comment

    was working fine on latest stable (6.6.7)  closed down all of my VMs and containers. ensured mover had finished. backed up flash stopped array and then updated to next 6.7.0-rc6. b

     Better than previous attempts to upgrade, as far as on reboot all drives were detected in correct slots, however on starting array errors everywhere.

     

    log is full of errors:

    Mar 30 23:26:05 TheNewdaleBeast emhttpd: error: get_filesystem_status, 6474: Input/output error (5): scandir
    Mar 30 23:26:05 TheNewdaleBeast kernel: XFS (md2): metadata I/O error in "xfs_trans_read_buf_map" at daddr 0x15d508f48 len 32 error 5
    Mar 30 23:26:05 TheNewdaleBeast kernel: XFS (md2): xfs_imap_to_bp: xfs_trans_read_buf() returned error -5.
    Mar 30 23:26:06 TheNewdaleBeast emhttpd: error: get_filesystem_status, 6474: Input/output error (5): scandir
    Mar 30 23:26:06 TheNewdaleBeast kernel: XFS (md2): metadata I/O error in "xfs_trans_read_buf_map" at daddr 0x15d508f48 len 32 error 5
    Mar 30 23:26:06 TheNewdaleBeast kernel: XFS (md2): xfs_imap_to_bp: xfs_trans_read_buf() returned error -5.
    Mar 30 23:26:07 TheNewdaleBeast emhttpd: error: get_filesystem_status, 6474: Input/output error (5): scandir
    Mar 30 23:26:07 TheNewdaleBeast kernel: XFS (md2): metadata I/O error in "xfs_trans_read_buf_map" at daddr 0x15d508f48 len 32 error 5
    ............................

    screenshot shows five appearing as unmountable (were mounted and functioning with no problem in stable 6.6.7)

     

    also attached is the diagnostics log.

     

    going to revert back again to a functioning system!

    Screenshot 2019-03-30 at 23.30.44.png

    thenewdalebeast-diagnostics-20190330-2333.zip

    Link to comment
    9 hours ago, Duggie264 said:

    screenshot shows five appearing as unmountable

    It's a controller problem:

    Mar 30 23:15:06 TheNewdaleBeast kernel: hpsa 0000:03:00.0: scsi 5:0:2:0: resetting physical  Direct-Access     SEAGATE  ST4000NM0023     PHYS DRV SSDSmartPathCap- En- Exp=1
    Mar 30 23:15:38 TheNewdaleBeast kernel: hpsa 0000:03:00.0: Controller lockup detected: 0x00130001 after 30
    Mar 30 23:15:38 TheNewdaleBeast kernel: hpsa 0000:03:00.0: controller lockup detected: LUN:0000000000800101 CDB:01030000000000000000000000000000
    Mar 30 23:15:38 TheNewdaleBeast kernel: hpsa 0000:03:00.0: Controller lockup detected during reset wait
    Mar 30 23:15:38 TheNewdaleBeast kernel: hpsa 0000:03:00.0: scsi 5:0:2:0: reset physical  failed Direct-Access     SEAGATE  ST4000NM0023     PHYS DRV SSDSmartPathCap- En- Exp=1

    Likely a kernel issue, I believe there were other reports with problems with these HP controllers.

    Link to comment

    Thanks, I just find it strange that I have had no issues under 6.6.7  and below? 

    Now I have reverted, it is all working fine, as it was before the upgrade. 

    Link to comment



    Guest
    This is now closed for further comments

  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.


    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.