Day 10 – 2013
Resurrecting a WD MyBook Live
So I managed to kill the Guvnors NAS box and have now resurrected it. How to repair it (with a backup before hand) because we really don’t want to loose his data.
Step 1: We need to remove the hard drive from is enclosure:
(hey – we’re going fancy here and embedding video)
Anyway – I followed this for getting the thing to pieces.
Step 2: Using a SATA->USB adapter connect the box up to your linux PC (NB use on that works and is not flaky – it will save hours when trying to backup the data!)
Step 3: a quick dmesg on the command prompt will tell you which device it is:
[usb 1-4.2: New USB device found, idVendor=13fd, idProduct=1340 usb 1-4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-4.2: Product: External usb 1-4.2: Manufacturer: Generic usb 1-4.2: SerialNumber: 57442D5743415A414B343135 usbcore: registered new interface driver uas Initializing USB Mass Storage driver... scsi6 : usb-storage 1-4.2:1.0 usbcore: registered new interface driver usb-storage USB Mass Storage support registered. scsi 6:0:0:0: Direct-Access Generic External 2.08 PQ: 0 ANSI: 4 sd 6:0:0:0: Attached scsi generic sg2 type 0 sd 6:0:0:0: [sdb] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB) sd 6:0:0:0: [sdb] Write Protect is off sd 6:0:0:0: [sdb] Mode Sense: 21 00 00 00 sd 6:0:0:0: [sdb] No Caching mode page present sd 6:0:0:0: [sdb] Assuming drive cache: write through sd 6:0:0:0: [sdb] No Caching mode page present sd 6:0:0:0: [sdb] Assuming drive cache: write through sdb: sdb1 sdb2 sdb3 sdb4 sd 6:0:0:0: [sdb] No Caching mode page present sd 6:0:0:0: [sdb] Assuming drive cache: write through sd 6:0:0:0: [sdb] Attached SCSI disk
This shows the drive registered as /dev/sdb with 4 partitons, the data is stored on /dev/sdb4 however for some reason WD decided to use 16k block sizes which, unless you want to rebuild your kernel, most prebuilt kernels can use. Enter debugfs!
Step 4: We want to backup the data on /dev/sdb4 incase we totally cockup. As we can’t mount the partiton we can use a tool called debugfs, will allows us to do all sores of useful things, like recover deleted files etc. What we are using it for is just a way to read the file off the disk and make a copy of them elsewhere.
Now we want to copy the contents of the share directory.
rdump share /backup/
To all intents and purposes this is the equivalent of cp -rvp /mnt/shares /backup/ if we were actually able to mount the drive. Beware this can take a loooong time and you will have no feedback whatsoever (unless it fails and you get lots of short reads due to using a dodgy SATA->USB adapter!)
Step 5: Okay! So we got the data backed up! Hurrah! Now we need to get the debrick script from here
unrar the script
unrar e debrick.rar
Step 6:And we need a copy of the firmware
Step 7:Now we need to extract the rootfs.img from the firmware
unzip ap2nc-024202-012-20130401.zip dpkg -c ap2nc-024202-012-20130401.deb
Which gives us a new folder called CacheVolume and in there is a folder called uploads and in there you will find rootfs.img
Step 8:Run the script:
bash debrick.sh /path_to/rootfs.img /dev/sdb
and answer the questions prompted:
********************** DISK ********************** script will use the following disk: Model: Generic External (scsi) Disk /dev/sdb: 2000GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 3 15.7MB 528MB 513MB primary 1 528MB 2576MB 2048MB ext3 primary raid 2 2576MB 4624MB 2048MB ext3 primary raid 4 4624MB 2000GB 1996GB ext4 primary is this REALLY the disk you want? [y] y ********************** IMAGE ********************** ********************** IMPLEMENTATION ********************** everything is now prepared! device: /dev/sdb image_img: rootfs.img destroy: false this is the point of no return, continue? [y] y mdadm: /dev/sdb1 appears to contain an ext2fs file system size=1999808K mtime=Tue May 7 14:45:05 2013 mdadm: size set to 1999808K mdadm: creation continuing despite oddities due to --run mdadm: array /dev/md0 started. mke2fs 1.42.5 (29-Jul-2012) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 125184 inodes, 499952 blocks 24997 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=515899392 16 block groups 32768 blocks per group, 32768 fragments per group 7824 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912 Checking for bad blocks (read-only test): done Allocating group tables: done Writing inode tables: done Creating journal (8192 blocks): done Writing superblocks and filesystem accounting information: done mdadm: added /dev/sdb2 synchronize raid... done copying image to disk... 3999616+0 records in 3999616+0 records out 2047803392 bytes (2.0 GB) copied, 436.436 s, 4.7 MB/s mdadm: stopped /dev/md0 all done! device should be debricked!
Step 9: OK so now we have the system restored to the drive and with any luck your backup is now redundant!
Unplug the HDD, and reassemble the unit.
Step 10: Plugin the device to the network access it and double check that the firmware is at the latest version. Do any updates, recreate you shares and users and off you go!