unRAID Server Release 5.0-beta14 Available


limetech

Recommended Posts

  • Replies 496
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

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.

Link to comment
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?

Link to comment

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

Link to comment
# 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?

Link to comment

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

 

Link to comment

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

 

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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!

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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

Link to comment

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
Link to comment

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

 

Link to comment

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.

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.