Version 6.4.1-rc1 2018-01-26

Summary:

• Linux kernel 4.14.15 includes further changes to the "retpoline" patch set introduced in 4.14.14 and we have recompiled using GCC 7.3. This addresses 'Spectre Variant 2'.

• Added kernel patch to address GPU passthrough issue on AMD Threadripper.

• Following guidance from Intel we have reverted Intel microde to the 2017-11-17 release.

• Refinements to SSL/TLS handling:

  • When not using SSL/TLS (https), we no longer auto-redirect PORTSSL (443) to PORT (80).
  • Added "Local TLD" configuration variable to specify your local top-level domain (default is "local").

• User bonienl added the possibility to remove or preserve user defined networks within Docker. This is for advanced users only. Also explained in the Help text.

• Fixed bug related to improper handling of replacing device in btrfs cache pool, when the device being replaced is still installed in the server. Note: there is no webGUI monitoring of btrfs replace operation in this release but you can monitor progress in the Log window.

Changes

Base distro:

• aaa_elflibs: version 14.2-x86_64-34
• ca-certificates: version 20170717
• curl: version 7.58.0 (CVE-2018-1000007, CVE-2018-1000005)
• intel-microcode: version 20171117
• kernel-firmware: version 20180118
• ttyd: version 1.4.0

Linux kernel:

• version 4.14.15 (CVE-2017-5715)
• added patch for AMD Threadripper pci bridge reset

Management:

• exclude user plugins from cron in safemode
• update smartmontools drivedb and hwdata/{pci.ids,usb.ids,oui.txt,manuf.txt}
• docker: rebuild networks upon restart
• emhttp: add "Local TLD" configuration setting
• emhttp: bug fix: array Start hang if empty MEDIADIR
• emhttp: bug fix: handle btrfs cache pool replace device case
• nginx: when SSL not in use, do not listen on http PORT
• rsyslogd: suppress nginx message 'user "logout" was not found in "/etc/nginx/htpasswd"'
• rsyslogd: suppress UpdateDNS message 'Error: Nothing to do'
• shfs: less verbose logging
• webgui: Add installed plugins & version to diagnostics
• webgui: List users alphabetically
• webgui: New Docker option to remove or preserve user defined networks
• webgui: Show History button when parity operation in progress
• webgui: Correct system information for systems with >= 1TB of RAM memory
• webgui: Included SMART attribute 199
• webgui: vm manager: shrink width separating cpu core checkboxes to prevent clipping on linux desktops (gtk3)
• webgui: vm manager: remove Log column
• webgui: UpdateOS should fetch unRAIDServer.plg from LimeTech download site instead of from github
• webgui: Switch to font-awesome for delete template on add Container
• webgui: Updated jquery tablesorter to v2.29.4

Updated from 6.4 rc21 to this with no issues.

VM also worked and booted directly into it.

Cheers

Quote

The 6.4.1-rc1 release includes a patch that should solve Threadripper GPU passthrough issue.  Please give it a try:

Done, no issues. One oddity two of my drives reported SMART UDMA CRC failure. Looked, it was just old age flag on first drive. Went to check the second drive and array had gave all good. VM running nominally. 

 

1 hour ago, Jcloud said:

One oddity two of my drives reported SMART UDMA CRC failure. Looked, it was just old age flag on first drive. Went to check the second drive and array had gave all good. VM running nominally. 

 

Normal, in this release SMART attribute 199 (UDMA CRC errors) is monitored by default. This can result in first time notifications when restarting the system. You can acknowledge these, see also Dashboard. When CRC errors start to increment only then more notifications are given. Usual course of action is to check the SATA cable & disk connection.

 

50 minutes ago, bonienl said:

When CRC errors start to increment only then more notifications are given. Usual course of action is to check the SATA cable & disk connection.

Good to know, had already started checking the drives.  Both drives where bought, installed, and gave this same error all the exact same time (same manufacture, WD one blue, one red) -- too many coincidences, so I wasn't really worried about it.

Edited January 27, 20188 yr by Jcloud
clarification.

