dangil Posted February 16, 2012 Share Posted February 16, 2012 I had another "BUG: unable to handle kernel NULL pointer dereference" when stopping the array. but this time I didn't have my LSI controller installed. Only hardware installed is the X8SIL-V motherboard, CPU, 4GB RAM, 3x2tb seagate HDs, 3 1.5tb seagate HD lets hope the 5.0 final doesn't have this issues syslog.zip Quote Link to comment
rainmaker002 Posted February 19, 2012 Share Posted February 19, 2012 I don't think I've changed much with my unraid server after updating it to b14 (from 4.7), and installing sabnzd. I was messing around with the config for it (sab), and then rebooted after it hung on "enable". Now, unraid won't start the array. It just hangs on "Starting...". I've left it for 5+ hours with no luck. Any advice? syslog-2012-02-18.txt Quote Link to comment
Joe L. Posted February 19, 2012 Share Posted February 19, 2012 I don't think I've changed much with my unraid server after updating it to b14 (from 4.7), and installing sabnzd. I was messing around with the config for it (sab), and then rebooted after it hung on "enable". Now, unraid won't start the array. It just hangs on "Starting...". I've left it for 5+ hours with no luck. Any advice? yes. Disable your add-on. Others have had exactly the same issue. The add-on is keeping the array from starting by attempting to access the disks before they are mounted. The solution is to delay the start of the add-ons until AFTER the array is on-line. Quote Link to comment
PeterB Posted February 19, 2012 Share Posted February 19, 2012 The solution is to delay the start of the add-ons until AFTER the array is on-line. Is there a recommended way of testing for the array being online? Some of my addons access the cache drive, and I have a little script which I use to wait for the cache drive coming ready: #!/bin/bash #################################################################################### # wait_cache # A simple utility to suspend further processing until the cache drive comes online. # # Version 1.0 based on snippet of code taken from Joe L's cache_dirs # # Peter Bell. #################################################################################### let count=120 let interval=2 while [ ! -d /mnt/cache -a $count -gt 0 ] do # Wait for the drive to come online sleep $interval let count=count-interval done if [ $count -le 0 ] then exit 1 fi exit 0 However, I still get occasional failures, I suspect because the apps do access other array drives. Should I just use the same test on drive1? Quote Link to comment
rainmaker002 Posted February 19, 2012 Share Posted February 19, 2012 I don't think I've changed much with my unraid server after updating it to b14 (from 4.7), and installing sabnzd. I was messing around with the config for it (sab), and then rebooted after it hung on "enable". Now, unraid won't start the array. It just hangs on "Starting...". I've left it for 5+ hours with no luck. Any advice? yes. Disable your add-on. Others have had exactly the same issue. The add-on is keeping the array from starting by attempting to access the disks before they are mounted. The solution is to delay the start of the add-ons until AFTER the array is on-line. Unfortunately I'm not sure how to do this- my Go script is quoted below. I see a reference to a delay but I'm not sure how to actually make addons wait (they're all installed via unmenu). #!/bin/bash # Start the Management Utility /usr/local/sbin/emhttp & # Wait for the array to start... (before installing any packages that expect the array to be fully started) until `cat /proc/mdcmd 2>/dev/null | grep -q -a "STARTED" ` ; do echo ">>>waiting..." ; sleep 1 ; done ; echo ">>>STARTED." # Enable one of these at a time /boot/unmenu/uu /boot/packages/cache_dirs -w cd /boot/packages && find . -name '*.auto_install' -type f -print | sort | xargs -n1 sh -c Quote Link to comment
Electric Posted February 19, 2012 Share Posted February 19, 2012 Try "sleep 60" to make the script wait for 60 seconds. Quote Link to comment
PeterB Posted February 19, 2012 Share Posted February 19, 2012 # Wait for the array to start... (before installing any packages that expect the array to be fully started) until `cat /proc/mdcmd 2>/dev/null | grep -q -a "STARTED" ` ; do echo ">>>waiting..." ; sleep 1 ; done ; echo ">>>STARTED." Your command script would appear to be waiting for the array to start before launching any addons. However, I suspect that it is this which is causing a problem ... my guess is that 'STARTED' used to appear in /proc/mdcmd under v4.x, but that the string is altered under v5.x and that is making the script wait forever. Yes, confirmed, the text 'STARTED' does not appear anywhere in my mdcmd. So, back to my earlier question ... is there a recommended way to test for the array being started? Quote Link to comment
BRiT Posted February 20, 2012 Share Posted February 20, 2012 After some examination, the "mdState" variable is indeed set to STARTED under the 5.0.x beta series, at least using beta12 flavor, so what was posted should indeed work. If you want to validate this, you need to remove the -q parameter if you're simply inspecting standard out. cat /proc/mdcmd 2>/dev/null | grep -a "STARTED" Typical output is: "mdState=STARTED" Here's what I'm using now, after slight tweaks to include a maximum wait period before moving on. # wait for all disks to be mounted, or until timed out... max_wait=30 total_wait=0 sleep_delay=5 while [ : ] do found=`cat /proc/mdcmd 2>/dev/null | grep -a "STARTED" | wc -l` [ $found -gt 0 ] && break [ $total_wait -gt $max_wait ] && break sleep $sleep_delay (( total_wait += $sleep_delay )) done Quote Link to comment
perrin Posted February 20, 2012 Share Posted February 20, 2012 The solution is to delay the start of the add-ons until AFTER the array is on-line. Is there a recommended way of testing for the array being online? Some of my addons access the cache drive, and I have a little script which I use to wait for the cache drive coming ready: I am using the emhttp events to start items that require the array be online when they start. If you look at /boot/custom/emhttp_event/event, there are sections for different array 'states' case $1 in disks_mounted) /boot/packages/twonkymedia-i386-glibc-2.2.5-6.0.38.sh ;; svcs_restarted) if ! ps -ef|grep twonkymedia|grep -v grep; then cd /usr/local/twonkymedia/ /usr/local/twonkymedia/twonkymedia.sh start fi ;; unmounting_disks) if ps -ef|grep twonkymedia|grep -v grep; then /usr/local/twonkymedia/twonkymedia.sh stop fi ;; *) logger -t Event\ Script Incorrect\ Argument ;; esac HTH Rob Quote Link to comment
krisha Posted February 23, 2012 Share Posted February 23, 2012 Hope this is the right thread. Two bugs (posted also on seperate threads): 1) On clearing a new disk the webGUI is not available 2) I saw on local screen "run_cmd.... share_size" as login, probably after setting include disks to "disk1 disk2" or after clearing and formatting finished. Quote Link to comment
BRiT Posted February 23, 2012 Share Posted February 23, 2012 Two bugs (posted also on seperate threads): 1) On clearing a new disk the webGUI is not available On point 1, that functions as designed and is technically not a bug. It's how unRAID has always functioned as far as I can tell. That is why the community created the preclear_disks tool. Quote Link to comment
krisha Posted February 24, 2012 Share Posted February 24, 2012 On point 1, that functions as designed and is technically not a bug. It's how unRAID has always functioned as far as I can tell. That is why the community created the preclear_disks tool. Hm ok, so it's kind of protection. But should be changed, maybe replace the endless waiting with an output "Currently clearing disks, estimated finished in xx min. Do NOT power off.". New users might think that the system is stuck and just force a reboot. Quote Link to comment
Joe L. Posted February 24, 2012 Share Posted February 24, 2012 The unrAID display used to not freeze on earlier releases. It did not refresh itself, but upon refresh would let you know of the progress in the clearing step. I think it is a bug in that the web-interface freezes. Joe L. Quote Link to comment
MikeL Posted February 28, 2012 Share Posted February 28, 2012 So tomorrow will be day 100 since the last beta, (That was called b14, but in reality it was more like b21 or so! beta 8 had something like 5 different beta releases, and many others had 2+ each) Are we ever going to see a final release? 2 years in beta with 20+ releases is not good at all! Quote Link to comment
dgaschk Posted February 28, 2012 Share Posted February 28, 2012 What's not good about it? My data is safe running version 4.7. I would rather wait though 100 beta releases than put my data at risk with an imperfect release. Why are you in such a hurry? Quote Link to comment
jbartlett Posted February 28, 2012 Share Posted February 28, 2012 There's quirks that need to be worked out at the hardware level which involve drivers and the linux kernel. Thus Tom is at the mercy of other teams. I've been running the betas since b11 and it's been totally stable for me. Currently on b13 - didn't need to upgrade to b14 which was only a kernel change. Quote Link to comment
BRiT Posted February 29, 2012 Share Posted February 29, 2012 What's not good about it? Beta 13 and Beta14 are completely broken beyond repair if you have the very popular LSI SATA Controller; when the drives spin-up after being spun-down they suffer from thousands of phantom read failures that red-balls the drives and drops them out of the array. In reality there is no problem at all with the drives. To fix the LSI issue, if you take the new code (the md drivers, emhttp and all the other installed packages) and place it on the older Linux Kernel 3.0.x then everything is stable. However, the Beta13/Beta14 used the newer Linux Kernel 3.1/3.2 for some reason that I can't recall right now, maybe it was an attempt to try and fix the other major issues with the NFS feature. Quote Link to comment
dimaestro Posted March 1, 2012 Share Posted March 1, 2012 It made the Marvell Controller, the SUPERMICRO AOC-SASLP-MV8 not be broken. This is the main one I know about. I'm happy that my SUPERMICRO AOC-SASLP-MV8 isn't broken. Quote Link to comment
Auggie Posted March 1, 2012 Share Posted March 1, 2012 It made the Marvell Controller, the SUPERMICRO AOC-SASLP-MV8 not be broken. This is the main one I know about. I'm happy that my SUPERMICRO AOC-SASLP-MV8 isn't broken. Have you put a 3TB+ drive on the SASLP? I read reports that there maybe issues on some mobo's with this setup. I have the same mobo model as yours and only have 2TB drives on the SASLP. Quote Link to comment
Alex R. Berg Posted March 1, 2012 Share Posted March 1, 2012 I have discovered that if a split is defined (say at 2) for a share, then cache free-min-space is ignored for directories above the split-level (eg levels 3,4,5,...) if those directories already exists on the cache drive. This permits the cache drive to be filled up, ignoring the min-free-space. See this post for details: "Cache fills up if writing files to new dir above split level": http://lime-technology.com/forum/index.php?topic=18729.msg167497 I think it is a bug. Either that or very unfortunate 'feature'. Regards, Alex Quote Link to comment
Joe L. Posted March 1, 2012 Share Posted March 1, 2012 I have discovered that if a split is defined (say at 2) for a share, then cache free-min-space is ignored for directories above the split-level (eg levels 3,4,5,...) if those directories already exists on the cache drive. This permits the cache drive to be filled up, ignoring the min-free-space. See this post for details: "Cache fills up if writing files to new dir above split level": http://lime-technology.com/forum/index.php?topic=18729.msg167497 I think it is a bug. Either that or very unfortunate 'feature'. Regards, Alex Sounds like a bug to me... report to tomm@lime-technology Quote Link to comment
evans036 Posted March 1, 2012 Share Posted March 1, 2012 What's not good about it? My data is safe running version 4.7. I would rather wait though 100 beta releases than put my data at risk with an imperfect release. Why are you in such a hurry? i somewhat agree. but when a product languishes that long, it may indicate deeper problems like: is limetech as commited to unraid as they once were. perhaps they have a buyer for it. i just seems odd that that it has taken THIS long for a new production grade version to be released. especially when viewed in the light of the turnaround of prev releases. hopefully i am dead wrong steve Quote Link to comment
WeeboTech Posted March 1, 2012 Share Posted March 1, 2012 What's not good about it? My data is safe running version 4.7. I would rather wait though 100 beta releases than put my data at risk with an imperfect release. Why are you in such a hurry? i somewhat agree. but when a product languishes that long, it may indicate deeper problems like: is limetech as commited to unraid as they once were. perhaps they have a buyer for it. i just seems odd that that it has taken THIS long for a new production grade version to be released. especially when viewed in the light of the turnaround of prev releases. hopefully i am dead wrong steve I think the problem is wider then limetech's scope. From my perspective, the root problem is more of kernel driver issues, something lime-tech relies on external support for. Quote Link to comment
pras1011 Posted March 1, 2012 Share Posted March 1, 2012 Yes but he should tell us that instead of coming online having a look at what we have written and then disappering again!! Takes a few minutes to update us on what hes upto. One word for this is "arrogant" Quote Link to comment
boof Posted March 1, 2012 Share Posted March 1, 2012 I suspect I missed this but why *did* the beta kernel version jump from 2.6.x to the new 3 stream? It struck me as an odd thing to be doing mid beta cycle as it's a fairly massive change. But I'm sure there was a good reason? 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.