Jump to content
limetech

unRAID OS version 6.4.0 Stable Release Available

537 posts in this topic Last Reply

Recommended Posts

I am interested in hearing from anyone who is running 6.4.0 with the patched kernel on a xeon 2670 v1 (Sandy Bridge).

 

There's an article on ServeTheHome that suggests that Intel has not gotten around to patching this generation of CPU and I don't want to run a kernel that has not been tested with my cpu.

Share this post


Link to post
6 minutes ago, Living Legend said:

 

I'm getting dirty looks from the family on this cold weekend day about the server being down, so I'm going to reset via IPMI and see if there is any data I can collect before starting the array and rolling back to a version that's actually stable for me.

 

I did not start the array.  I have access to the flash drive.  I guess when the crash happened, a diagnostic log was left on the flash drive.

 

unraid-diagnostics-20180113-1252.zip

Share this post


Link to post
27 minutes ago, Living Legend said:

I reluctantly made the upgrade to 6.4 as I had zero success with any of the pre-releases.  But since it was titled as a stable release, I figured I'd give it a shot.

 

Generally I treat the initial "stable release" with a bit of caution. It has been well tested by LimeTech, but the migration from the prior stable gets a workout as people try it, and it is normal for there to be a couple of quick releases to resolve problems found.

 

I'd prefer if the stable release was a promotion of the last RC to stable status, rather than a new release suddenly termed stable. But LimeTech has a good track record of good stable releases with only a bit of noise from a few users.

 

Quote

 

One hour in and I have yet another hard crash.  I have not touched anything since.

 

- I cannot access Web UI

- I cannot SSH in

- Monitor output shows a flashing dash

- Pinging the IP gets "destination host unreachable"

 

To make sure I provide the most information possible, before I roll back to stable 6.3.5, how should I gather necessary information in order to better troubleshoot?

 

 

I'd recommend the standard diagnostic zip file (Tools -> Diagnostics). You may have done before but that is the right first step. (Looks like you have already posted)

Share this post


Link to post
10 minutes ago, Living Legend said:

 

I'm getting dirty looks from the family on this cold weekend day about the server being down, so I'm going to reset via IPMI and see if there is any data I can collect before starting the array and rolling back to a version that's actually stable for me.

 

When testing the new version and having issues, first try to run it in safemode and see if the problems persist. It wouldn't be the first time a plugin or installed package is causing issues.

Share this post


Link to post
3 minutes ago, SSD said:

 

Generally I treat the initial "stable release" with a bit of caution. It has been well tested by LimeTech, but the migration from the prior stable gets a workout as people try it, and it is normal for there to be a couple of quick releases to resolve problems found.

 

I'd prefer if the stable release was a promotion of the last RC to stable status, rather than a new release suddenly termed stable. But LimeTech has a good track record of good stable releases with only a bit of noise from a few users.

 

 

I'd recommend the standard diagnostic zip file (Tools -> Diagnostics). You may have done before but that is the right first step.

 

Automatically created diagnostics already on flash drive before starting array:

unraid-diagnostics-20180113-1252.zip

 

Downloaded after startup:

unraid-diagnostics-20180113-1413.zip

Share this post


Link to post

Just as an FYI, the majority of issues I've seen reported in this thread are from onr of two causes:

 

1) using non standard / directly supported configurations (such as modifications to go file or use of 3rd party plugins)

 

2) upgrading from a much older version of unraid directly to 6.4

 

It appears the majority of folks running stock builds and that were on 6.3.5 have had little to no issues with the upgrade.

 

Please keep the feedback coming!!

Share this post


Link to post
10 minutes ago, johnnie.black said:

 

btrfs is supported, you have a non standard unRAID partition, likely created with an old version of the UD plugin, you need to downgrade back to v.6.3.5, backup your cache to the array, upgrade back to v6.4, reformat the cache device and restore the data back, you can use this procedure to do the backup/restore.

 

Just copy the bz 6.3.5 files over to the flash drive correct?

Share this post


Link to post
1 minute ago, jonp said:

Just as an FYI, the majority of issues I've seen reported in this thread are from onr of two causes:

 

1) using non standard / directly supported configurations (such as modifications to go file or use of 3rd party plugins)

 

2) upgrading from a much older version of unraid directly to 6.4

 

It appears the majority of folks running stock builds and that were on 6.3.5 have had little to no issues with the upgrade.

 

Please keep the feedback coming!!

 

After a hard crash will the diagnostics file show if a 3rd party plugin was the culprit of the freeze?

Share this post


Link to post
2 minutes ago, jrdnlc said:

 

Just copy the bz 6.3.5 files over to the flash drive correct?

Yes, they should be in the previous folder on your flash, then reboot.

