Houston, we have a problem.

 

A new build of 4.7 unRAID Server Pro on a SuperMicro Atom MB with SuperMicro 8-port SATA controller. 8 x WD 2TB EARS. All new parts. To keep a long story short (will provide details if necessary): Pre-cleared all the HDs. Assigned 7 data disks (left parity unassigned), copied across 6TB of data. Rebooted and assigned the parity drive (device sdf). Ran a parity sync. Completed with zero errors.

 

I then stopped the array and rebooted the system via unRaid Main. Upon reboot, unRaid main shows:

"Stopped. Initial configuration", Disk status shows parity "Not installed", no data disk free/read/write/errors info.

Devices page shows parity device as unassigned.

 

MyMain shows:

Array Status NEW_ARRAY, unRAID ARRAY is STOPPED 7 disks in array.    PARITY NOT VALID: DISK_NEW; SAMBA is STOPPED, Shared drives will not be visible on the LAN.

 

Would love to hear from the gurus how to sort this problem out and not lose any data. I have a backup but the transfer took about 5 days with verify copy.  

 

Thanks in advance.

 

Ross

 

syslog-2011-03-16.txt

Ummm, now why would super.dat be unreadable?

 

Mar 16 16:00:58 Tower kernel: md: could not read superblock from /boot/config/super.dat

Mar 16 16:00:58 Tower kernel: md: initializing superblock

Is the "trust my parity" the procedure to follow?

 

http://lime-technology.com/forum/index.php?topic=4726.0

 

Ross

 

A little further info. I rebooted to see if the super.dat file could be read by the OS. No go; I still see the "could not read superblock" error in syslog.

 

An ls -l of the /boot/config directory shows super.dat to be a 0 byte file, last updated yesterday (about 19 hours ago), not today when I rebooted after the parity sync finished. I'm not sure if the timestamp corresponds to when I started the parity sync (I rebooted immediately prior to the parity sync).

 

There is a super.old file of 4096 bytes with an old timestamp from last month.

 

Doing a search of the forum I see another thread describing a similar situation to mine but with a different solution:

 

http://lime-technology.com/forum/index.php?topic=9438.0

 

No need for any initconfig command. Just delete the corrupt super.dat, boot, and hit the start button. Is either solution ok?

 

Ross

A little further info. I rebooted to see if the super.dat file could be read by the OS. No go; I still see the "could not read superblock" error in syslog.

 

An ls -l of the /boot/config directory shows super.dat to be a 0 byte file, last updated yesterday (about 19 hours ago), not today when I rebooted after the parity sync finished. I'm not sure if the timestamp corresponds to when I started the parity sync (I rebooted immediately prior to the parity sync).

 

There is a super.old file of 4096 bytes with an old timestamp from last month.

 

Doing a search of the forum I see another thread describing a similar situation to mine but with a different solution:

 

http://lime-technology.com/forum/index.php?topic=9438.0

 

No need for any initconfig command. Just delete the corrupt super.dat, boot, and hit the start button. Is either solution ok?

 

Ross

I would do one more thing.  I'd put the flash drive in your window's PC and run scandisk/checkdisk against it.  Also, make sure it is not full. (unlikely, but it has happened to me)  Once you know its file system is sane and there is space on the drive you should be fine.

 

Other than that, you can run the initconfig command which will delete the super.dat file.

 

Joe L.

Thanks Joe. That problem is solved. I ran checkdisk and let it fix the flash file system (one file corrupt). I then deleted super.dat, booted, assigned my parity disk (again) and hit the start button. Parity check commenced, super.dat was then re-written by the system, and parity check later completed with zero errors.

I then rebooted. Super.dat looks intact this time and parity assignment wasn't dropped this time, so things look ok.

 

Now one other problem has reared its ugly head: no shares appearing on the network.

 

Tower emhttp: shcmd (35): killall -HUP smbd (Minor Issues)

Tower emhttp: _shcmd: shcmd (35): exit status: 1 (Other emhttp)

I'll start a new thread about this problem if I can't fix it.

 

Ross

This is normal. It happens every time SMB is restarted.

Thanks.

 

I ended up having to delete secrets.tdb in /etc/samba/private/ and then rebooting to get Samba up and running again.

 

Ross