johnodon Posted June 11, 2013 Share Posted June 11, 2013 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 Quote Link to comment
PeterB Posted June 11, 2013 Share Posted June 11, 2013 ... the only reason I install UnMenu is for this & the related CleanPowerDown package You don't need unmenu for this - there is a stand-alone plugin version, which I intend to re-release with a fix for the log rotation problem. Quote Link to comment
sacretagent Posted June 11, 2013 Share Posted June 11, 2013 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 Quote Link to comment
DMAddict Posted June 11, 2013 Share Posted June 11, 2013 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 Quote Link to comment
NAS Posted June 11, 2013 Share Posted June 11, 2013 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 Quote Link to comment
garycase Posted June 11, 2013 Share Posted June 11, 2013 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. Quote Link to comment
freekie Posted June 11, 2013 Share Posted June 11, 2013 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. Quote Link to comment
mejutty Posted June 11, 2013 Share Posted June 11, 2013 Give this bug is in the official bug list with a reply from limetech saying that he has been able to reproduce it and investigating I am not sure it has anything to do with a plugin?? Quote Link to comment
tr0910 Posted June 11, 2013 Share Posted June 11, 2013 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.... Quote Link to comment
WeeboTech Posted June 11, 2013 Share Posted June 11, 2013 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. Quote Link to comment
Pauven Posted June 11, 2013 Share Posted June 11, 2013 +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 Quote Link to comment
drawz Posted June 11, 2013 Share Posted June 11, 2013 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. Quote Link to comment
Joe L. Posted June 11, 2013 Share Posted June 11, 2013 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) Quote Link to comment
WeeboTech Posted June 11, 2013 Share Posted June 11, 2013 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. Quote Link to comment
tr0910 Posted June 11, 2013 Share Posted June 11, 2013 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. syslog_2013-06-11_14.46.zip Quote Link to comment
disco Posted June 11, 2013 Share Posted June 11, 2013 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. Quote Link to comment
Recommended Posts
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.