New Release - Firmware Version 2.3.01 for the WD Sharespace (9/12/11)

[juanito_tc]

Like everybody else, I updated the firmware to 2.3.01, did not get any error messages, but ended up with all 4 leds showing amber in a 4x1TB raid5 array on my wd sharespace and nothing showing on the home network.

Using ssh from a linux machine, I was able to get into the wd sharespace os and rebuild the raid5 array:

$ ssh admin@192.138.1.130
$ su -
password XXXXX

$ mdadm --assemble --force /dev/md2 /dev/sda4 /dev/sdb4 /dev/sdc4 /dev/sdd4
mdadm: /dev/md2 has been started with 3 drives (out of 4).

$ pvcreate /dev/md2
  No physical volume label read from /dev/md2
  Physical volume "/dev/md2" successfully created

$ vgcreate lvmr /dev/md2
  Volume group "lvmr" successfully create

$ lvcreate -l 714182 lvmr -n lvm0
  Logical volume "lvm0" created

$ fsck /dev/lvmr/lvm0 
fsck 1.38 (30-Jun-2005)
fsck: WARNING: couldn't open /etc/fstab: No such file or directory
e2fsck 1.38 (30-Jun-2005)
Couldn't find ext2 superblock, trying backup blocks...
ext3 recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
NASRAID: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Filesystem contains large files, but lacks LARGE_FILE flag in superblock.
Fix<y>? 
yes

Pass 3: Checking directory connectivity
/lost+found not found.  Create<y>? 
yes

Pass 4: Checking reference counts
Pass 5: Checking group summary information
...
Free blocks count wrong for group #22316 (32254, counted=29092).
Fix<y>? 
yes

Free blocks count wrong (719813722, counted=646135193).
Fix<y>? 
yes
...
Free inodes count wrong for group #22316 (16384, counted=16367).
Fix<y>? 
yes

Free inodes count wrong (365674484, counted=365312054).
Fix<y>? 
yes

NASRAID: ***** FILE SYSTEM WAS MODIFIED *****
NASRAID: 362442/365674496 files (6.3% non-contiguous), 85187175/731322368 block

$ mount -t ext3 /dev/lvmr/lvm0 /DataVolume -o rw,noatime

$ exportfs -av 
exporting *:/DataVolume/Download
exporting *:/DataVolume/Public
exporting *:/DataVolume/tc

Note that the last part (exportfs -av) is required if you had an nfs share set up on the wd sharespace and need to connect to it from a linux machine to copy off data.

I had a dialogue with wd on my problems - while they apologised, they were not willing to help with the linux commands required to re-build the array. 

[juanito_tc]

So, after copying my data off the wd sharespace. I set it to rebuild the raid5 array via the gui.

I got a message it would take 16-17 hours, but in fact it took about four days:

 03/20 22:33:27  wd-1-4tb daemon.warn wixEvent[1016]: Volume Status - Volume 'DataVolume' is resyncing, 80% had completed.
 03/20 02:49:09  wd-1-4tb daemon.warn wixEvent[1016]: Volume Status - Volume 'DataVolume' is resyncing, 60% had completed.
 03/19 07:04:37  wd-1-4tb daemon.warn wixEvent[1016]: Volume Status - Volume 'DataVolume' is resyncing, 40% had completed.
 03/18 09:30:06  wd-1-4tb daemon.warn wixEvent[1016]: Volume Status - Volume 'DataVolume' is resyncing, 20% had completed.
 03/17 10:06:34  wd-1-4tb daemon.warn wixEvent[1016]: Volume Status - Volume 'DataVolume' is resyncing, 0% had completed.

 After the rebuild appeared to complete - I did not see 100% in the log - the power light stopped blinking and stayed solid green and also the disk leds switched from amber to green.

On reboot, the disk leds are amber, the power light is solid green and the gui reports the array as failed.

So, I guess the firmware update really did kill my sharespace... 

[juanito_tc]

WD kindly agreed to refund the full purchase price of my wd-sharespace - refund gratefully received.