Important: If you want to report an issue, please start a new topic in this board.

 

This is a bug fix release only (-rc6).

 

UEFI support (-rc5)

It is now possible configure UEFI boot mode to boot unRAID OS.  The make_bootable.bat (Windows), make_bootable_mac (MacOS) and make_bootable_linux (Linux) scripts will output a prompt:

 

  Permit UEFI boot mode [Y/N]:

 

If answered with 'Y' a new directory is included on the USB flash boot device called 'EFI'.  The presence of this directory along with its contents, and along with some additional linux kernel options permit UEFI boot.  This is done in such a way that you could choose either BIOS (legacy) or UEFI to boot off your USB flash device (that is, even if you answer 'Y' here you can still configure your motherboard to use Legacy boot).

 

If answered with 'N' the directory and contents are still created, but named 'EFI-' (a dash at the end).  This will prevent UEFI firmware from considering this device.  You can manually rename the 'EFI-' directory to 'EFI' and permit possible UEFI boot (and rename back to 'EFI-' to prevent it again).

 

Note: Even if the 'EFI' directory exists, whether or not your motherboard actually uses UEFI to boot is determined by BIOS settings.  In addition, some motherboards may present a strongly worded warning along the lines of "The system found unauthorized changes on the firmware, operating system or UEFI drivers."  In this case look for a "Secure Boot" BIOS setting and change to "Other OS" or "Disable".

 

If you update your server using Check for updates on the Plugin page, an 'EFI-' directory and files will be automatically created on your USB flash boot device.  If you prepare a new USB flash using this release, the 'EFI-' directory and files will also be included.  If you use the "manual" method of updating by copying the bz* files from the release zip, beware you will need to manually also copy over the 'EFI-' directory (and modify the first line of syslinux.cfg and copy it to 'EFI-/boot' directory).

 

There is also a webGui setting to permit UEFI boot located on the 'flash' device information page in the 'Syslinux Configuration' section.

 

Update OS (-rc5)

We have changed the way one checks for new unRAID OS releases.  Instead of bundling an "unRAID Server" plugin on the Plugins page, there is a new page on the Tools menu in the About section called 'Update OS'.  Here you can check for a new unRAID OS release as well as switch between the latest release in the stable branch or the next branch.  In addition there is a separate control on the Notification Settings page that configures whether or not to automatically check for updates.

 

Improved shfs/mover (-rc1)

 

The LimeTech user share file system (shfs) has been improved in two areas.  First, we now make use of FUSE read_buf/write_buf methods.  This should result in significant throughput increases.  Second, the mover script/move program no longer uses rsync to move files/directories between the cache pool and the parity array.  Instead the move program invokes a new shfs ioctl() call.  This should result in complete preservation of all metadata including atime and mtime.

 

While this function has been fairly extensively tested, please keep an eye on mover activities - there shouldn't be any data loss, but it's a fairly significant code change.

 

nginx http server (-rc1)

We now use the nginx webserver as the front-end to the unRAID OS Management Utility (aka, webGui).  The emhttp process has been changed to a daemon (emhttpd) listening at a unix socket.  Incorporating nginx provides several features:

• Multi-threaded access, though emhttpd is still single-threaded.
• https (SSL) support.  At present unRAID OS will generate a self-signed certificate.  https works but you will get a scary warning from your browser about not being able to verify the certificate.  No worries.
• nchan (websocket) support.  We have only just begun the process of converting many of the browser javascript polling functions to an event-driven websocket paradigm.  This opens the door for  us to create something like a process manager where we can have several background operations in process, all monitored in real-time via webGui dashboard.

 

enabling https (-rc3)

To enable https support it's necessary to edit your 'config/go' file on your USB flash boot device.  Use the -p option to specify the port(s) and optionally include the -r option to redirect http request from your browser to using https.  Here's the detailed usage:

# Usage:
#   emhttp [-r] [-p port [,sslport]] [OPER]

# OPER is start or stop.  Default is start.
# By default nginx will be setup to listen only at port 80 (http).
# The -p option may be used to define different listening ports and/or setup nginx
# to listen at a specified port for https.  The -r option may be used to setup
# nginx so that any http request is redirected to https (this requires that both
# ports have been specified with -p option).  For example, to have nginx listen
# at both standard ports but redirect all http to https use:
#   emhttp -rp 80,443
# To listen at only port 443 use:
#   emhttp -p ,443

# Note: the stop operation is only "safe" if the array has already been stopped
# (this will be fixed).

 

linux 4.11 kernel (-rc1) - should provide better Ryzen support among other improvements.

 

IPv6 support (-rc1)

