• Unraid OS version 6.9.0-beta1 available


    limetech

    Welcome to 6.9 beta release development!

     

    This initial -beta1 release is exactly the same code set of 6.8.3 except that the Linux kernel has been updated to 5.5.8 (latest stable as of this date).  We have only done basic testing on this release; normally we would not release 'beta' code but some users require the hardware support offered by the latest kernel along with security updates added into 6.8.

     

    Important: Beta code is not fully tested and not feature-complete.  We recommend running on test servers only!

     

    Unfortunately none of our out-of-tree drivers will build with this kernel.  Some were reverted back to in-tree version, some were omitted.  We anticipate that by the time 6.9 enters 'rc' phase, we'll be on the 5.6 kernel and hopefully some of these out-of-tree drivers will be restored.

     

    We will be phasing in some new features, improvements, and changes to address certain bugs over the coming weeks - these will all be -beta releases.  Don't be surprised if you see a jump in the beta number, some releases will be private.

     

    Version 6.9.0-beta1 2020-03-06

    Linux kernel:

    • version 5.5.8
    • igb: in-tree
    • ixgbe: in-tree
    • r8125: in-tree
    • r750: (removed)
    • rr3740a: (removed)
    • tn40xx: (removed)
    • Like 10
    • Thanks 3



    User Feedback

    Recommended Comments



    Hi I had a complete lockup last night. I have been making changes to the system so will detail what I can.

     

    Yesterday I replaced 1 disk for a larger one. Process was pretty standard, stopped all dockers/vm's.

    Shutdown unraid.

    Changed disk.

    Started unraid - assigned replacement.

    Waited for rebuild.

    Did a parity check. Was using all my vm's etc while this happened fine through the day. No errors.

    Shutdown unraid again and checked it booted again fine.

    Did another parity check to be safe. No errors again.

     

    Created the boinc-rdp docker to use and assigned it 3GB RAM and 50% CPU.

    I think that was about all the changes I made.

     

    I continued using the vm's and services unraid provides during the day for a few hours and eventually went to sleep. Once I woke up all services were unavailable. Unraid could not be pinged either.

    On the actual console screen it showed error messages that would dump to the screen every few minutes. I could press return and login but nothing happened when I tried to type "shutdown -h now" - it accepted the command and said system is going down now! but nothing actually happened. After a few more minutes of the erros being dumped to the screen I took a photo and had to reset it. (see image).

     

    It has come back up and a parity check is now at 40% with 1 sync error found.

     

    In addition to this crash i also want to remove a disk today from the array. As I replaced a disk yesterday, I dont need this additional disk. I have copied off what was on it already to the replaced drive in the array that had enough capacity to accommodate the replaced disk and this one I want to remove now.

     

    Are the steps as follows? (taken from faq):

    Stop the array by pressing "Stop" on the management interface. Un-assign the drive on the Devices page, then return to the unRAID Main page.

    Stop array

    Select the 'Utils' tab

    Choose "New Config"

    Agree and create a new config

    Reassign all of the drives you wish to keep in the array

    Start the array and let parity rebuild

     

    Got to keep forging ahead despite the crashes huh?

     

    Let me know your thoughts. My fault or unraids? I do abuse the system quite a bit. I dont treat it with the respect of a maiden, I kind of just beat it with a stick until it stops working then try to not batter it so hard until its been stable for a while. I do make a lot of changes to it generally speaking, but it was working fine on the beta until last night when I changed the disk and made the new docker. I believe CPU would have averaged around 60-70% and memory would have been at about 40% all of last night (16GB system). I am now running at 93% RAM and about 80% CPU as I had to spin up a vm to do something and the parity check is running. It hasnt crashed again under this high load.

     

    Happy to hear thoughts on this and advice on removing a disk would help.

     

    P

    UnraidCrash.jpg

    Link to comment
    On 3/18/2020 at 9:18 AM, PeteAsking said:

    Are the steps as follows? (taken from faq):

    Stop the array by pressing "Stop" on the management interface. Un-assign the drive on the Devices page, then return to the unRAID Main page.

    Stop array

    Select the 'Utils' tab

    Choose "New Config"

    Agree and create a new config

    Reassign all of the drives you wish to keep in the array

    Start the array and let parity rebuild

    That sounds like you must be working from an old V5 wiki or something, since the Utils tab is called Tools on V6.

     

    That is still basically the idea, except it will now let you keep your assignments when doing New Config. So keep all your assignments, and then just unassign the single disk you want to remove before starting the array and rebuilding parity.

    • Like 1
    Link to comment

    Cool tnx. Any thoughts on the lockup? I mean currently unraid seems to be "fixing itself" fine so no major harm done.

    Edited by PeteAsking
    Link to comment
    22 minutes ago, PeteAsking said:

    Hi I had a complete lockup last night. I have been making changes to the system so will detail what I can.

    Also, your report doesn't exactly follow the guidelines here:

     

    https://forums.unraid.net/bug-reports/prereleases/how-to-install-prereleases-and-report-bugs-r8/

     

    In particular:

     

    Quote

    Reporting Bugs:

    • Please only report bugs/issues that are unique to the prerelease.
    • Important: if possible, please include information that describes how to reproduce the bug/issue.
    • Please visit Tools/Diagnostics and attach the diagnostics.zip file to your post.

     

    Some people have reported lockups when trying to get their BOINC docker tuned just right. Does it lockup if you don't run that docker?

    • Like 1
    Link to comment
    3 minutes ago, trurl said:

    Some people have reported lockups when trying to get their BOINC docker tuned just right. Does it lockup if you don't run that docker?

    Oh no idea. I have never run it before yesterday. I dont even know if it is a bug with unraid beta or not thats kind of why Im asking. Also since I had to reset any logs are lost as its all run from RAM. I couldnt access anything so no way to get any logs.

    Edited by PeteAsking
    Link to comment

    And another thing at that link:

     

    Quote

    Plugins: A number of issues that can occur on a system could be the result of installed plugins that are not officially supported by Lime Technology.  Issues with plugins should be discussed in their respective forums and not posted here for repair.  If you're using ANY plugins on your system, please reboot in Safe Mode and see if the issue you're having still exists.  If so, post a report, but if not, try adding plugins back one by one until the issue occurs again.  Then report the issue in the relevant plugin thread.

     

    Link to comment

    Hmm, well thats kind of impossible since I use the system so I cant really leave it in safe mode for days just on the off chance it locks up again. Thanks anyway, if what I posted is not useful I will just move onto the next thing. Not every crash reported can be useful I guess. Just life, not really going to lose sleep over it. I will do the disk removal instead of worrying about this :)

     

    If it happens again I will try take a diagnostics right after like you suggest. Cant really do the safe mode thing though.

    Link to comment
    2 minutes ago, PeteAsking said:

    If it happens again I will try take a diagnostics right after like you suggest. Cant really do the safe mode thing though.

    Setup syslog server anyway. If it happens again start a new support thread in General Support.

    • Like 2
    Link to comment

    I ran into this issue as well. I originally thought it was BOINC causing the problem, but I had it happen after I ran a parity check and had turned off BOINC and F@H. So I ended up reverting back to 6.8.3 for now, looking forward to a more stable version in the future!

    Link to comment
    24 minutes ago, eagle470 said:

    I ran into this issue as well. I originally thought it was BOINC causing the problem, but I had it happen after I ran a parity check and had turned off BOINC and F@H. So I ended up reverting back to 6.8.3 for now, looking forward to a more stable version in the future!

    Sorry, but this doesn’t add anything. If you want to test beta versions, you need to be prepared to investigate and put more info to the table.

     

    Simply stating “I have an issue” doesn’t give us anything to work on.

     

    Most instability issues happen due to underlying hardware issues. It is always important to rule this out first.

    Edited by bonienl
    Link to comment

    While I understand that what I reported doesn't help anyone, I have no logs to provide. If I did, I would have given them to you. My machine locked up and became entirely non-responsive and the ONLY thing I could have done was taken a picture with my phone of the cash cart monitor. 

     

    I didn't think about that until I had already reset the system the first time and the second time I was running in GUI mode, so all I would have taken a picture of was the frozen lock screen.

     

    I have logs being written off to the syslog server, but apparently the system locked up so fast no useful information was laid down as the last syslog roll up I had was from the day prior. 

     

    I didn't have a secondary system up and running to capture logs, though that is something I can setup now. 

     

    I'm not trying to be unhelpful, I'm just VERY limited on the information that I have to provide. 

     

    If the kind of reporting that I CAN provide is annoying or undesired, I'll simply stop posting any results at all.

    Link to comment

    For users of the r8168 devices that are testing this - can you comment on network performance? I'm interested in seeing if the in-tree drivers for the 816x devices have improved to usable status or not haha.

    Link to comment

    Found Syslog "shfs: direct_io: 0" always "0", does it ref. "GLOBAL SHARE SETTINGS" direct I/O ?

    Link to comment

    I see from another historic thread, there was discussion around bringing iSCSI Targets to release 6.9

     

    At present I'm limited to another vendors software, since they currently have iSCSI support, however I'm patiently waiting for iSCSI support within Unraid so I can finally make the switch over. Do you guys have a rough timeline/idea of a release date with iSCSI support?

    Link to comment
    On 4/6/2020 at 3:50 PM, eagle470 said:

    I will check, I am running an older motherboard though.

     

    I am still on the latest though. No new patches since September: https://www.asus.com/us/Motherboards/PRIME-X370-PRO/HelpDesk_BIOS/

    I have the same MB and only bad experiences with newer (>4200) BIOS-Versions. They break GPU-passthrough and make random kernel panics happen, like you described.

     

    The problem with GPU-passthrough did not only occur with ASUS-mainboards, see this thread as example:

     

    The last stable BIOS-Version I can use is 4024 -> GPU-passthrough works and my PC is running since December without random crashes.

    I hope the new kernel in 6.9 will let me use a more advanced BIOS, in a few days I will begin testing on a second machine.

     

     

    For you @eagle470 - if you want to try this, you can downgrade your mainboard, but you may brick it.

     

    https://rog.asus.com/forum/showthread.php?99490-Flash-any-most-Asus-motherboard-Bios-in-DOS-with-USB-tutorial-Intel-AMD-roll-back

     

    This is the procedure I used to try all BIOS-versions on my X370-Pro, from 5220 to 4024 which is as I said the "newest stable" version I can use.

    Link to comment
    On 4/7/2020 at 6:09 PM, AlphonseCapone said:

    I have the same MB and only bad experiences with newer (>4200) BIOS-Versions. They break GPU-passthrough and make random kernel panics happen, like you described.

     

    The problem with GPU-passthrough did not only occur with ASUS-mainboards, see this thread as example:

     

    The last stable BIOS-Version I can use is 4024 -> GPU-passthrough works and my PC is running since December without random crashes.

    I hope the new kernel in 6.9 will let me use a more advanced BIOS, in a few days I will begin testing on a second machine.

     

     

    For you @eagle470 - if you want to try this, you can downgrade your mainboard, but you may brick it.

     

    https://rog.asus.com/forum/showthread.php?99490-Flash-any-most-Asus-motherboard-Bios-in-DOS-with-USB-tutorial-Intel-AMD-roll-back

     

    This is the procedure I used to try all BIOS-versions on my X370-Pro, from 5220 to 4024 which is as I said the "newest stable" version I can use.

    Makes me wonder what I wouldn't gain from a motherboard upgrade. But I think I'll wait a while longer. No sense in unnecessarily spending a bunch of money in the middle of all this.

    Link to comment

    Would be possible to have the url for the zip of this release? I need to check which out of tree kernel modules are included before I attempt an update. Thanks!

    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.