unRAID Server Release 5.0-rc13 Available

[syntaxx]

I upgraded to rc13 while the wiki says that when I reboot it should say Configuration Invalid. While on my upgrade the array started automatically. Are there something wrong? Thanks

 

Guys can someone answer this please? I am getting nervous.

The wiki is out of date.  Do not stress over it.

 

Thanks Joe!

[syntaxx]

Ok this is the first problem I encountered with 5.0-rc13. It works no doubt. But the emhttp doesn't seem to respond when I visit the page. I checked the logs and can't see anything unusual.

[Joe L.]

Ok this is the first problem I encountered with 5.0-rc13. It works no doubt. But the emhttp doesn't seem to respond when I visit the page. I checked the logs and can't see anything unusual.

Three questions:

What URL are you using to access emhttp?   

Can you access it by IP address?

Have you disabled ALL the add-ons you might have added?

 

Open a thread in the rc support forum, attach a zipped copy of your syslog.

 

Joe L.

[Zaxxan]

Has this release added an additional data drive to the PLUS version? I now have the option for 1 Parity, 6 Data and 1 Cache drive.

[syntaxx]

Ok this is the first problem I encountered with 5.0-rc13. It works no doubt. But the emhttp doesn't seem to respond when I visit the page. I checked the logs and can't see anything unusual.

Three questions:

What URL are you using to access emhttp?   

Can you access it by IP address?

Have you disabled ALL the add-ons you might have added?

 

Open a thread in the rc support forum, attach a zipped copy of your syslog.

 

Joe L.

 

I always use ip address when accessing the emhttp since I am mostly using my ipad to access it. Though unmenu works quite well. I will try to remove all addons and reboot

[lishpy]

Has this release added an additional data drive to the PLUS version? I now have the option for 1 Parity, 6 Data and 1 Cache drive.

 

Yes. Tom stated that in 5.0 final the PLUS version would gain one drive.

[Zaxxan]

Oh good. I must have missed his comment when he said that.

[limetech]

...This seems to be fixed in the linux 3.9.x kernel series...

 

I notice you used 3.9.3.  Just curious if there's a particular reason not to use 3.9.4 (24-May-2013)

Didn't want to delay the release.  The kernel will get updated in the next unRaid patch release.

[limetech]

Thats fantastic, looking forward to the final release.

 

I take it that ipv6 support is not going to make 5 final if no other major additions are to come? I saw it in IssueList for version 5.x

Right, didn't want to delay the release further since this will involve a lot of extra testing.

[limetech]

Second main issue this addresses is NFS stale file handles.  If you want to use NFS with user shares, then you need to do some set up explained here:

http://lime-technology.com/wiki/index.php?title=Plugin/webGui/NFS

 

There is a better fix for this which will go into a future release.

 

I guess that I need to wait for the 'better' fix, then!  In the meantime I will revert to RC10.

 

I ran one mkvmerge from my 'Torrent' user share to my 'Movies' user share then went to open the 'Movies' share in Nautilus - this resulted in a 'stale nfs file handle' report.

 

I still don't understand why this problem was absent between rc4 and rc10, but returned in rc11.

Please follow directions here, make "stale file handle" happen, and then post your system log.

http://lime-technology.com/wiki/index.php/Plugin/webGui/NFS

Note: I forgot to mention in these instructions to stop/start the array after creating the extra.cfg file in order for the change to take effect.

[limetech]

Second main issue this addresses is NFS stale file handles.  If you want to use NFS with user shares, then you need to do some set up explained here:

http://lime-technology.com/wiki/index.php?title=Plugin/webGui/NFS

 

There is a better fix for this which will go into a future release.

 

I guess that I need to wait for the 'better' fix, then!  In the meantime I will revert to RC10.

 

I ran one mkvmerge from my 'Torrent' user share to my 'Movies' user share then went to open the 'Movies' share in Nautilus - this resulted in a 'stale nfs file handle' report.

 

I still don't understand why this problem was absent between rc4 and rc10, but returned in rc11.

i have this same issue, extra config parametrs does not help to much

(also with ubuntu, old or new one, and even from ubuntu side force to use nfsv3 also dont help)

Please follow directions here, make "stale file handle" happen, and then post your system log.

http://lime-technology.com/wiki/index.php/Plugin/webGui/NFS

Note: I forgot to mention in these instructions to stop/start the array after creating the extra.cfg file in order for the change to take effect.

[Hitcher]

Second main issue this addresses is NFS stale file handles.  If you want to use NFS with user shares, then you need to do some set up explained here:

http://lime-technology.com/wiki/index.php?title=Plugin/webGui/NFS

I'm confused by this as I have NFS enabled but don't have any users other than root.

 

Do I need to do anything?

 

