Hi, I'm running 9 disks with unRaid Pro v4.2.4. I restarted the server today through its web interface and now I got this weird problem:

 

At first reboot it appeared that the array stuck at "Starting...": on the mainpage in "Command area" I only saw a green dot and "Starting..." with two buttons "Refresh" (enabled) and "Start" (grayed out). I somehow made a not so wise decision to force a shutdown by pressing the power button on the server. Then it seemed to be doing polarity sync after reboot, but I let the process went through (probably took hours but I didn't check) until the numbers under "Reads" stopped changing. However, I was still stuck with the same mainpage with "Starting..." and a single "Refresh" button and a grayed out "Start" button. Over the network I could only see "unRAID/flash", no harddrives and shares.

 

I'd really appreciate the helps how to get the array into service.  I attached the syslog here too. I took a look at the log and it seems some files were corrupt on disk6?

 

Thanks a lot again.....

 

Yang

 

===========================

 

Hardware configuration:

 

Asus P5B-E + Celeron D331 Prescott 2.66GHz + 2GB

P5B-E SATA controller: disk 0-6 (1TB, 500GB x 3, 1TB x 3)

Supermicro AOC-SAT2-MV8 PCI SATA PCI controller (disk 7, 8: 1TBx2)

Athena SATA cage for disk 0-4.

Matrix G400 PCI VGA card

 

=================================

 

 

I note that the system is recovering from the improper shutdown by replaying 5 transactions on all of the drives but Disk 6 (only 4 transactions), and as you noted, there appears to be corruption in the file system on Disk 6.  This makes me suspect (just speculating here) that a necessary fifth transaction on Disk 6 was corrupted, and not attempted, leaving its file system in a bad state.  You definitely need to run reiserfsck on Disk 6, discussed below.

 

The problem though is the system appears to be stuck in a loop, waiting for a User Shares process to finish initializing, but it is hung up on something, probably on Disk 6.  Rebooting *might* work, but will probably result in the same loop, stuck at the same point, until Disk 6 is fixed.  Type stop at the console or telnet prompt, and see if that will properly close down the User Share system as well as the rest of the unRAID driver processes.  If stop does not stop the unRAID startup and umount the drives, then perhaps a more knowledgeable Linux user can help you safely stop the correct processes.

 

It would be nice to have a way of rebooting unRAID, but without Starting the array.  I don't know a clean way to do that though, except to temporarily rename the /config/super.dat file on the flash drive.

 

The standard advice on reiserfsck is here:  http://lime-technology.com/wiki/index.php?title=Check_Disk_Filesystems.  This wiki page however, assumes a working unRAID array, and when you succeed in closing yours down, the array will be down, and there won't be an md6, so you will need the alternate way of identifying the drive device.  You can obtain the Device ID of Disk 6 from the Devices web page, should be sdh I think.  Then type reiserfsck -y /dev/sdh1 at the console or telnet prompt (that is sdh1, for the first partition of sdh).  If it tells you to rerun with --fix-fixable or --rebuild-tree, do so.  For example, reiserfsck -y --rebuild-tree /dev/sdh1.

 

Thank you so much, RobJ. I typed "stop" through telnet console, and it apparently stopped the array. I then typed reiserfsck -y /dev/sdh1 and it went through with "No corruption found". I checked in the device page and confirmed that ID of disk6 is sdh. Isn't this inconsistent with the syslog? I knew almost nothing about Linux...

 

I didn't reboot array after reiserfsck, since it didn't do anything to disk6 I guess the array will just do the parity sync and get stuck again after reboot. Should I go ahead give --fix-fixable or --rebuild-tree on disk6 a try anyway? I noticed that when array was stuck after finishing the sync, all other disks eventually went to sleep, except for disk5 and 6. Any implications here?

 

 

 

 

Since Disk 6 is apparently fine, I took another look at the syslog, and have to admit I probably jumped to conclusions, with respect to the duplicate files found on Disk 6.  At first glance, that looks like file system corruption, but now I think it was just that the logger could not handle the character set used for that part of the path, and tried to 'translate' it for display.  Those 2 files are also on one of the earlier disks.

 

Just to be safe, you might try testing each of the other data disks.  Don't test the parity disk, as it does not have a file system.  For the others, use the same reiserfsck command, except substitute the correct device ID from Devices page, and don't forget to add a 1 to each (eg. sdc1).

 

If all tests fine, then powerdown and reboot, and see if it stalls again.  Hopefully, a fresh start will be better, although not confidence building.

 

If it does fail again, stop it again, and try temporarily turning off User Shares, and rebooting.  If it Starts fine then, try another unRAID version with a different implementation of User Shares, like the latest beta.

 

If reiserfsck reports no corruption, there is no reason to run with additional parameters.  You only use them if instructed to.

 

Thanks, RobJ! I'm in the office right now but I'll check all the disks (except for parity disks) once I get home. Hopefully reiserfsck will find and fix the problems. You're right, those "weird" characters in the syslog probably is not due to corruption, they're just mistranslated chinese characters in original file and directory names. unRAID handles those "foreign" characters really well so far, unlike couple other server stuff I tried (like Infrant NAS600).

 

You mentioned to "turn of User Shares" as an option. I actually didn't enable any new usershare features in 4.2.4. All the top level directory like "Videos" etc are on split level 0, I also didn't create any users. Is there still anything I can do about turning off User Shares? One thing I noticed after 4.2.4 update is that the server didn't update shares (e.g. Videos) promptly for new files on disk7 and disk8, the two latest disks I added to Supermicro SATA controller. Since there is no more "Rescan" button in 4.2.4, I don't how to force the server to update shares. That's part of the reason I decided to reboot the server to see if it will update the shares... oh well...

 

 

Yang

Is there still anything I can do about turning off User Shares?

 

On the Shares tab of the web management pages, change the User Shares setting to Disabled, and click the Apply button.  You should not lose any information, but I don't remember if you might have to reconfigure User Shares after re-enabling them.

 

the 4.3 release makes that much easier.  No need for "rescan" button. It is automatic, regardless if you write to user-share, or direct to disks.

 

Suggest you upgrade once you get things stable.

 

.. only need to download and uncompress latest release, then copy bzroot and bzimage to your flash drive.  (You can rename the existing files to make it easy to go back to the older version if you like)

 

Joe L.

 

I checked all eight disks by reiserfsck and none of them found corruptions. I rebooted the server through the console (shutdown -r 0) and apparently it didn't do the parity sync anymore after boot, but still I got the same mainpage saying "Starting...." in Command area with Refresh and Stop buttons only (Stop is grayed out). I looked at the Shares page, the "User shares" option was grayed out. I tried to stop array by typing "stop" in the console, the green dot before "Starting..." turned into red, all disks except for parity showed "mounting", but "User shares" was still grayed out with "array must be Stopped to change". I then typed "sync" in the console (I don't know what it really means though!) and still no change. Looks like I can't even actually stopped the array?

 