Share this post


Link to post
8 hours ago, zin105 said:

Same problem with certificate. I had "set service dns forwarding options rebind-domain-ok=/unraid.net/" already in my config from the RC that I tried couple of months ago but it didn't work now for the stable release it seems. Edit: Works now all of a sudden!

 

Also, the self signed certificate signed for the CN "htpc.local" and redirected me to https://htpc.local when my FQDN actually is htpc.lan.

 

Right we 'hard code' TLD .local because that works for 98% of everyone on either PC or Mac.  In your case, you can use the command line to create your own self-signed cert and put it on your usb flash device with name:

config/ssl/certs/<server-name>_unraid_bundle.pem

Also please review the Help for Identification page.

Share this post


Link to post

So question maybe someone can help me understand better. I enabled the Https and all seems well.  

 

My question is say i get a new router or have to reset my current one and my LAN IP for my unRAID box changes. Right now i have it 192.168.1.222 say it changed to 192.168.1.54 or something.

 

How would the server communicate with unraid to notify there dns of a local ip change and to update the cert?

From what i read on the change long here:

 

Finally, we have included another background daemon that checks every 10 minutes for a change in your servers IP address. If your IP address changes, then the DNS A-record for your server is updated.

 

Am i understanding correctly that it will auto update after 10 min if the ip has been changed for some reason? I remember seeing if a previous post about 6.4 that you had to enter a command to reset the cert and the ip associated with it. Is that no longer the case?

 

Also does that mean i would lose access if limetech dns go down?

Edited by sourCream

Share this post


Link to post
11 minutes ago, Living Legend said:

After a hard crash will the diagnostics file show if a 3rd party plugin was the culprit of the freeze?

 

That is usually very hard to tell, but easy to test by starting in safemode.

 

Share this post


Link to post
1 minute ago, sourCream said:

My question is say i get a new router or have to reset my current one and my LAN IP for my unRAID box changes. Right now i have it 192.168.1.222 say it changed to 192.168.1.54 or something.

 

How would the server communicate with unraid to notify there dns of a local ip change and to update the cert?

The cert doesn't need to be changed because you get a new public IP.

 

And it isn't your public IP that matters - it's the IP of your unRAID device. The public DNS stores the local IP of your unRAID, so your browser will be able to translate from hostname to IP.

 

So the only thing happening outside of your own private network is the reporting of the unRAID IP to the public DNS. And asking that DNS for the local IP of your machine.

 

If the public DNS is down, then you need to enter the unRAID IP directly to reach your box, because the "magic" name that it got will not work.

Share this post


Link to post
1 minute ago, bonienl said:

 

That is usually very hard to tell, but easy to test by starting in safemode.

 

 

Okay.  I'll give this a try on the next crash then.  Assuming it does work, we can assume it's just a plugin and work off process of elimination, or is there a better method?

 

If anyone has had a chance to take a look at my logs, I'd be curious to see if there are any notable issues that could be causing this hard crash.

Share this post


Link to post
3 minutes ago, pwm said:

The cert doesn't need to be changed because you get a new public IP.

 

And it isn't your public IP that matters - it's the IP of your unRAID device. The public DNS stores the local IP of your unRAID, so your browser will be able to translate from hostname to IP.

 

So the only thing happening outside of your own private network is the reporting of the unRAID IP to the public DNS. And asking that DNS for the local IP of your machine.

 

If the public DNS is down, then you need to enter the unRAID IP directly to reach your box, because the "magic" name that it got will not work.

I'm aware it isnt the public ip that matters say the ip of the unraid device changes if i got a new router would i just go to the new ip and unraid would auto update the dns then? In regards to if the dns is down it sounds like it just defaults back to http when or if the lime tech servers cant be reached. 

Share this post


Link to post
1 minute ago, sourCream said:

would i just go to the new ip and unraid would auto update the dns

You are formulating that in the wrong order.

 

unRAID would auto-update the DNS within 10 minutes.

So if you then attempt to reach unRAID, you would go to the new IP because the DNS would point to the new IP.

The exception is if the IP has recently changed in the DNS - the DNS will specify a cache lifetime and the browser will remember the previous answer until the caching timeout.

 

unRAID doesn't know if the public DNS is down or not.

So unRAID will not change behavior just because the DNS is down.

It will be your browser that will fail to resolve the long, magic, hostname.

So you will have to manually enter the IP of your unRAID box to reach it.

Share this post


Link to post
7 minutes ago, sourCream said:

In regards to if the dns is down it sounds like it just defaults back to http when or if the lime tech servers cant be reached.

 

You are not talking directly to the Limetech server but to your DNS server. As long as the DNS server is able to resolve the name into an IP address, the GUI is accessible.