We want to again, give a big "thank you" to bonienl who has greatly improved unRAID OS networking with the addition of IPv6 support.  Give it a try and report any issues.

 

Other (-rc1)

• Two new webGUI themes: Azure and Gray.  Again, thanks to bonienl.
• Expanded driver support (QLogic) and more hardware monitoring support.
• Kernel modules and firmware are left on the Flash in a squashfs loopback and loaded into RAM on demand.
• Many more misc. improvements

 

Changes (-rc6)

 

Linux kernel:

• additional modules:
  • CONFIG_INTEL_POWERCLAMP: Intel PowerClamp idle injection driver
  • CONFIG_CPU_FREQ_GOV_SCHEDUTIL: 'schedutil' cpufreq policy governor
  • CONFIG_THERMAL_GOV_FAIR_SHARE: Fair-share thermal governor
  • CONFIG_THERMAL_GOV_BANG_BANG: Bang Bang thermal governor
  • CONFIG_THERMAL_GOV_POWER_ALLOCATOR: Power allocator thermal governor
• more components changed from built-in to module

Management:

• webgui: More updates to plugin manager - remove dynamix check
• webgui: Fixed auto resize icons to 48px in plugins page
• webgui: Fixed incorrect name when plugin check is done
• webgui: Add "Check for Updates" button and disable auto-check as needed
• webgui: Remove the "Retry" button when communication failure
• webgui: Fixed regression error of double function declaration