Fixed bug related to improper handling of replacing device in btrfs cache pool, when the device being replaced is still installed in the server. Note: there is no webGUI monitoring of btrfs replace operation in this release but you can monitor progress in the Log window.

  Great job on this [emoji106], I tried my best to break it doing all kinds of replacements and adding/removing members and it always worked great.

 

One more suggestion, if it's easy/possible, similarly to when there's an ongoing parity operation, disable the stop array button during a pool balance or replacement, these can take a while depending on the config and data usage and if the user tries to stop the array before it's done he'll get a "retry unmounting disk shares" warning until it's done, I fear a more impatient user might force a reboot most likely ending up with a corrupt cache pool.

 

 

 

 

Haven't updated from 6.3.5 yet, but planning to today or tomorrow.

 

For those of us on Threadripper, are there any manual steps - go/config file edits or similar - that are still needed?

9 hours ago, limetech said:

nginx: when SSL not in use, do not listen on http PORT

Don't you mean do not listen on https port?

Will this release include the latest Docker-CE v18.01.0-ce ?

30 minutes ago, Dazog said:

Will this release include the latest Docker-CE v18.01.0-ce ?

 

17.09.1-ce is the included version

4 hours ago, dlandon said:

Don't you mean do not listen on https port?

Yes.

Upgraded, no issues. Thanks for staying on top of Meltdown and Spectre for us. Intel reverting the microcode update is kind of crazy!

I'm looking for changes to make to the Update Notes thread when 6.4.1 goes stable... can you confirm that Ryzen users should still invoke zenstates in their go script?

If so, I'd suggest updating 6.4.0 release notes to include the full path to zenstates, as I believe that is necessary

https://lime-technology.com/forums/topic/65494-unraid-os-version-640-stable-release-available/?page=22&tab=comments#comment-627240

 

 

Also, is this a valid description of the new SMART 199 feature?

Quote

 

unRAID can now track changes in SMART attribute 199 (CRC errors), which indicates an issue with the SATA cable or connectors.

 

If you previously customized the smart notifications for your drives, you'll need to enable this on each drive:

• Go to Main -> Disk 1 -> Disk 1 Settings -> SMART Settings and put a check mark next to attribute 199.  Apply.
• Click the arrow buttons to move to the next drive and repeat.

You may also want to confirm it is enabled in the global settings:

• Settings -> Disk Settings -> Global SMART Settings -> put a checkmark by 199 and Apply.

 

 

5 hours ago, -Daedalus said:

For those of us on Threadripper, are there any manual steps - go/config file edits or similar - that are still needed?

 

I haven't been tweaking my go file for Threadripper. I updated, from 6.3.5, to 6.4-rc17b (when it was a new release) prior to swapping my hardware

I hope that answered your question.

 

Good day.

Upgraded to 6.4.1rc1 and all good so far.

Updated OK here too, also had the UDMA CRC error on my two WD80EZZX drives.  The WD50EFRX was OK.

1 hour ago, HellDiverUK said:

Updated OK here too, also had the UDMA CRC error on my two WD80EZZX drives.  The WD50EFRX was OK.

Me as well, I had  UDMA CRC errors on 2 HDDs and  an SSD once I updated so I had to disconnect all sata and recheck all cables.

but everything else seems to be working fine.

Everyone can acknowledge and ignore if they get an initial CRC error warning, this attribute is cumulative and never resets, any future warnings should be acted upon, these errors are usually fixed by replacing the SATA cable, though if you get a single error once in a blue moon it can also be ignored.

 

 

On 1/26/2018 at 11:20 PM, limetech said:

Following guidance from Intel we have reverted Intel microde to the 2017-11-17 release.

 

Tom ----  There have been a few reports of reboots with 6.4.0, should there be a post in that release thread stating that upgrading to 6.4.1-rc1 might resolve those issues if Intel processors are involved?  

9 minutes ago, Frank1940 said:

should there be a post in that release thread stating that upgrading to 6.4.1-rc1 might resolve those issues if Intel processors are involved?  

It probably should, but only Haswell and Broadwell CPUs are affected.

10 minutes ago, johnnie.black said:

