unRAID OS version 6.4.1 Stable Release Available


limetech

Recommended Posts

Making a new rig with a 1920X Threadripper in it. The 6.4.1 update resolved the issue of not being able to pass through an Nvidia GPU at all, but having an issue with slot 1.

 

I've tried a GTX 960 4GB and a GTX 1060 6GB in the first slot, using the roms I dumped from the respective GPUs.

Both of these cards work in slot 3 with no issues, and no issues in the separate xeon build.

When I start a Win10VM my syslog either spams this message

"

Feb  4 02:01:02 BEAST kernel: vfio-pci 0000:42:00.0: BAR 3: can't reserve [mem 0xc0000000-0xc1ffffff 64bit pref]

"

Or will pop that message once and hard lockup the server.

 

 

The only differences between this rig and the Home Server listed in my sig are:

unRAID 6.4.1 / MB: MSI X399 SLI Plus - Latest BIOS update / CPU: 1920x TR4 / RAM: 24GB Kingston Non-ECC DDR4 (1 dimm out for preclearing a different system) / and the 1060 listed above.

 

Is anyone else running into this?

 

 

EDIT: pulled another DIMM just incase, but same situation. Diags attached

 

 

EDIT2: Thought I would be slick and just work around the issue by dropping the cards down to slot 2 and 3. Unfortunately, it then assigns the next highest slot as slot 1 and I get the exact same issues. :/ At least that rules out it being a bad slot, which makes me happy.

 

beast-diagnostics-20180204-0233.zip

Edited by ryoko227
Adding diags and some more info
Link to comment

Upgraded from 6.4 and no apparent issues other than this error in the log, which I think is an NTP server error or is it something else?

Feb 3 13:10:28 DaVault ntpd[1933]: receive: KoD packet from 45.127.112.2 has inconsistent xmt/org/rec timestamps. Ignoring.
Feb 3 13:11:33 DaVault ntpd[1933]: receive: KoD packet from 45.127.112.2 has inconsistent xmt/org/rec timestamps. Ignoring.
Feb 3 13:12:40 DaVault ntpd[1933]: receive: KoD packet from 45.127.112.2 has inconsistent xmt/org/rec timestamps. Ignoring.
Feb 3 13:13:47 DaVault ntpd[1933]: receive: KoD packet from 45.127.112.2 has inconsistent xmt/org/rec timestamps. Ignoring.
Feb 3 13:14:52 DaVault ntpd[1933]: receive: KoD packet from 45.127.112.2 has inconsistent xmt/org/rec timestamps. Ignoring.
Feb 3 13:15:57 DaVault ntpd[1933]: receive: KoD packet from 45.127.112.2 has inconsistent xmt/org/rec timestamps. Ignoring.

https://ipinfo.io/45.127.112.2


I have these NTP servers listed, are others recommended?

 

Screen Shot 2018-02-03 at 1.29.40 PM.png

Link to comment
2 hours ago, wirenut said:

"Fixed bug where the server TLD is not formed correctly in the self-signed SSL cert. After installing this release delete the self-signed cert config/ssl/certs/<server-name>_unraid_bundle.pem and then reboot to let unRAID OS regenerate a new one."

 

I've never used self signed certs as far as I know. Following the release notes I performed the instructions above. the file  <server-name>_unraid_bundle.pem did exist but after reboot nothing new was created. Only certificate_bundle.pem remains. Just want to be sure this is expected behavior. Thanks.

I deleted my file to try and get my tld working and had no joy.  I just noticed as well that the file was missing - went back to default (blank) and rebooted and the file still wasnt' recreated

Link to comment

<SOLVED>

 
I was able to get the VM up again by using the option : "Enable PCIe ACS Override:" in the VM settings.

Strange, i don't think I had this setting enabled before the update

</SOLVED>

 

Just updated and my VM won't start up correctly. Stays on the bios bootup for ages and eventually fails to boot. It then reboots and tries to get into windows "preparing automatic repair" but is unable to continue

 

update: It starts fine when I remove my videocard from the config and run via VNC. Nvidia card on INTEL cpu, worked fine before patch

 

Even got a crash in the log 

 

DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000800
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000
CPU #2:
EAX=00000640 EBX=00000000 ECX=00000000 EDX=00000000
ESI=bfe6a019 EDI=bf49f711 EBP=bfde2491 ESP=bfe6af00
EIP=bfe6a05d EFL=00000097 [--S-APC] CPL=0 II=0 A20=1 SMM=0 HLT=1
ES =0030 00000000 ffffffff 00c09300 DPL=0 DS [-WA]
CS =0010 00000000 ffffffff 00c09f00 DPL=0 CS32 [CRA]
SS =0030 00000000 ffffffff 00c09300 DPL=0 DS [-WA]
DS =0030 00000000 ffffffff 00c09300 DPL=0 DS [-WA]
FS =0000 00000000 0000ffff 00009300 DPL=0 DS16 [-WA]
GS =0000 00000000 0000ffff 00009300 DPL=0 DS16 [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT= bfe66698 00000047
IDT= bf8ab018 00000fff
CR0=00010033 CR2=00000000 CR3=bfe78000 CR4=00000640
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000800
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000
2018-02-03 19:00:59.191+0000: shutting down, reason=crashed

 

Edited by spirituality
Link to comment
9 minutes ago, DZMM said:

I deleted my file to try and get my tld working and had no joy.  I just noticed as well that the file was missing - went back to default (blank) and rebooted and the file still wasnt' recreated

 

Set 'Settings/Identification/SSL Certificate Settigngs/Use SSL/TLS' to No.  Verify you can reach server using http protocol.  Then delete the contents of 'config/ssl/certs/' on your usb flash boot device (there should only be one file in there).  Now go back and set 'Use SSL/TLS' to Yes.  That should do 2 things:  First it will cause a new self-signed cert to be created in 'config/ssl/certs/' directory.  Second it should enable https access to your server in addition to setting up a redirect so that http gets redirected to https.

 

If still no love after all this, send me the cert that got generated so I can take a look at it.  Also, would be helpful to know more details about your local domain.  If you don't want to discuss via forum then switch to email: [email protected].

Link to comment
53 minutes ago, limetech said:

 

Set 'Settings/Identification/SSL Certificate Settigngs/Use SSL/TLS' to No.  Verify you can reach server using http protocol.  Then delete the contents of 'config/ssl/certs/' on your usb flash boot device (there should only be one file in there).  Now go back and set 'Use SSL/TLS' to Yes.  That should do 2 things:  First it will cause a new self-signed cert to be created in 'config/ssl/certs/' directory.  Second it should enable https access to your server in addition to setting up a redirect so that http gets redirected to https.

 

If still no love after all this, send me the cert that got generated so I can take a look at it.  Also, would be helpful to know more details about your local domain.  If you don't want to discuss via forum then switch to email: [email protected].

sent via email

Link to comment

I am using my own self-signed certificate for SSL.  Will this survive the upgrade or should I plan on reapplying my certificate?  I believed I named my certificate file the same as the unRAID default and just overwrote the default unRAID certificate.

Edited by mifronte
Link to comment
On 2/3/2018 at 3:16 AM, limetech said:

In addition, this release contains additional security updates related to the recent Meltdown and Spectre vulnerabilities.  For this reason, all users are encouraged to update.  We expect additional updates in the near future as additional mitigations become available.

I very much appreciate the heads up -- it helps me determine whether to update now or wait for near-term additional updates -- the latter in my case, as I don't want to update the OS again shortly after updating it previously.

Link to comment

I upgraded from 6.3.5 to 6.4.1 and every thing is working well, plugins, dockers and vm's.

 

I've had a search of the forums but can't find a definitive answer as to why use https for unRaid?

 

Is this feature only relevant to those accessing their unRaid server over the internet in a somewhat insecure matter?

 

99% of the time I access locally through my LAN, otherwise OpenVPN into my network. In my current scenario (And assuming no malware etc on my home LAN), is there any advantage to using https? Is this foundation work for something coming to unRaid at a later date?

 

Thanks :)

Link to comment

Upgraded from 6.3.5 cleanly (approximately 24 hours ago). I upgraded dockers and plugins before the upgrade. (I don't run any VM's).

 

All went perfectly, but tonight unraid was completely locked up. Never had this issue with 6.3.5, so I suspect something with the new version.  No access via Gui or CLI. No response to a ping of the management address.

 