Thanks.

user shares = You creating a share like "Movies", "TV Shows", "Data", etc... then yes read and apply whats in the notes

If you are only using Disks; like Disk#1, Disk#2 directly, then is seems like no you would not have to do anything.

Thanks for the clarification.

[limetech]

A wierd thing in rc13 that smells like a bug...

 

When I issue one `sync` command from a bash script or something, unRaid wakes up all sleeping disks, and writes something to ALL disks. Not only that, but it keeps on writing small writes to all disks without end. Pressing the Refresh button on the web-gui a few times, and I see how the write counters keep increasing on all disks. Nothing shows in the syslog.

 

I waited for awhile, and when the writes didn't stop, I freaked out and shut down the server.  Upon restart everything was normal, until I opened a telnet session and issued a `sync` command -- the same infinite writes started again.

 

Now, I believe I've seen that strange behaviour when sync wakes up all sleeping disks in a previous beta, But I've never seen those writes that never stop writing -- that really bothers me. Can someone try to reproduce this?

Yes I can confirm this behavior.  This is probably (99%) a linux kernel bug.  If you Stop/Start the array the behavior stops.  I'll need to look into this.  In meantime, don't issue 'sync' from the command line 

[limetech]

A wierd thing in rc13 that smells like a bug...

 

When I issue one `sync` command from a bash script or something, unRaid wakes up all sleeping disks, and writes something to ALL disks. Not only that, but it keeps on writing small writes to all disks without end. Pressing the Refresh button on the web-gui a few times, and I see how the write counters keep increasing on all disks. Nothing shows in the syslog.

 

I waited for awhile, and when the writes didn't stop, I freaked out and shut down the server.  Upon restart everything was normal, until I opened a telnet session and issued a `sync` command -- the same infinite writes started again.

 

Now, I believe I've seen that strange behaviour when sync wakes up all sleeping disks in a previous beta, But I've never seen those writes that never stop writing -- that really bothers me. Can someone try to reproduce this?

 

I just noticed three more wierd things about this RC, that may all be somehow connected.

 

1) ^^ (my previous post above) ^^

 

2) When I stop the array from the web-gui, then every time I press the refresh button it creates a flury of activity in the syslog. Upon inspection, it appears that pressing the Refresh button causes the server to: unload all disks, unload the md driver, reload the md driver, reload all disks, r4efresh the gui. Truly amazing! That can't possibly be by design.

 

3) I decided to capture the syslog output to hard disk in order to see what happens when I press the powerdown button. And indeed, a funny thing happens: The server unloads all disks, unloads the md driver, then reloads the md driver again, reloads all disks, then unloads all disks yet again, unloads the md driver again, and then goes for powerdown. That's quite an OCD way to turn off the lights!

 

4) Despite having selected all options telling unRaid to not engage in any disk spun up / spin down, there's plenty of entries in syslog saying "spinning up all disks. I really wish the server doesn't bother with any spinning up or down if I chose so in the settings.

 

More tests to come.

That's all normal.

[limetech]

I upgraded to rc13 while the wiki says that when I reboot it should say Configuration Invalid. While on my upgrade the array started automatically. Are there something wrong? Thanks

 

Guys can someone answer this please? I am getting nervous.

Probably not.  Are you upgrading from 4.7?

[peter_sm]

@Tom

 

Please see this -> http://lime-technology.com/forum/index.php?topic=10978.msg244868#msg244868

 

Is there something removed from RC13? works fine on RC12 ;-)

 

Thanks

 

Peter

[Ice_Black]

@Tom

 

Im not sure if this is UnRAID bug, see http://lime-technology.com/forum/index.php?topic=27654.0

[hawihoney]

I do have lots of problems with this new RC13 on my two original LimeTech machines. Whenever I try to stop an array it hangs. Plugins (Subsonic, BitTorrent Sync) are not stopped and even if I kill these processes shutdown will not go on. /sbin/shutdown does nothing. The machine is still running after /sbin/shutdown and I need to push the power button to stop that machine. RC12a was running happily since its appearance.

 

The second machine is completely silent. It came up and after some time I saw spinup/spindown messages flooting my putty console. The machine is dead currently.

 

I do hope they come up with a parity check and I will go back to RC12a then. I hope I can go back ...

 

Regards

 

EDIT: Both machines came up with a parity check. No logs because of the hard reset buttons. I did copy RC12a to both flashs immediately. Puh, I'm to old for this ;-)

 

[limetech]

Has this release added an additional data drive to the PLUS version? I now have the option for 1 Parity, 6 Data and 1 Cache drive.

