unRAID Server Release 5.0-rc13 Available


Recommended Posts

OK...the NFS issue with OpenELEC/XBMC and unRAID RC13 seems to be resolved.

 

OpenELEC posted an update (v3.05) which addresses some NFS issues.  I updated both of my OpenELEC boxes (one ION and one Fusion) to v3.05 and also updated unRAID to RC13.  Both OpenELEC boxes can now access the unRAID NFS shares without issue.

 

Funny how OpenELEC v3.03 works with unRAID RC12a and OpenELEC v3.05 works with unRAID RC13.  Talk about a perfect storm.  :)

 

John

Link to comment
  • Replies 341
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

as promised my syslog from last nights experiment

don't see much difference between them (with powerdown script and without) but you guru's have a crack at it

 

Joe,

 

what would be the command equal to pressing the stop button on the gui ?

was thinking of using this in my cron

 

1. swapoff -a

wait 5 minutes

2. use that stop command

wait 5 minutes

3. /usr/local/sbin/unraid_powerdown

 

while we wait for a good guy to update the powerdown script

syslog11062013.zip

Link to comment

Just wanted to drop a note to give a big thanks to Tom and all the others that make Unraid so great. My Unraid server has been running solid for 4 years now and am greatful for the low maintenance reliability while having the utmost confidence in the protection of my files.

-Thank you

Link to comment

Just wanted to drop a note to give a big thanks to Tom and all the others that make Unraid so great. My Unraid server has been running solid for 4 years now and am greatful for the low maintenance reliability while having the utmost confidence in the protection of my files.

-Thank you

 

I think you have just voiced the opinion of the silent majority. This is what keeps me with unRAID so kudos

Link to comment

Just wanted to drop a note to give a big thanks to Tom and all the others that make Unraid so great. My Unraid server has been running solid for 4 years now and am greatful for the low maintenance reliability while having the utmost confidence in the protection of my files.

-Thank you

 

I think you have just voiced the opinion of the silent majority. This is what keeps me with unRAID so kudos

 

+1  Rock solid, stable, and just works.    Virtually all of the issues noted on this forum (certainly the vast majority) are caused by add-ons ... NOT by the core functionality.

 

Link to comment

I totally agree.  The last 12 release candidates were rock solid for me and any of them could have gone to final.

 

However some of us are having a genuine problem with the lockup on shutdown issue. This happens on a number of peoples systems with no plugins installed. It is a genuine issue and just because you don't suffer from it doesn't mean that is not there.

 

I am surprised at some of the people who are complaining. I would have expected better from you.

Link to comment

Oh and by the way, running the offending script without the rsync component now fails with a "Kernel panic" 

Before killing the powerdown command this worked fine.

Things are getting worse not better....  :-)

you are indeed linked to the stock unRAID powerdown.

 

After 2 runs through this offending script without the unmenu Powerdown now script, and reverting to stock unRaid, I have had success.

 

Before it would never fail on the script without the heavy duty rsync commands, but would always fail when run with them.  It has just been through  both without failure.  Go figure....

Link to comment

There seems to be an issue with the kernel and the mount/unmount functionality in some kernels.

The scripts, either of them, seem to trigger this issue more.

 

With the powerdown script, the syslogs seem to show that emhttp does not like having the filesystems unmounted anymore.  Granted it's probably not the best thing to do, in any case, we'll need to revisit the tool.

 

 

Link to comment

+1  Rock solid, stable, and just works.    Virtually all of the issues noted on this forum (certainly the vast majority) are caused by add-ons ... NOT by the core functionality.

In the market for small home NAS solutions, people are looking for certain capabilities, which in unRaid's case are possible only through add-ons. So the way you draw the line what's "core functionality" makes the difference between people buying your product or somebody else's.

 

In a similar fashion, many people buy Ford Mustangs because they can acquire certain capabilities through add-ons.  While Ford doesn't prevent you from bolting on a Roush supercharger in your garage using your limited selection of tools, they would certainly balk at your complaints of a rough idle and stalling once they saw your handiwork.  Ford doesn't test their product with 3rd party add-ons, nor can they support them, even though they are in the business of providing a platform that allows them.  So who should you turn to for support of your supercharger?  The 3rd party manufacturer, Roush in this example.

 

When Tom makes a new version of unRAID, he doesn't test with 3rd party add-ons either, and any expectation that he should do so is flawed.  Tom is being a really good sport about plug-ins and add-ons, allowing users to post issues in the RC threads that are technically not unRAID issues but 3rd party add-on issues.  Unfortunately this is muddying up the waters, making it difficult to determine how good RC13, Bone Stock, really is.

 