Unfortunately, I had no choice but to power the machine off. It's running through it's parity check now.:(

 

I took a diagnostics immediately after restart in case it's useful. As console access was not working, I couldn't take a diagnostics before the power reset.

 

Is there anything I can check? Diagnostics after the reboot attached.

moose-diagnostics-20180205-2054.zip

Edited by PeteB
Link to comment
On 2/5/2018 at 4:47 AM, scytherbladez said:

99% of the time I access locally through my LAN, otherwise OpenVPN into my network. In my current scenario (And assuming no malware etc on my home LAN), is there any advantage to using https? Is this foundation work for something coming to unRaid at a later date?

 

You are assuming that your LAN is secure.  If it is all wired, you probably are OK. That assumes that all of your users are trustworthy.  Wireless is a bit more of problem.  I understand that there are some kiddy-scripts out there that can crack the security on wireless routers pretty quick.  (But those folks are not really seeking out your unRAID server, they often want to hide their identities when they are conducting certain types of Internet activities.)

 

I decided to go the middle route.  I am using https with a self-signed certificate.  Most modern browsers will scream holy terror when you go that route but googling will quickly find the method to make the server address a 'trusted' one.  

 

EDIT:  (2018-02-27)  I finally decided to modify the configuration of my Ubiquiti Router to permit secure provisioning using Let's Encrypt SSL certificate.  It did take some effort on my part but I did find an easier way then using Ubiquiti Command Line Interface.   If you are interested, you can read about it here:

 

        https://lime-technology.com/forums/topic/61265-what-router-are-you-running/?page=3&tab=comments#comment-637221

 

Edited by Frank1940
  • Like 1
Link to comment

Upgraded the main server that also runs my firewall via pfsense vm. These errors were detected in fix common problems, but they make sense why since there was no network connection: 

 

Could not check for blacklisted plugins	The download of the blacklist failed	
Could not perform unknown plugins installed checks	The download of the application feed failed.	
Could not perform docker application port tests	The download of the application feed failed.	
Could not perform docker application port tests	The download of the application feed failed.

 

Maybe a way to delay those tests? Like a toggle to add a few minutes delay to allow for a firewall to boot up before checking?

 

 

Also, for some reason after the array started it tried to run a parity check even though I used the reboot button when upgrading from 6.4.0

 

Otherwise all seems fine.

Link to comment
2 hours ago, PeteB said:

I took a diagnostics immediately after restart in case it's useful. As console access was not working, I couldn't take a diagnostics before the power reset.

 

Is there anything I can check?

 

Install the 'Fix Common Problems' plugin and turn on the 'Troubleshooting' mode.  That plugin will run a tail on your syslog, periodically appending the results to a file in the logs folder/directory on your Flash Drive.  There is also another thread in this sub-forum which has Update Notes about this release, have you read through it to make sure that you don't have one of the systems that requires some other steps then a simple upgrade of the software? 

Link to comment

Hi, not sure if it ok to post this here, otherwise please let me know if I should open a new thread.

 

I have mounted a network share of another NAS in Unraid via User Scripts plugin. The share is mounted on startup and unmounted on shut down. Since 6.4.0 the connected NAS no longer sleeps and the HDDs don't spin down. If I unmount the folder manually everything works as it should. When I switch of the NAS, i get the following error in the log file:

 

Tower kernel: CIFS VFS: Server "ip of NAS" has not responded in 120 seconds. Reconnecting...

 

I assume that there is an intermittent query if the network decive, i.e. NAS, is still responding and I suspect this is preventing the NAS from hibernation. Is there a way to disable that feature?

 

Your help is much appreciated!

 

Cheers,

Sebastian

Link to comment
2 minutes ago, Seige said:

Hi, not sure if it ok to post this here, otherwise please let me know if I should open a new thread.

 

I have mounted a network share of another NAS in Unraid via User Scripts plugin. The share is mounted on startup and unmounted on shut down. Since 6.4.0 the connected NAS no longer sleeps and the HDDs don't spin down. If I unmount the folder manually everything works as it should. When I switch of the NAS, i get the following error in the log file:

 

Tower kernel: CIFS VFS: Server "ip of NAS" has not responded in 120 seconds. Reconnecting...

 

I assume that there is an intermittent query if the network decive, i.e. NAS, is still responding and I suspect this is preventing the NAS from hibernation. Is there a way to disable that feature?

 

Your help is much appreciated!

 

Cheers,

Sebastian

Do you have Unassigned Devices installed?

Link to comment
On 2/3/2018 at 3:07 AM, Squid said:

Because the Support and Project Links for each installed docker application on the context menus within the Dashboard and Docker pages are a new feature going forward, your already installed / previously installed applications may not show both (or any of) those new menu items.

 

THIS IS COMPLETELY OPTIONAL AND IS NOT REQUIRED, NOR WILL NOT DOING THESE STEPS IMPEDE THE OPERATION OF YOUR SERVER AT ALL

 

If you would like to add those menu items to your existing installed apps, then 

  1. Go To The Apps Tab.  This step just insures that the data step 2 uses is completely up to date.  If you haven't gone to the apps tab at least once before step 2, it will error out and tell you that you first must go to the apps tab
  2. Go to Plugins, Install Plugin and paste the following URL into the section:   
    
    https://raw.githubusercontent.com/Squidly271/misc-stuff/master/fix_template.plg

     

 

You should get a whack of messages as it updates your existing applications with the new menu information.  Note that you're not actually installing a plugin or anything.  I'm just using the plugin system as a simple way to run a script.

 

It is only necessary to ever run this script ONCE.  Going forward, any new installations of applications via the apps tab will populate the appropriate section for the new menu items to work properly (on pretty much any version of CA)  

 

* If you have already run this script on 6.4.1-rc2, then it is NOT necessary to re-run it on 6.4.1 stable.

 

After I did this, any docker that I update has it's template become an orphan image :( what do I do? This is a critical issue.

hal9000-diagnostics-20180205-1855.zip

Edited by JohanSF
Diagnostics attached
Link to comment
  • limetech locked and unpinned this topic
Guest
This topic is now closed to further replies.