• Unraid OS version 6.7.0-rc3 available


    limetech

    More bug fixes.  More refinements to webGUI, especially check out latest Community Apps plugin!

     

    Other highlights:

    • Parity sync/Data rebuild/Check pause/resume capability.  Main components in place.  Pause/resume not preserved across system restarts yet however.
    • Enhanced syslog capability.  Check out Settings/Nework Services/Syslog Server.

     

    Special thanks once again to @bonienl and @Mex.

     

    Version 6.7.0-rc3 2019-02-09

    Base distro:

    • jq: version 1.6
    • oniguruma: version 5.9.6_p1
    • php: version 7.2.14

    Linux kernel:

    • version: 4.19.20
    • md/unraid: version 2.9.6 (support sync pause/resume)
    • patch: PCI: Quirk Silicon Motion SM2262/SM2263 NVMe controller reset: device 0x126f/0x2263

    Management:

    • emhttp: use mkfs.btrfs defaults for metadata and SSD support
    • emhttp: properly dismiss "Restarting services" message
    • firmware:
    • added BCM20702A0-0a5c-21e8.hcd
    • added BCM20702A1-0a5c-21e8.hcd
    • vfio-pci script: bug fixes
    • webgui: telegram notification agent bug fixes
    • webgui: VM page: allow long VM names
    • webgui: Dashboard: create more space for Dokcer/VM names (3 columns)
    • webgui: Dashboard: include links to settings
    • webgui: Dashboard: fix color consistency
    • webgui: Syslinux config: replace checkbox with radio button
    • webgui: Docker page: single column for CPU/Memory load
    • webgui: Docker: usage memory usage in advanced view
    • webgui: Dashboard: fixed wrong display of memory size
    • webgui: Dashboard: fix incorrect memory type
    • webgui: Plugin manager: align icon size with rest of the GUI
    • webgui: Plugin manager: enlarge readmore height
    • webgui: Plugin manager: add .png option to Icon tag
    • webgui: Plugin manager: table style update
    • webgui: Added syslog server functionality
    • webgui: syslog icon update
    • webgui: Main: make disk identification mono-spaced font
    • webgui: Added parity pause/resume button
    • webgui: Permit configuration of parity device(s) spinup group.
    • Like 6
    • Upvote 1



    User Feedback

    Recommended Comments



    7 minutes ago, Niklas said:

    Yes, i know. I have some deeper understanding when it comes to sectors and how storage devices work. Just not much experience with parity calculation in Unraid. Yet. Found Unraid in nov-oct 2018 and have been reading and watching videos about parity (in unraid) so.. I'm learning as i go. ;)

    Start here:

     

         https://wiki.unraid.net/index.php/UnRAID_Manual_6#WORK_IN_PROGRESS

     

    Section 1.1.1  explains how single parity works.  (Dual parity merely adds a second parity disk in addition to this first single parity disk.  The contents of this second disk requires an advance degree in Mathematics to fully understand!) 

    Link to comment
    5 minutes ago, Frank1940 said:

    Start here:

     

         https://wiki.unraid.net/index.php/UnRAID_Manual_6#WORK_IN_PROGRESS

     

    Section 1.1.1  explains how single parity works.  (Dual parity merely adds a second parity disk in addition to this first single parity disk.  The contents of this second disk requires an advance degree in Mathematics to fully understand!) 

    Thanks for the suggestion. Already ingested that and yes, understanding second parity make my brain hurt. ;)

    Edited by Niklas
    Link to comment
    4 hours ago, SuperTrembler said:

    Anyone had success with TRIM on LSI2308/LSI2008?

    It stopped working for all SSDs without DRAT or DZAT a while back

    It still doesn't work, it does on SAS3 HBAs based on the SAS3008 chipset, only on SSDs with deterministic read after TRIM.

    Link to comment

    Just rebooting my server to rc3.

     

    Just checking this the correct place to bang on about non-functional cosmetic changes now?

    Link to comment
    1 hour ago, Yak said:

    Just rebooting my server to rc3.

     

    Just checking this the correct place to bang on about non-functional cosmetic changes now?

    Depends.  If you are talking about not liking the way something is presenting, then no.  If you are talking about a display/programming issue, then please post separate bug report.  If you want something totally different, please post feature request.  But if you post in here, chances are good (say 50/50) will be totally ignored ;)

    Link to comment

    Thanks for doing the monospace font for drive identities!  Is it possible to include the size and sdX identifier as well so they also lineup nicely?  Essentially, the whole Identification cell should be monospaced.

     

    Thanks!

    Link to comment
    2 minutes ago, limetech said:

    But if you post in here, chances are good (say 50/50) will be totally ignored ;)

    You gotta love honesty :) 

    Link to comment
    Just now, Dephcon said:

    Thanks for doing the monospace font for drive identities!  Is it possible to include the size and sdX identifier as well so they also lineup nicely?  Essentially, the whole Identification cell should be monospaced.

     

    Thanks!

    post as feature request^^

    Link to comment
    9 minutes ago, nuhll said:

    like you ignore the unraid slowdown posts? :D

    Not ignoring.  The purpose of Prerelease board here is to put different issues into different reports instead of a single HUGE topic which is very inefficient.  You don't like this, then wait for Stable release.

    • Upvote 1
    Link to comment

    I and atleast 2 other ppl have the same issue and we posted a seperate thread for each problem. Besides "check your ram" there was no much help. For me it seems, if i write to cache, then array speed goes down. If i dont write to cache, array is at "normal" speed.

     

    Please give us some information on how we can help to find out what the problem is. We wanna help to make unraid great again! xD

     

     

    Edited by nuhll
    Link to comment
    13 minutes ago, nuhll said:

    I and atleast 2 other ppl have the same issue and we posted a seperate thread for each problem. Besides "check your ram" there was no much help. For me it seems, if i write to cache, then array speed goes down. If i dont write to cache, array is at "normal" speed.

     

    Please give us some information on how we can help to find out what the problem is. We wanna help to make unraid great again! xD

     

     

    The best answer would be to roll back to stable.

     

    They are looking into it and remember we jumped kernel releases.

     

    Since unraid is used in different ways then any distro, we see different issue than some of the distro users see.

     

    Sometimes being on the cutting edge has disadvantages in edge cases.

     

    I would wait to test again once the devs can figure if its an unraid or upstream issue.

    Edited by Dazog
    Link to comment

    ... how to fix if no one tests it? But if no one tells us what to test or to do, we cant test it... :D


    Im not complaining that its not working. Im complaining that it seems like they are not activly tryin to find out what the problem is (or maybe they do but dont tell, i dont know).

     

    I would like to help find out what the problem is. But my knowledge is not that great on linux interna.

    Edited by nuhll
    Link to comment
    1 minute ago, nuhll said:

    ... how to fix if no one tests it? But if no one tells us what to test or to do, we cant test it... :D

    Do not interpret lack of "hey we're looking at this" as that we're not looking into it.

    Link to comment
    20 minutes ago, limetech said:

    Do not interpret lack of "hey we're looking at this" as that we're not looking into it.

    It wouldnt feel that way if you just write a "were investigating on this"

    Link to comment
    11 minutes ago, nuhll said:

    It wouldnt feel that way if you just write a "were investigating on this"

     

    kN4gmxq.png

    • Like 1
    Link to comment

    I dont understand how someone can think that?

     

    I didnt got told anything except, check your ram, after reporting the problem.


    Thats btw just the attitute why ppl dont report bugs anymore.

     

    Since we posting funny pictures now:

    3_child-died.jpg

    Edited by nuhll
    Link to comment

    And that is why some folks no longer bother to reply to threads with varioous items to try.

    Link to comment
    12 minutes ago, BRiT said:

    And that is why some folks no longer bother to reply to threads with varioous items to try.

    I dont understand that, what you mean?

    Link to comment

    I started getting a log error. For clock not synchronized. But it has the right time. It really doesn't make sense. 

     

    Currently I'm using time1.google.com 

    Default settings 

    Link to comment
    3 hours ago, limetech said:

    But if you post in here, chances are good (say 50/50) will be totally ignored ;)

    Fair enough. At least I know it was noticed! ;)

     

    I expressed my opinion, a couple of people agreed with me, and now I'll move on with life.

    Link to comment
    17 minutes ago, gacpac said:

    I started getting a log error. For clock not synchronized. But it has the right time. It really doesn't make sense. 

     

    Currently I'm using time1.google.com 

    Default settings 

    Thats normal if you restart server. 

    • Like 1
    Link to comment
    10 minutes ago, gacpac said:

    I started getting a log error. For clock not synchronized. But it has the right time. It really doesn't make sense. 

     

    Do you mean like this, at the beginning of your syslog, just as the ntp daemon is starting up?

    Quote

    Feb 10 13:35:53 Mandaue ntpd[1664]: ntpd [email protected] Thu Dec 6 21:21:42 UTC 2018 (1): Starting

    Feb 10 13:35:53 Mandaue ntpd[1664]: Command line: /usr/sbin/ntpd -g -u ntp:ntp

    Feb 10 13:35:53 Mandaue ntpd[1666]: proto: precision = 0.083 usec (-23)

    Feb 10 13:35:53 Mandaue ntpd[1666]: Listen normally on 0 lo 127.0.0.1:123

    Feb 10 13:35:53 Mandaue ntpd[1666]: Listen normally on 1 br0 172.26.147.90:123

    Feb 10 13:35:53 Mandaue ntpd[1666]: Listen normally on 2 lo [::1]:123

    Feb 10 13:35:53 Mandaue ntpd[1666]: Listen normally on 3 br0 [fe80::f037:baff:fed2:cad7%15]:123

    Feb 10 13:35:53 Mandaue ntpd[1666]: Listening on routing socket on fd #20 for interface updates

    Feb 10 13:35:53 Mandaue ntpd[1666]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized

    Feb 10 13:35:53 Mandaue ntpd[1666]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized

    My understanding is that it's normal. The ntp daemon takes several minutes to synchronise the clock so as to try to avoid causing any sudden big jumps or "timewarps". That doesn't mean that the clock is wrong, just that it isn't locked in synchronism with the time server. The message isn't new to Unraid 6.7. It's present in 6.6.6 and earlier too. If you're seeing it later (hours or days) in the syslog then you might have a connectivity or configuration problem.

    Link to comment
    1 hour ago, FreeMan said:

    Fair enough. At least I know it was noticed! ;)

     

    I expressed my opinion, a couple of people agreed with me, and now I'll move on with life.

    Sorry for coming on a little strong.  I only meant that as new releases get published we 'lock' these "announement" topics and most of the time we don't take time to back and re-read every single post.  That is why a completely separate board (this one) was created in the first place: to post issues separately so we can track them.  Yes we monitor the reports and a lot of times don't always reply immediately - just really really busy trying to duplicate and fix the issues.  We do try to mark as 'solved' or 'retest' upon next release however.

    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.