LOL yep that snuck through, it will be corrected in next release.  Explanation: this release -rc13 had all the code in place to support "cache pool", that is, you can assign a storage device (HDD or SDD) to either the "array" or to the "pool".  In addition you could configure the "pool" to use btrfs as the file system.  So if you want, you could assign all disks to array, or all disks to pool or some combination of both.

Unfortunately, this resulted in quite a few changes to the webGui which broke a number of plugins, particularly Simple Features.  So I've ripped all that out until I can coordinate with plugin authors.  This was an "executive decision" that delayed the release by at least a week.

[lainie]

I am receiving the same errors as peter_sm when trying to compile headers to make a VirtualBox package. The errors occur at the "make oldconfig" command. I have attached a log showing each step from a fresh boot up to "make oldconfig && make" in the same thread VirtualBox for unRAID.

[JonathanM]

I do have lots of problems with this new RC13 on my two original LimeTech machines. Whenever I try to stop an array it hangs. Plugins (Subsonic, BitTorrent Sync) are not stopped and even if I kill these processes shutdown will not go on. /sbin/shutdown does nothing. The machine is still running after /sbin/shutdown and I need to push the power button to stop that machine.

In all the flurry of activity, I suppose it's understandable that you missed it, but you should NEVER upgrade a machine with addons active. You must disable ALL addons, and preferably you should do a parity check before you upgrade, so you know all your drives are healthy. Best bet at this point would be to go back to 12a and get back stable with no addons, then try the upgrade, and confirm you have a stable working machine with no addons before you start installing things again. It's likely the addon authors will need to make changes to be compatible with any new release.

[Joe L.]

preferably you should do a parity check before you upgrade, so you know all your drives are healthy..

And, you should REBOOT with the old release before upgrading.

 

So many of the issues I've been seeing with either the array not stopping, OR the array not completing startup are because of a plugin or add-on that will either not allow shut down or start-up.  If your current handling of start-u or shut down is flawed, no sense upgrading until AFTER you've disabled the plugin/addon and can cleanly stop the arrray/reboot correctly.

[limetech]

A wierd thing in rc13 that smells like a bug...

 

When I issue one `sync` command from a bash script or something, unRaid wakes up all sleeping disks, and writes something to ALL disks. Not only that, but it keeps on writing small writes to all disks without end. Pressing the Refresh button on the web-gui a few times, and I see how the write counters keep increasing on all disks. Nothing shows in the syslog.

 

I waited for awhile, and when the writes didn't stop, I freaked out and shut down the server.  Upon restart everything was normal, until I opened a telnet session and issued a `sync` command -- the same infinite writes started again.

 

Now, I believe I've seen that strange behaviour when sync wakes up all sleeping disks in a previous beta, But I've never seen those writes that never stop writing -- that really bothers me. Can someone try to reproduce this?

Yes I can confirm this behavior.  This is probably (99%) a linux kernel bug.  If you Stop/Start the array the behavior stops.  I'll need to look into this.  In meantime, don't issue 'sync' from the command line 

 

You are kidding, right? I honestly hope you are.

 

That `sync` waking up all disks, and writing to all disks, is not new for this RC. I've raized the question before. Only the "never-ending-writes" are new for RC13.

It's perfectly normal and expected that a 'sync' issued from the command line will spin up all the mounted drives.  What's it's doing is writing out super-block info which is going to spin the drives up.  The new behavior of continuously flushing data that's already been flushed is most probably a kernel bug.  I say this because the 'kworker' threads are the ones doing the writing and it stops when the disk(s) get un-mounted.

 

See, if emhttp has never been started, the sync command would never unnecessarily wake up any spun-down disks. It normally flushes only what needs flushing.  But when you start emhttp & mdmod, a sync command starts causing writes to ALL disks. I find that strange. If you don't believe me, just boot into a previous beta, issue a sync, and then refresh the gui with the write counters.

Startup of emhttp and/or md-mod doesn't issue any syncs.

[WeeboTech]

That `sync` waking up all disks, and writing to all disks, is not new for this RC. I've raized the question before.

 

It's normal that a sync will wake up all disks in standby and write something to each.

Any dirty blocks are written and there is filesystem housekeeping that occurs.

I.E. time fields in the superblock are updated.

 

If the disk is mounted, it will be woken. unmounted disks outside of the array will (should) be left alone.

 

On my arrays, I've always known that a sync at the command line will wake up all disks.

It's a behaviour I've seen over and over again.

 

Only the "never-ending-writes" are new for RC13..

 

This is a bonafide bug and concerns me.

[hawihoney]

And, you should REBOOT with the old release before upgrading.

 

My machines are off during night, they were booted just some minutes ago. These two plugins, ok, my fault. I thought between RC12a and RC13 it would work.

 

I need to wait for the parity check (50 hours to go). So in three days I can reboot with RC12a and try again without these two plugins...

 

Regards