First RC for 6.4 I have tried. Upgraded from 6.3.5 stable without issue. Renamed EFI- to EFI, made appropriate changes in the BIOS, and all booted up perfectly the first time. WebGUI is super snappy (starting Dockers used to take a few seconds, now it's immediate)!

 

Really great work, Limetech team!

6 minutes ago, kaiguy said:

Really great work, Limetech team!

 

Thanks for the report!  A lot of credit goes to bonienl for webGui work and eschultz for nginx integration.

After a +1 week of using builds since rc3, this has been very stable now up to rc6. 

I'd like to say a special thanks to bonienl, the changes made in rc3 allowing IP addresses assignable to docker containers was a feature I'd been wanting for a long time! It made me upgrade early to this 6.4 pre-release version. It works great. I can setup a static route in the new network settings UI as well to point the IP around my OpenVPN plugin to allow that container to now be in the VPN, so ports still forward to it (Great for those wanting to run Plex and have remote access yet still run OpenVPN for everything else on UnRAID). It works fantastic! I finally shutdown my last VM, it's all docker now. Thank you bonienl !!!!!

16 hours ago, kaiguy said:

First RC for 6.4 I have tried. Upgraded from 6.3.5 stable without issue. Renamed EFI- to EFI, made appropriate changes in the BIOS, and all booted up perfectly the first time. WebGUI is super snappy (starting Dockers used to take a few seconds, now it's immediate)!

 

Really great work, Limetech team!

 

I just did the same as above and can confirm the same results. My Windows 10 VM has never started as quickly as it did today. I barely saw any of the startup screens. Great work everyone!

What are the advantages to booting with UEFI with unRaid?   I jumped to 6.4rc5 and now rc6 with no issues and wondering if it would be beneficial to rename this folder and see if my system boots.

32 minutes ago, digiblur said:

What are the advantages to booting with UEFI with unRaid?   I jumped to 6.4rc5 and now rc6 with no issues and wondering if it would be beneficial to rename this folder and see if my system boots.

I asked the same question a couple of rc's ago. Primary advantage is future proofing unRAID (some boards no longer support bios I guess). Depending on your motherboard you may have a few features using uefi that you don't have now.

Just now, wgstarks said:

I asked the same question a couple of rc's ago. Primary advantage is future proofing unRAID (some boards no longer support bios I guess). Depending on your motherboard you may have a few features using uefi that you don't have now.

 

It's a Dell Poweredge T20 box, I do remember it supporting UEFI so I'll give it a shot.  Geaux Tigers!

10 hours ago, digiblur said:

 

It's a Dell Poweredge T20 box, I do remember it supporting UEFI so I'll give it a shot.  Geaux Tigers!

 

It's a real game of chance out there regarding UEFI booting.  The UEFI boot ability was added in rc4 and it was the default if your MB permitted it.  One of the problems was that some MB defaults  were set to do a 'secured' UEFI boot option that only Microsoft supports with Windows 8 and 10. (Mine was one.)  When unRAID tried to boot on a MB so configured, the boot stopped and the BIOS/UEFI loader would throw up a warning on the connected monitor.  If the MB was setup to permit a boot with an unsigned OS (which Linux is) it booted just fine using UEFI!  So it is possible that you already have booted up using UEFI if your MB supports UEFI and it was turned on and it allowed booting of unsigned OS...

 

You can check to see which one is running with version 6.4.0-rc6, by going to  'Main'  >>>  'Boot Device'    >>>  'Flash' (under "Device" column)  >>>  ' Syslinux Configuration'

Edited June 25, 20179 yr by Frank1940

New to UnRaid...  Have a Ryzen build and it appears that there are some fixes that will benefit me in this release...  I have been poking around the forums for a while but, I cannot seem to find where to download the beta releases or instructions on how to do so?  

 

Little help?

 

Thanks for all help!

2 minutes ago, nnpeters08 said:

New to UnRaid...  Have a Ryzen build and it appears that there are some fixes that will benefit me in this release...  I have been poking around the forums for a while but, I cannot seem to find where to download the beta releases or instructions on how to do so?  

 

Little help?

 

Thanks for all help!

PR Installation Guide

Hi there. I'm an old sheep that strayed away from the Unraid flock years ago but have found my my back. Overall, this is a great preview release and I've been running 6.33-6.35 Pro for the previous month with no issues. Since upgrading to 6.4 rc6 this am, I can't boot into GUI mode. I'm also running with UEFI boot too.  It seems to load the bzimage fine and I can see all the text but end up with a blinking cursor in the upper lefthand corner. This is also the case in GUI safe mode. When I change the syslinux config to boot into non-gui mode, I get the root command prompt just fine. Is there something that I'm missing? I've browsed the rc forum but can't seem to find my way through this. Sorry in advance if I've missed something.

 

Thanks!

 

Edit:  To clarify, I can boot the machine just fine since applying the rc, but can't access the onboard GUI. I can access the Web GUI just fine through my phone's browser, the browsers in my Win10 VM hosted in unraid, etc...

 

Edit2: Got it working. I had to enable CSM in the BIOS then set to UEFI only. I previously had CSM disabled which allows UEFI boot, but CSM enabled then setting sub setting to UEFI only did the trick. Sorry for any inconvenience.

Edited June 25, 20179 yr by jayman
figured out problem

I'm having some issues getting around the new nginx implementation:

 

So I have unraid doing the 80->443 redirection, awesome, works fine for accessing the webui from 80 or 443.  Now when i try to hit anything else, ie containers, the unraid nginx is catching it and pushing 502s/etc.

 

An example:

I have my router take http/https and forward it to my unraid box on ports 81/441.  I have a nginx docker container listening on those ports and redirects to plex, unifi, etc.  This was working fine prior to unraid switching to nginx as now it's catching all HTTP requests and rejecting them.

 

As a work-around i used the new feature to do custom IPs for docker.  I gave my nginx container it's own IP and now my router passes external 80/443 to it successfully, but then my container redirects to unraidIP:whatever and again get intercepted.

 

as a further work around i gave a dedicated IP to my unifi container too and now i hit my unifi container from the internet.  Cool... but i don't want to set a static IP for every container i eventually want to access externally.

 

Thoughts?

 

Thanks!

Edited June 25, 20179 yr by Dephcon

On 6/25/2017 at 3:44 AM, digiblur said:

What are the advantages to booting with UEFI with unRaid?   I jumped to 6.4rc5 and now rc6 with no issues and wondering if it would be beneficial to rename this folder and see if my system boots.

 

Xeon overclocking

16 minutes ago, methanoid said:

 

Xeon overclocking

 

I have seen this been mentioned a couple of times now, but have found no info about this. Why does efi boot allow over locking of a Xeon CPU?

11 hours ago, Dephcon said:

I'm having some issues getting around the new nginx implementation:

 

So I have unraid doing the 80->443 redirection, awesome, works fine for accessing the webui from 80 or 443.  Now when i try to hit anything else, ie containers, the unraid nginx is catching it and pushing 502s/etc.

 

An example:

I have my router take http/https and forward it to my unraid box on ports 81/441.  I have a nginx docker container listening on those ports and redirects to plex, unifi, etc.  This was working fine prior to unraid switching to nginx as now it's catching all HTTP requests and rejecting them.

 

As a work-around i used the new feature to do custom IPs for docker.  I gave my nginx container it's own IP and now my router passes external 80/443 to it successfully, but then my container redirects to unraidIP:whatever and again get intercepted.

 

as a further work around i gave a dedicated IP to my unifi container too and now i hit my unifi container from the internet.  Cool... but i don't want to set a static IP for every container i eventually want to access externally.

 

Thoughts?

 

Thanks!

 

With the new implementation you have the possibility to assign dynamic IP addresses to Dockers out of a predefined pool. This pool can be entered under Docker Settings with the Docker service stopped. Care needs to be taken that the Docker pool does not conflict/overlap with the regular DHCP service (usually your router), some planning is required.

 

1 minute ago, saarg said:

 

I have seen this been mentioned a couple of times now, but have found no info about this. Why does efi boot allow over locking of a Xeon CPU?

 

It's not real OC but allowing Xeons to run where all cores run at the full single core Turbo frequency so a helpful boost. Only works on v3 (Haswell) Xeons - https://forums.anandtech.com/threads/what-controls-turbo-core-in-xeons.2496647/

5 minutes ago, methanoid said:

 

It's not real OC but allowing Xeons to run where all cores run at the full single core Turbo frequency so a helpful boost. Only works on v3 (Haswell) Xeons - https://forums.anandtech.com/threads/what-controls-turbo-core-in-xeons.2496647/

 

I read some of it, but didn't see any reference to uefi in the first two pages, so didn't read further 

I guess its buried somewhere in that thread. Was hoping for a TL;DR in the first page as I was only interested in knowing why it's uefi only, not doing it myself 

1 minute ago, saarg said:

 

I read some of it, but didn't see any reference to uefi in the first two pages, so didn't read further 

I guess its buried somewhere in that thread. Was hoping for a TL;DR in the first page as I was only interested in knowing why it's uefi only, not doing it myself 

 

Its an awful thread for that. 

 

The short version for you:  Mod your BIOS to strip out microcode (it will be too recent). UEFI boot, set your Xeon settings to allcores at max, set your UEFI shell to load a file before the OS, and boot OS, loading newer microcode with Windows (most using that) but Linux can load microcode a different way and the Allcore Turbo is locked in at the single core rate. 

 

Not done it myself yet but the benefits are there. My E5-2683-v3 is 2.0 GHz, allcore 2.5 and single core 3.0. With this process I should be able to run all cores at 3.0 GHz, effective 20% boost. Handy for VMs of course.

Just enabled UEFI boot on the hardware detailed in my .sig - no problems encountered.

 

However, on examining the system log, there are two lines which caught my attention - are they of any import?

 

First is a warning:

Jun 26 18:15:09 Tower avahi-daemon[13853]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!

Second is an error:

Jun 26 18:15:09 Tower root: error: /webGui/include/ProcessStatus.php: wrong 155F9F8FBDD0F762:8B6907138D1C296D csrf_token

Anything I should be worrying about?

1 hour ago, PeterB said:

Second is an error:

Jun 26 18:15:09 Tower root: error: /webGui/include/ProcessStatus.php: wrong 155F9F8FBDD0F762:8B6907138D1C296D csrf_token

Anything I should be worrying about?

wrong csrf token has been explained many times on the forum. Typically it means you have another browser open to your server. Do you have any phone apps that access it?

3 hours ago, bonienl said:

 

With the new implementation you have the possibility to assign dynamic IP addresses to Dockers out of a predefined pool. This pool can be entered under Docker Settings with the Docker service stopped. Care needs to be taken that the Docker pool does not conflict/overlap with the regular DHCP service (usually your router), some planning is required.

 

 

Even with a pool defined, the IPs are still dynamically assigned to the containers right?  That means I pretty much have to statically assign them to be able to config my reverse proxy for all the apps.

 

It it possible to set a "Docker IP" so that all containers use the same IP, like before, but it's just not the same that unraid uses?  a user would still need to deal with port overlap, etc, but at least would know all our containers are at a specific IP.

4 hours ago, methanoid said:

 

Its an awful thread for that. 

 

The short version for you:  Mod your BIOS to strip out microcode (it will be too recent). UEFI boot, set your Xeon settings to allcores at max, set your UEFI shell to load a file before the OS, and boot OS, loading newer microcode with Windows (most using that) but Linux can load microcode a different way and the Allcore Turbo is locked in at the single core rate. 

 

Not done it myself yet but the benefits are there. My E5-2683-v3 is 2.0 GHz, allcore 2.5 and single core 3.0. With this process I should be able to run all cores at 3.0 GHz, effective 20% boost. Handy for VMs of course.

 

Thanks for the easy version for the lazy ones 

what i noticed is that the new WebUI design sometimes doesnt like dashes in the names.

 

Example #1:

 

Example #2 with mouse hovered over the docker:

4 minutes ago, DaLeberkasPepi said:

what i noticed is that the new WebUI design sometimes doesnt like dashes in the names.

 

Should be fixed with the next release.