Unbricking a Western Digital Mybook Live

A couple months ago, my 2tb WD NAS decided to brick itself after I had to move it. Searching the internet, one can find that this is not exactly an uncommon problem, and is diagnosed by the unit showing a solid blue light (with the occasional flash to yellow). Mostly, none of the multitude of threads in the forums have any real solutions, or suggest to RMA the hard drive with Western Digital. This isn’t really a solution as far as data is concerned, so I decided to poke at it myself.

What You’ll Need

Unbricking the drive is a moderately involved process, and risks screwing it up even further. That said, if you want to try it here’s the things you’ll need.

Sata-USB adapters can be had for less than $20 on Amazon.

Setup

First the harddrive will have to be removed from its chassis. This is easier said than done, but can be achieved by prying up the plastic sides around the drive, while sliding the 2 pieces of it apart. It is probably possible to get it apart without breaking anything but breaking some of the tabs holding it together may be inevitable.

Once apart, the actual electronics are just wedged into the chassis on rubber-padded rails and can be pulled out fairly easily.

From this point, there are 4 screws securing the harddrive to the logic board. Once these are removed, the board and drive can be separated (note: one of the screws is under the rubber pad holding the LED light guide).

With the drive free, it can be hooked up to a comptuer via the Sata-USB adapter.

Fixing the Disk

You should now connect the drive to a computer, and have some sort of Linux distribution running (Ubuntu should work).

If you look at the disk with a tool like gparted, you’ll see that there are 4 partitions on it. These should be named something like sdb1-sdb4.

sdb1 and sdb2 are where the actual OS is installed. These are mirrored ext3 partitions, controlled by software RAID (this seems silly since there’s only once disk, but since there are also 2-disk versions of this NAS, and the same OS setup is probably used on both of them, it does make some degree of sense). sdb3 is swap, and sdb4 is where the data lives as an ext4 filesystem.

It’s possible to directly mount sdb1 and sdb2 (passing ‘-t ext3’ to ‘mount’ explicitly), but it should probably be avoided. Instead, tell the OS to treat them as a RAID array using ‘mdadm’. Something like

# mdadm --build /dev/md0 --raid-devices=2 --level=1 /dev/sdb1 /dev/sdb2

# mount /dev/md0 /mnt

should successfully get the partitions mounted if you want to poke around at them.

The actual reason behind the bricking seems to be the filesystem getting messed up from unpluggin the unit while it’s still running (there’s no power switch, so it’s hard to power off any other way). As a result, the actual problems with the drive can be fixed by just fscking them.

# umount /mnt

# fsck /dev/md0

will unmount, and repair the filesystem that the actual OS lives on. Odds are this will fix any issues caused by prematurely unpluggin the drive.

The data partition is a bit tricker. For some unknown reason, Western Digital decided to make this partition be completely incompatible with comptuers that are actually used. The blocksize on the filesystem is set to 16k, whereas 64-bit computers can only use a 4k block size. This means that it is impossible to mount this partition to get files off of it!

All is not lost though, as ‘fsck’ still works on the partition, despite the block size not being usable. As a result

# fsck /dev/sdb4

should fix this filesystem as well.

Once this is all finished, you should be able to plug the drive back in and have it work. I recommend not putting it back into the chassis until you have verified it is actually working.

Getting Data from the Data Partition

The block size issue described above makes it rather tricky to get data off of the drive in the event that the system paritions somehow got screwed up while the data partitions didn’t. It is not impossible though, and can be accomplished through the ‘debugfs’ command.

With the drive connected to the computer, run

# debugfs /dev/sdb4

This drops into a filesystem debugging interface. Run ‘help’ to see what all can be done from here. Most of the commands are really dangerous to run on a disk we’re hoping to salvage, so a great deal of caution should be taken. That said, there are a number that are quite useful. These include ‘ls’, ‘cd’, ‘cat’, and ‘dump’.

The first 3 do exactly what one would expect, with lots of extra filesystem data presented as well. ‘dump’ though, is the key to recovering data from the drive. ‘dump’ will take the contents of(read: a file) and dump it to a local file. This will only work on files (not directories), and can only dump one file at a time, but it can be used to recover important files if all else fails.