Worst case, e.g. when your Internet is down and resolving isn't possible then the GUI needs to be accessed with the corresponding IP address.

 

Share this post


Link to post
3 minutes ago, pwm said:

You are formulating that in the wrong order.

 

unRAID would auto-update the DNS within 10 minutes.

So if you then attempt to reach unRAID, you would go to the new IP because the DNS would point to the new IP.

The exception is if the IP has recently changed in the DNS - the DNS will specify a cache lifetime and the browser will remember the previous answer until the caching timeout.

 

unRAID doesn't know if the public DNS is down or not.

So unRAID will not change behavior just because the DNS is down.

It will be your browser that will fail to resolve the long, magic, hostname.

So you will have to manually enter the IP of your unRAID box to reach it.

That makes sense, thanks for taking the time to explain it. 

Share this post


Link to post
1 hour ago, Squid said:

I left that one alone due to your cert problems.  A status of unknown is where the system is unable to determine the available versions because it can't communicate with GitHub.com

 

I didn't have this problem before upgrade. I can browse github.com from all computers on my network, and I can ping github.com from the Unraid terminal window. No firewall logs related to the unraid server or github.com in pfSense either. Any ideas?

Share this post


Link to post
2 minutes ago, gar13 said:

 

I didn't have this problem before upgrade. I can browse github.com from all computers on my network, and I can ping github.com from the Unraid terminal window. No firewall logs related to the unraid server or github.com in pfSense either. Any ideas?

 

Do you have the button "Check for Updates" in the top right corner?

 

If yes, click on it and the latest status will be retrieved.

If no, click on the Plugins button and again it retrieves the latest status.

If in both cases the status remains "unknown" it means github couldn't be contacted.

Share this post


Link to post
5 hours ago, landS said:

Smoking!   The web Gui has always been a dog on my X7SPA-HF D525.  Now it is more responsive than even my fastest Unraid rig on any prior version.  Awesome work folks.

 

Running a backup script to this server now,  then will manually trigger mover followed by a dual-drive parity check.  I'll update if any snags are hit.

 

@garycase  I think the folks just injected some major life support for the atom... Thanks  @limetech  and @bonienl

 

@landS  Thanks for the heads up.   Just upgraded my D525 and the GUI is indeed VERY responsive.    Just kicked off a parity check to see if there's any improvement in that -- initial look doesn't seem promising (~ 50MB/s), but I'll leave it alone and see just how long it takes.    The slower data transfers and MUCH slower parity checks relative to v5 are frustrating, but something I've simply decided to live with.    It'd be neat if these got resolved at some point, but I doubt that will ever happen.    I routinely got over 100Mb data transfers with v5, and get ~ 75Mb with v6;  and the parity check times went from a bit over 8 hours to over 15 with v6 ... I'll see what 6.4 takes in about 15 hours :).    It's a bit frustrating that my 15TB server using 3TB WD Reds takes longer to do a parity check than my 48TB server with 8TB HGST NAS drives on an old C2SEA motherboard with a Pentium E5300.

 

But the simple fact is the slower data transfers and longer parity checks really don't matter -- and the MUCH better GUI responsiveness is REALLY nice with this new version.

Share this post


Link to post
5 minutes ago, bonienl said:

 

Do you have the button "Check for Updates" in the top right corner?

 

If yes, click on it and the latest status will be retrieved.

If no, click on the Plugins button and again it retrieves the latest status.

If in both cases the status remains "unknown" it means github couldn't be contacted.

 

No Check for updates button in the right hand corner on the Plugins page at all. Reloading the page takes a while, but still shows unknown.  

Share this post


Link to post
1 minute ago, gar13 said:

 

No Check for updates button in the right hand corner on the Plugins page at all. Reloading the page takes a while, but still shows unknown.  

 

Open a terminal window and type

ping 8.8.8.8

(ctrl-C to break)

Share this post


Link to post

Updated from 6.3.5 to 6.4.0 and it was pretty painless. 

 

I clicked the update prompt at the bottom, then manually rebooted.  It seemed to boot back up in 6.3.5 once, then the server disappeared shortly after, then when it came back it was 6.4.0.  I wasn't in the same room as the server to hear when it actually rebooted.

 

So one confusing bit, but otherwise it worked well.

 

Thanks!

Share this post


Link to post

Noted the following on 6.4:

 

=> On the Plugins page, clicking "Check for Updates" does a check, but after it's done still shows Status: Unknown for my only plugin (Dynamix Cache Directories)

 => On the new "OS Update" page in Tools, clicking "Check for Updates" does a check, but it also shows Status: Unknown after the check.

 

 

Share this post


Link to post
Guest
This topic is now closed to further replies.