The situation is very simple. It does not happen regularly, but if you do come across it you might find this post useful. Now quit the chit-chat. As the title already implies, my external HDD (harddrive), a Western Digital mybook 500GB with data ended up with a corrupted partitiontable.

The story began like this: I needed a hfs (Mac OS) to do some testing. I remember the first 3 partitions on my HDD functioned as test-subject during my Amsonia adventures. So I thought, why not merge these into one larger partition. In the beginning my HDD had this structure:

This structure is then altered using fdisk and resulted in this state:

So the process of freeing space was done beautifully. The data on my logical partitions remained intact as they should be. The next step would be of course connect the disc to the macbook and launch Disk Utility to create the partition and format it. I double checked it won’t touch the partitions by reviewing the options hidden in options. Everything seems fine, so let’s apply the changes…. and there comes the surprise: Disk utility failed to apply the changes and ejects the device.

Apparently Disk Utility did modify the partitiontable but failed to do it successfully. Here I am, my partitions inaccessible. A quick web-hunt resulted in trying out gpart. The process of scanning 500GB took around 10 hours to complete; the disc was connected over usb 2.0. Average readspeed was 16mb/s. When gpart was done scanning, it didn’t report anything useful. So the hunt continues till I stumbled against Recovering lost ext2 Linux filesystems. After reading the article I decided to give their hand-crafted utility a try. My article is written with the hope to add value to the information you’ve gathered. It should not be seen as a replacement!

After scanning the whole disc, Scandrive produces a ~2mb report. As the article indicates, lines of the following format might indicate partition start:

ext2 432180492 # size=68095510 #0

So, let’s filter out these interesting line with grep:

grep -w "#0" /path/to/file

The key here is to find a pattern in the less cluttered data. With pattern I mean consecutive large groups having the same size. All found groups are potential partitions, the first block of the group minus two might be the start of a partition.

Once you’ve gathered the offsets and sorted by group size, you can start trying to recreate the partitiontable (preferably one by one) using sfdisk.

Back to my situation, after some trial and error attempts I found logical 1, but the size appears to be incorrect. Because the system could only read that partition partially (some directories could not be read). So I decided to calculate the maximum size of my HDD and use it as the right-boundary. This allowed me to recover all files on logical 1. When the copying process was done, the second partition can also be found and treated in the same way.

You can define the boundaries (your new partitiontable structure) in a text file like this:

# partition table of /dev/sdc
unit: sectors

/dev/sdb1 : start= 432003978, size=544764087, Id=83

Then write it to the disc using sfdisk:

sfdisk -n /dev/YOURDEV < /path/to/new/pt

If you think it is good, commit to disc:

sfdisk --force /dev/YOURDEV < /path/to/new/pt

Then try to mount the new partition. If mount bails out with an error, don't panic, continue trying other potential starting offsets.

Notice the start offset is calculated this way, say you found this line:

ext2 432180492 # size=68095510 #0

The start offset should be: 432180492-2 = 432180490
You only have to do this for the first offset in a group!

The recovering adventure lasted 1.5 days with a happy ending. I've learned a lot during this process, I hope you find this information useful. Special thanks go to Steve Friedl's Unixwiz.net Tech Tips.

No related posts.