If you are not the author of a 3rd party add-on, you really have no business reporting issues in this thread when you are running them.  Instead, any issues you have with RC13 while running add-ons should be reported directly to the add-on's author (Joe L., WeeboTech, etc...).  In turn, only those authors should be the ones reporting add-on issues to Tom.

 

And that is really the limit to which Tom's/Lime-Tech's obligations should extend, supporting end users of stock unRAID, and supporting authors of plug-ins/add-ons, but not the end users of said plug-ins/add-ons.

 

Things to keep in mind:

  • Even though Tom has created a plug-in system,  he has not delivered an all-encompassing API.  What that means is that while 3rd-party authors can plug their code into unRAID, much of their code is operating outside the bounds of unRAID, using features and functionality that is part of the underlying Linux OS, and not actually unRAID functionality.  Because the authors are working outside of an established API, they can do some amazing, and crazy, things - much of which might be harmful to unRAID or Linux or both.
     
  • Certain things being discussed in this thread technically aren't plug-ins or add-ons, but all-out code replacements.  The powerdown script is the perfect example of a code replacement:  it renames an unRAID script to disable it, and completely replaces the code with its own code.  Think about it, we're actually ripping out Lime-Tech's code, replacing it with someone else's 4-year old code, and we have the gall to show up here and complain about poor unRAID stability.

 

I do agree that it would be beneficial to all if Tom could provide a 'Safe-Mode' boot option, allowing all users to easily test unRAID beta and release candidates without incompatible plug-ins/add-ons/code-replacements.  On the flip side, if you're not capable of booting stock-unRAID, perhaps you shouldn't be running these RC's.  Think about it:  this is brand new unRAID code, new to even the authors of the add-ons, and their code may not have been updated in years, much less for the most recent RC that came out mere days ago.

 

In the meantime, perhaps Tom can open two threads for RC14:  one for RC14 Bone Stock, and one for RC14 with Add-Ons, and require logs to be posted with all issue reports, and delete/move all posts in the Bone Stock thread that show add-ons have been used.

 

I've said my piece. Thanks for reading...

-Paul

Link to comment

Another vote for a "safe boot" mod, which would make it easier for everyone to test RCs in a clean environment (or even troubleshoot later on).

 

A clear cut API for add-ons would certainly help, but maybe should wait for 5.1 at this point.

I like the idea of it being triggered by the presence of a "flag" file on the flash drive OR a boot menu option. 

(Easiest for inexperienced users to set the flag)

Link to comment

Another vote for a "safe boot" mod, which would make it easier for everyone to test RCs in a clean environment (or even troubleshoot later on).

 

A clear cut API for add-ons would certainly help, but maybe should wait for 5.1 at this point.

I like the idea of it being triggered by the presence of a "flag" file on the flash drive OR a boot menu option. 

(Easiest for inexperienced users to set the flag)

 

A boot menu option could be detected by /etc/rc.d/rc.local or it could detect a flag file in /boot.

It means that Tom needs to add this to the /etc/rc.d/rc.local script.

 

I've tested this before and it worked for my personal installation.

I had a debug and safe keyword.

 

It was also suggested here.

http://lime-technology.com/forum/index.php?topic=25609.msg225763#msg225763

 

I like the keyword safe

 

I suppose we could have keywords such as

noextra

noplugins

nogo

 

Probably something we should fork() off to another thread. ;)

Link to comment

Oh and by the way, running the offending script without the rsync component now fails with a "Kernel panic" 

Before killing the powerdown command this worked fine.

Things are getting worse not better....  :-)

you are indeed linked to the stock unRAID powerdown.

 

After 2 runs through this offending script without the unmenu Powerdown now script, and reverting to stock unRaid, I have had success.

 

Before it would never fail on the script without the heavy duty rsync commands, but would always fail when run with them.  It has just been through  both without failure.  Go figure....

 

After running 10+ runs of that offending script, I finally got it to fail without the powerdown now from unMenu.  Here is the log and the final screen.

IMG_20130611_144257.jpg.b74916ed0a33ce77567a25ab8236b6c8.jpg

syslog_2013-06-11_14.46.zip

Link to comment

Maybe this has already been reported, but I had to manually stop and then start AFP to be able to connect to the shares via my Mac after upgrading to -rc13. I haven't restarted unRAID since upgrading, so not sure if this is a requirement upon each reboot.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.