• Unraid OS version 6.7.0-rc7 available


    limetech

    Another kernel update, more base package updates, bug fixes.

     

    Version 6.7.0-rc7 2019-04-03

    Base distro:

    • aaa_elflibs: version 15.0
    • curl: version 7.64.1
    • gnutls: version 3.6.7
    • harfbuzz: version 2.4.0
    • icu4c: version 64.1
    • iproute2: version 5.0.0
    • iputils: version 20190324
    • kernel-firmware: version 20190402_67b7579
    • libedit: version 20190324_3.1
    • libssh2: version 1.8.2
    • lsscsi: version 0.30
    • mkfontscale: version 1.2.1
    • nano: version 4.0
    • shadow: version 4.6
    • shared-mime-info: version 1.12
    • sqlite: version 3.27.2
    • talloc: version 2.2.0
    • tdb: version 1.4.0
    • tevent: version 0.10.0
    • wget: version 1.20.2
    • xfsprogs: version 4.20.0

    Linux kernel:

    • version: 4.19.33

    Management:

    • rc.nginx: eliminate unnecessary 10 sec delays
    • webgui: Dashboard: add settings shortcuts
    • webgui: Docker: Add More Info link (docker registry) to context menus
    • webgui: Updated jquery cookie script from 1.3.1 to 1.4.1
    • webgui: Keep status visible for paused array operations



    User Feedback

    Recommended Comments



    Works for me upgrading from 6.6.7  :)


    What I am hoping to test out with the RC is stability for 5 (or worst case scenario 4) gpus (gtx1080s) running on one system with windows 10 VMs.  I was doing some stress testing as I get the VMs really working, I start to see video artifacts (short horizontal white lines randomly on the windows desktop) and then one of the game clients starts to have serious issues rendering the 3d environment. I have done a decent chunk of trouble shooting thinking it was one or two GPUS but turns out they seem fine. Some more google searches turn up that people setting the VM to use Q35 resolves issues.  So with this update i'll try not to modify anything, then switch things to Q35 and I'll report my findings to the thread linked below, in an attempt to also respond back to jonp's request for feedback: "Feedback is critical here.  We are seriously considering removing the option to select Q35 for Windows-based VMs from VM manager.  If you can provide a use-case for why we shouldn't, please do!!"

     

    Link to comment

    Actually one thing problem I am having, I cannot passthrough my unraid gpu to a VM. In the past all I needed to do was specify a (hex edited ala SpaceInvaderOne) GPU bios dump and it would work. Now I am getting that classic "first pinned cpu maxes out at 100%" freeze and have to force stop the VM.  I did try some rudimentary trouble shooting, but I'll check the prior RC threads to see if it has been covered before.  I am attaching a diag zip.

    rc7_cannot_passthough_unraid_gpu.zip

    Link to comment
    3 minutes ago, interwebtech said:

    I get this far and it halts. No errors on console. Tried 3 times from Tools | Update OS.

    When I update, it always pauses at this point for (what seems to be) a substantial period of time.  Did you wait a couple of minutes to see if it would actually continue?

    • Upvote 1
    Link to comment
    2 minutes ago, Frank1940 said:

    When I update, it always pauses at this point for (what seems to be) a substantial period of time.  Did you wait a couple of minutes to see if it would actually continue?

    I will try leaving it be. I've never had it pause for a long time that I recall.

    Link to comment
    1 minute ago, interwebtech said:

    I will try leaving it be. I've never had it pause for a long time that I recall.

    I must be very impatient today. lol

     

    Quote

    syncing - please wait...
    Update successful - PLEASE REBOOT YOUR SERVER
    plugin: updated

     

    Link to comment
    1 minute ago, interwebtech said:

    I will try leaving it be. I've never had it pause for a long time that I recall.

    Mine took ~90 seconds right there. I think it was actually syncing but didn't display that until the sync had already completed.

    • Upvote 1
    Link to comment

    If there is any heavy disk activity going on it slows down the sync stage.    I have heard of a running pre-Clear make it take hours :)

    Link to comment
    3 hours ago, interwebtech said:

    I get this far and it halts. No errors on console. Tried 3 times from Tools | Update OS.

    What release did you upgrade from?  The extra delay in this step is due to a change that went into -rc6:

    • fstab: mount USB flash boot device with 'flush' keyword

     

    This tells the vfat file system to be more aggressive in flushing data to the USB flash device, though not fully "synchronous".  This was done to cut down on USB flash device corruption and should not be noticeable in normal operation.

     

    It is odd that the "Syncing - please wait" message did not appear immediately, we'll have to look into that.

    Link to comment
    1 hour ago, limetech said:

    What release did you upgrade from?  The extra delay in this step is due to a change that went into -rc6:

    • fstab: mount USB flash boot device with 'flush' keyword

     

    This tells the vfat file system to be more aggressive in flushing data to the USB flash device, though not fully "synchronous".  This was done to cut down on USB flash device corruption and should not be noticeable in normal operation.

     

    It is odd that the "Syncing - please wait" message did not appear immediately, we'll have to look into that.

    rc6 to rc7

    PS. I make a habit of spinning up all drives before running the upgrade. Speeds up the syncing process.

    Edited by interwebtech
    Link to comment
    2 hours ago, limetech said:

    What release did you upgrade from?  The extra delay in this step is due to a change that went into -rc6:

    • fstab: mount USB flash boot device with 'flush' keyword

     

    This tells the vfat file system to be more aggressive in flushing data to the USB flash device, though not fully "synchronous".  This was done to cut down on USB flash device corruption and should not be noticeable in normal operation.

     

    It is odd that the "Syncing - please wait" message did not appear immediately, we'll have to look into that.

    I observed the same behaviour.   Perhaps the change to that flag makes flushing the data  to the USB drive largely happen before you get to the point of running the explicit 'sync' command?   If so then you probably need a message added to the update process to say that you are transferring the files to the USB drive just before you start doing so?

    Link to comment

    Upgraded from rc6 last night, no issues to report. I also noticed the long pause others have reported, but wouldn't of thought to mention it.

    Link to comment

    My Intel box updated from RC6 to RC7 with no issues. My Threadripper box did not upgrade cleanly from RC5 to RC7.

     

    After it taking 3x as long to reboot as normal, the web admin was still offline. I pinged, got a response, telnetted in and pulled up a tail of the syslog. It looked odd so I copied the syslog to the flash drive and looked at it and I realized the system had not rebooted yet as it still had events from days ago. It looked like it stalled while checking PIDs left on /dev/md* when the only ones left was for the array drives. I executed the "reboot" command and five minutes later I still had no ping response.

     

    After connecting a monitor and forcing a reboot, the system locked up at the UEFI boot menu with only CTRL-ALT-DEL working. I plugged the flash drive into my Win10 machine, it detected errors and prompted me to scan it which I did so. No errors found. Plugged the USB drive back into the NAS and it rebooted without issue.

     

    Attached is the diagnostics from after the reboot. Also attached is the syslog entries from when I clicked the "Check for Update" button on to the last entry. I could not find any new diagnostic file referenced in the 2nd to last line on the root directory of the flash drive.

    nas-diagnostics-20190405-1659.zip

    partial_syslog.txt

    Edited by jbartlett
    Link to comment

    If time permits; I would love if some attention is given to Docker and it's macvlan issues referenced here:

    I'm having similar issues and would love to avoid setting up VLAN for my containers just yet -- at least, would love to know if the issue is with Docker or with unRAID.

     

     

    avnet-un-diagnostics-20190410-0743.zip

    Edited by avluis
    Link to comment
    On 4/6/2019 at 1:19 AM, jbartlett said:

    When pausing a Parity Check, the Dashboard reports "Error code: aborted"

    ... and when resuming, it says "Elapsed time: less than a minute", i.e. keeping the time elapsed only since resumption.

    Link to comment

    Still having the same Problem which I had with RC6. After updating the Server is unable to communicate with the outer world. There are 3 NIC Interfaces. 2 Build-in and 1 10Gbit card direct connection to the PC.

    Strangely the Server now tries to route all traffic thru the 10Gbit interface. If I deactivate and restart the Interface all is well, after rebooting the Server I'm back at the start.

    This is with the 10GBit Interface active:

    Quote

    root@Tower:~# traceroute github.com

    traceroute to github.com (192.30.253.112), 30 hops max, 60 byte packets

    1  unraid.xxxxxx.me (10.0.0.1)  3072.020 ms !H  3072.009 ms !H  3072.004 ms !H

    and here when I have restarted the Interface:

    Quote

    root@Tower:~# traceroute github.com

    traceroute to github.com (192.30.253.113), 30 hops max, 60 byte packets

    1  UniFiSecurityGateway3P (192.168.1.1)  0.485 ms  0.543 ms  0.709 ms

    tried to completely remove and reconfigure the 10GBit interface, no change

    Link to comment

    post your diagnostics after reboot (with the fail situation).

    Also include the output of

    ip route

    My suspicion is the metric value of the default gateway set on the 10G is lowest and gets selected.

    You can either:

    1. Remove the default gateway setting for the 10G link (preferred)
    2. Raise the metric value for the 10G link and make it the highest
    Edited by bonienl
    Link to comment

    Upgraded directly from 6.6.6 with no issues. Been running ~4 days no issues, Ryzen 1700 + Asus Crosshair mobo. 

    Link to comment

    I've also discovered the CA plugin is no longer working properly due to DNS. Neither was speedtest.net.

     

    I've rolled back to 6.6.7 at this point.2068398048_2019-04-1011_56_59-Window.thumb.png.a795804e5b4aa8c1baf77680d47200f0.png

    Link to comment
    14 minutes ago, eagle470 said:

    I've also discovered the CA plugin is no longer working properly due to DNS. Neither was speedtest.net.

     

    I've rolled back to 6.6.7 at this point.

    Works fine here, 2 systems upgraded with no such issues.

    Link to comment
    1 hour ago, eagle470 said:

    I've also discovered the CA plugin is no longer working properly due to DNS. Neither was speedtest.net.

     

    I've rolled back to 6.6.7 at this point.2068398048_2019-04-1011_56_59-Window.thumb.png.a795804e5b4aa8c1baf77680d47200f0.png

    Did you try what was suggested?

    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.