Yes, Joe, once the thing is stable I'll upgrade to 4.3.

 

"sync" requests that Linux flush any data it has in the buffer cache in memory to the physical disks.  It takes a few seconds or so to write to the disks if a lot is buffered, so you sometimes see "sync" typed more than once. (the second is not needed, it just takes a few seconds time to type)

 

In any case, when you typed "stop" at the command prompt you stopped the array from behind the scenes, and that gets the web-interface gets completely confused.  The only way I've ever found for it to figure things out again is to reboot.    Do not try to re-start with it thinking everything is unformatted... it might just try to format them... erasing your data. That would NOT be good.

 

Glad all your disks pass the reiserfsck check.

 

Joe L.

Hi Joe, thanks for the reply. So it looks like I am caught in the middle of a weird loop?  Say unRAID is stuck with sth (generating useshares?) during the boot but it gives me no options to stop the array from the web interface, without being able to stop array from web control then I can't turn of the user share to fix the problem...

 

So far it looks like all the data on the disk are fine, based on the report by reiserfsck and on unRAID mainpage. Still, I'd really appreciat to get this array back online.... I guess there must be a way out of this loop?

Try this as suggested by Tom to turn off user shares so you can then get out of your loop.

 

http://lime-technology.com/forum/index.php?topic=1745.msg12110#msg12110

 

Joe L.

That worked out great, Joe! I was able to disable User Shares by modifying the shares.cfg. Now my array is back online!

 

The server is doing a "real" parity check which is going to take few hour, but at least I can see the normal web interface with all the buttons like stop, start array, etc, etc in the "Command area". Plus, all the disks are online now. Wow, a great relief.

 

So should I enable use shares after the parity check? Or, update to 4.3 first and then enable user shares? I'm leaning towards enabling the usershares first, so the server will regenerate the usershares and presumably will shake off those problems it had before?

 

I really want to thank you and RobJ for your kind helps. Saved my life...

User shares are always generated dynamically based on your settings.    The "user share" file system was recently re-written to eliminate some of the issues you are complaining about so once the parity is re-checked and you are stable, I'd upgrade.

 

As I said, it is only two files to put into place after you un-zip the newest beta release on your PC.  If you export your flash drive as READ/WRITE you can do everything from your PC's file explorrer.  You can even re-name the current two files to bzroot42 and bzimage42 and then copy the two new files into place on your flash drive, and then reboot. If any issues surface, you can rename them back to their original names and you will be back to your older version.  It's that easy.

Whatever you do, do not re-format the flash drive, or re-load syslinux. (Those steps are already done, and not needed for a simple upgrade)

 

Once you are up on the new 4.3 release, you can re-enable the user-shares and we'll sort out the mess (if it still exists).

 

At least you won't have to work about the lack of a "re-scan" button at that point.

 

Joe L.

I'm happy to report that my unRAID server now is completely online.

 

It's now clear the the 4.2.4 was having problem to generate user shares after boot. After disabled user shares, I was able to get array back online fine. However, when I tried to enable user shares in 4.2.4 the array got stuck again at "Starting....".

 

I then upgraded to 4.3.6beta, problem solved! Everything back to normal. What a relief...

 

Many thanks to Joe and RabJ!

 

 

 

 

I had almost the same scenario and following this thread also fixed my problem.  Now running 4.3 beta 6 and it's working great again.

I had almost the same scenario and following this thread also fixed my problem.  Now running 4.3 beta 6 and it's working great again.

 

fabulous...  I thought I asked too many questions and helps... but your post makes me feel that at least I contributed a bit to this forum...