• unRAID OS version 6.5.1-rc4 available


    limetech
    • Closed

    Welcome to the new experimental Prerelease Support board!  We have added the ability to tag issues/bugs with a Priority and mark when solved.  Please report only issues/bugs which are new in the prerelease.

     

    Attention Intel 10Gbit Ethernet users: in this release we replaced the linux in-tree kernel drivers (ixgbe/ixgbevf) with the latest available from Intel.  This change should be considered experimental.  That is, for those of you having issues with Intel 10Gbit adapters, please report if this change solves the issues.  Likewise, please report if you have successfully been using an Intel 10Gbit adapter and now you are having issues.  If new problems arise or the old problems are not solved we will revert to in-tree drivers in the next release.

     

    Version 6.5.1-rc4 2018-04-06

    Summary:

    • Security updates, bug fixes and UI improvements.

    Linux kernel:

    • version 4.14.32
    • out-of-tree drivers:
      • intel ixgbe: version 5.3.6
      • intel ixgbevf: version 4.3.4

    Management:

    • emhttp: fix possible divide by zero error in cacluating cpustats
    • update smartmontools drivedb and hwdata/{pci.ids,usb.ids,oui.txt,manuf.txt}
    • webgui: Fixed DockerCreate regression error
    • webgui: Docker: optimized URL caching
    • webgui: Docker settings: improved IP format checking
    • webgui: Fixed ContainerManager regression error
    • webgui: Make "bridge" first network choice in new container creation
    • webgui: Added warning when system notifications are disabled
    • webgui: Hide settings when interface is member of a bond or bridge
      • Bond/bridge membership is shown before interface state
    • webgui: Fixed orphan images not shown when no containers defined
    • webgui: Fixed missing protocol type in container list
    • webgui: Fixed missing .txt extension in SMART report files
    • webgui: Docker enhancements and corrections
      • delete cache files when container is deleted
      • improved handling of user defined networks
      • optimized reading of container and image settings
      • improved handling of container IP address assignment
      • code optimization and consistency
    • webgui: Fixed select color for themes white and black
    • webgui: DockerCreate: show unassigned IP addresses as 0.0.0.0
    • webgui: VM Machines: get rid of the Actions column
    • webgui: VMs: allow SCSI bus type selection for disks and cdroms



    User Feedback

    Recommended Comments

    It appears the new 10Gbit Ethernet driver for intel has broken unraid.

     

    Drops my speeds down to nothing.

     

    Gui is non-responsive.

     

    I am running a  intel x520 single port setup.


    NO issues with previous build.

     

    I tried 2 browsers, chrome and firefox.

     

    Also tried transfering files via SMB and speeds were 40 times slower.

     

    Please revert.

    Edited by Dazog
    • Upvote 1
    Link to comment
    56 minutes ago, Dazog said:

    It appears the new 10Gbit Ethernet driver for intel has broken unraid.

     

     

    I would suggest that you post up your Diagnostics file.  If the GUI and SSH are unavailable then connect up a monitor and keyboard, login , and type diagnostics on the command line.  That will write the diagnostics file in the logs folder/directory on your flash drive.  

    Link to comment
    3 minutes ago, Frank1940 said:

     

    I would suggest that you post up your Diagnostics file.  If the GUI and SSH are unavailable then connect up a monitor and keyboard, login , and type diagnostics on the command line.  That will write the diagnostics file in the logs folder/directory on your flash drive.  

    send to limetech directly.

    Link to comment
    1 hour ago, Dazog said:

    Also tried transfering files via SMB and speeds were 40 times slower.

     

    The out-of-tree driver isn't 40 times slower.

     

    So it's likely to be some option that needs to be tweaked. Possibly some optimization that is default on in the in-tree driver but must be explicitly enabled in the out-of-tree driver.

     

    It's generally better to figure out what option instead of reverting to the in-tree driver, because the out-of-tree driver is most probably the more powerful driver or Intel wouldn't bother investing time with it.

    Edited by pwm
    grammar
    Link to comment
    2 minutes ago, pwm said:

     

    The out-of-tree driver isn't 40 times slower.

     

    So it's likely to be some option that needs to be tweaked. Possibly some optimization that is default on in the in-tree driver but must be explicitly enabled in the out-of-tree driver.

     

    It's generally better to figure out what option instead of reverting to the in-tree driver, because the out-of-tree driver is most probably the power powerful driver or Intel wouldn't bother investing time with it.

     

    I am checking how old my firmware on my x520 is...

     

    Maybe it needs to be updated.

    Link to comment
    10 minutes ago, pwm said:

     

    The out-of-tree driver isn't 40 times slower.

     

    So it's likely to be some option that needs to be tweaked. Possibly some optimization that is default on in the in-tree driver but must be explicitly enabled in the out-of-tree driver.

     

    It's generally better to figure out what option instead of reverting to the in-tree driver, because the out-of-tree driver is most probably the more powerful driver or Intel wouldn't bother investing time with it.

     

    Perhaps that sort of change should be in a BETA release branch that targets this specific change instead?

    Link to comment

    I updated one server in the hope that it would fix this nginx problem but it didn't. I've had the problem since 6.5.0 so it isn't specific to this version and I'm seeing it on all three servers. It's difficult to believe I'm alone but I've received no confirmation that anyone else is affected.

     

    Other than that the update went well.

     

    Link to comment
    19 minutes ago, John_M said:

    I updated one server in the hope that it would fix this nginx problem but it didn't. I've had the problem since 6.5.0 so it isn't specific to this version and I'm seeing it on all three servers. It's difficult to believe I'm alone but I've received no confirmation that anyone else is affected.

     

    Other than that the update went well.

     

    I've got the same problem too. It seems to happen when certain Dockers are running but I'm still trying to work out which ones. I have virtually no idea how to do anything in linux so only the obvious stands out to me. It's only been happening since 6.5.0 from what I can see. I have two seperate servers running 6.5.0 and only one has the memory leakage problem. As of now I have not tried any of the 6.5.1 RC series.

    Link to comment
    4 minutes ago, TheMantis said:

    I've got the same problem too. It seems to happen when certain Dockers are running but I'm still trying to work out which ones. I have virtually no idea how to do anything in linux so only the obvious stands out to me. It's only been happening since 6.5.0 from what I can see. I have two seperate servers running 6.5.0 and only one has the memory leakage problem. As of now I have not tried any of the 6.5.1 RC series.

     

    That's very interesting to hear. I can confirm (with diagnostics) that I got the error messages in Safe Mode (no plugins) and with no Dockers running. But it seems to happen during heavy disk I/O (which is something that certain Dockers are good at creating), such as a parity check, and it takes a while for the error messages to start. So as not to clog up this thread please post your diagnostics in the thread I linked and we can discuss it further there. Maybe other people have the same problem but haven't noticed yet. I see no major side effect other than a massive spamming of the syslog.

    Link to comment
    14 minutes ago, John_M said:

     

    That's very interesting to hear. I can confirm (with diagnostics) that I got the error messages in Safe Mode (no plugins) and with no Dockers running. But it seems to happen during heavy disk I/O (which is something that certain Dockers are good at creating), such as a parity check, and it takes a while for the error messages to start. So as not to clog up this thread please post your diagnostics in the thread I linked and we can discuss it further there. Maybe other people have the same problem but haven't noticed yet. I see no major side effect other than a massive spamming of the syslog.

    I've actually got my wires crossed a bit here: my fault is not the one you linked. The issue that I have is that nginx slowly consumes all available memory over a week or so.

    Link to comment

    Undate without problem, 10G NIC X520 performance have some improve and consistance.

    456.thumb.png.d06c42896d433e4d160f5d72ba0a97ea.png

    Edited by Benson
    Link to comment

    I updated from RC3 to RC4 then told unRAID to reboot, and went to do something else. 10 minutes later, I found the system hung, with no way to access diagnostics. After rebooting manually, everything came back fine, so I guess that is not a real problem. However, since I never saw this before, I thought I'd mention it.

     

    Something else though, now unRAID complains ' System notifications are disabled. Click here to change notification settings. '.

    So, I clicked here, and got to settings, where the help told me ' By default the notifications system is disabled. Enable it here to start receiving notifications.'

    Why am I getting notifications about a notification system that is disabled as default when it is disabled and so I shouldn't be getting notifications?

    In other words, why does unRAID complain about its own default settings?

    tower-diagnostics-20180408-0602.zip

    • Like 2
    Link to comment
    20 minutes ago, Wody said:

    Why am I getting notifications about a notification system that is disabled as default when it is disabled and so I shouldn't be getting notifications?

    In other words, why does unRAID complain about its own default settings?

     

    Virtually all of the longtime users who are active on this forum encourage everyone to turn on the Notification System.  The reason being is that it can alert the user that there are problems with the server before the system deteriorates to the point that data will be lost unless it can be restored from another source.   HOWEVER, Notification requires that the user setup it up with things like E-mail addresses, mail server and other setup information for various other notification services that the user might be setup for.  So, it is necessary that the Notification Service be turned off until these setups are completed.  

    Edited by Frank1940
    Link to comment
    20 minutes ago, Frank1940 said:

     

    Virtually all of the longtime users who are active on this forum encourage everyone to turn on the Notification System.  The reason being is that it can alert the user that there are problems with the server before the system deteriorates to the point that data will be lost unless it can be restored from another source.   HOWEVER, Notification requires that the user setup it up with things like E-mail addresses, mail server and other setup information for various other notification services that the user might be setup for.  So, it is necessary that the Notification Service be turned off until these setups are completed.  

     

    And you really, really want to set this up. I have been asking for a way to get users to notice this feature for a very long time.

     

    Most of the time when we get a user with multiple disk problems, they never set up Notifications because they just didn't know about them. They were running with one problem disk for a while and didn't even know about it until they got another problem disk and so parity couldn't help them anymore.

    • Like 1
    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.