It probably should, but only Haswell and Broadwell CPUs are affected.

 

I presume mose people still using Haswell or Broadwell...

I'm new to UnRAID... I did a test installation of 6.3.1 using the trial license a while back, just to make sure my hardware build worked correctly, and figured I'd wait for the next stable official release (equivalent to LTS releases on some OSS software) before  doing a real install with a paid license.

 

However, "stable" IME (was a SW dev for decades) also means no new released versions for a while -- 3-6 months at least -- particularly on server-type software.
I don't want to upgrade a server OS more than once a year unless absolutely vital.

 

6.4.0 was finally released after >20 release candidates (really beta versions -- took me a while to figure out the nonstandard terminology). I was going to monitor the forum for a couple weeks to make sure no vital issues came up, and then install.

Suddenly, two weeks after the 6.4.0 release, I see the announcement of 6.4.1 RC .

I'm confused:

1) Was a 6.4.1 release already anticipated when 6.4.0 came out? If so, this should have been documented in the (nicely detailed) 6.4.0 release announcement.

2) Were unexpected major issues found with 6.4.0 that require a 6.4.1? I did try to skim various forum threads re the release, but it's unclear, and again, it should be announced in a more formal way (and also,  is the 6.4.1-rc1 a real RC, or a beta)?

3) Is it already known there'll be a successor to 6.4.1 within the next 3 months or so due to bug fixes (e.g., Spectre/Meltdown issues) rather than new UnRAID functionality?  If so, I might want to delay my installation yet again.

 

It would be very helpful if these could be addressed either here or on the LT blog, wherever appropriate.

Frankly, IMHO,  UnRAID also badly needs something like a published roadmap, even if non-binding.
 

UnRaid releases are named x.y.z (e.g., 6.4.0)

 

Changes to x are rare. These are major releases. 5 to 6 changed from 32bit to 64bit.

 

Changes to y are normal releases. It is common to have several betas, followed by RCs, followed by "stable".

 

Changes to z normally represent a bug fix, security update, or version change of an included component. Historically they have not had RCs, but this one has. Assuming LimeTech is being conservative and wants to ensure the release has no unexpected consequences before marking it as a stable release.

1 hour ago, SSD said:

Assuming LimeTech is being conservative and wants to ensure the release has no unexpected consequences before marking it as a stable release.

 

While it wasn't officially stated I suspect the reason for this particular -rc release was because Intel advised removing the microcode update for the Meltdown/Spectre problem  that they rolled out a couple of weeks ago.  They also advised that  another fix was imminent.  I suspect that LimeTech decided it was best to comply with their request but since a second fix was right behind that one to go release candidate route.   (Remember that there are a fair number of AMD systems that weren't affected by this issue.)   I don't know if there will be a second -rc with the new 'fix' but it would not surprise me.  This Meltdown/Spectre problem is a real mess.   Just look at what MS has caused with their updates this month but that is another story ...

On 1/27/2018 at 2:15 AM, bonienl said:

 

Normal, in this release SMART attribute 199 (UDMA CRC errors) is monitored by default. This can result in first time notifications when restarting the system. You can acknowledge these, see also Dashboard. When CRC errors start to increment only then more notifications are given. Usual course of action is to check the SATA cable & disk connection.

 

 

So we can ACK all the alerts now and freak out if/when we get a notification of them incrementing?

 

**edit**

I'm a bit worried about my cache SSD:

199	CRC error count	0x003e	098	098	000	Old age	Always	Never	1348

 

Edited January 29, 20188 yr by Dephcon

7 minutes ago, Dephcon said:

So we can ACK all the alerts now and freak out if/when we get a notification of them incrementing?

Yes, for now that only means there was a bad cable in the past, if the value keeps increasing there's still a problem.

 

On 28/01/2018 at 12:44 PM, johnnie.black said:

Everyone can acknowledge and ignore if they get an initial CRC error warning, this attribute is cumulative and never resets, any future warnings should be acted upon, these errors are usually fixed by replacing the SATA cable, though if you get a single error once in a blue moon it can also be ignored.

 

Edited January 29, 20188 yr by johnnie.black