Louwrentius

Even today people do not understand how important it is for the safety of your data to make backups. I was asked to perform some data recovery on a hard drive of an old computer, which still contained important documents and photo's.

The first thing I did was to make a disk image with ddrescue. I always work with the image and not with the original drive, to prevent any risk of accidentally messing things up for good.

Example:

ddrescue -r 2 -v if=/dev/sdf of=/storage/image/diskofperson.dd bs=1M

Next, I tried using gparted on this file but got this error:

Welcome to GNU Parted! Type 'help' to view a list of commands.

(parted) p

Error: /storage/image/diskofperson.dd: unrecognised disk label

(parted) quit

Also fdisk -l didn't work:

Disk /storage/image/diskofperson.dd doesn't contain a valid partition table

It seemed that the partition table was gone. I used the utility testdisk to recover this partition, to no avail. Why this tool didn't work is beyond me.

I found a very old utility called 'gpart' that just searches a disk for existing partitions. I just want to know the starting offset of the relevant partition.

So I ran:

gpart -g /storage/image/diskofperson.dd

And I got nothing useful, although a partition was found:

Begin scan...

Possible partition(DOS FAT), size(57255mb), offset(0mb)

End scan.

So I ran the command again with more verbosity:

gpart -g /storage/image/diskofperson.dd

...

Begin scan...

Possible partition(DOS FAT), size(57255mb), offset(0mb)

type: 011(0x0B)(DOS or Windows 95 with 32 bit FAT)

size: 57255mb #s(117258372) s(63-117258434)

chs: (1023/255/0)-(1023/255/0)d (0/0/0)-(0/0/0)r

hex: 00 FF C0 FF 0B FF C0 FF 3F 00 00 00 84 38 FD 06

End scan.

...

This time I got something useful. The s(63-117258434) part shows the starting sector, which is 63. A sector is 512 bytes, so the exact starting offset of the partition is 32256.

So to mount this partition, just issue:

mount -o loop,ro,offset=32256 /storage/image/diskofperson.dd /mnt/recovery

And voilá, access to the filesystem has been obtained.

/storage/image/jdiskofperson.dd on /mnt/recovery type vfat (ro,loop=/dev/loop0,offset=32256)

After messing around with different kernels on Debian Lenny, I noticed that my system did no longer respond to WOL packets. The system is using an on-board Realtek R8168 chip which supports wake on lan.

After searching and reading i found the problem. The system is using an r8168 chip, but the driver that is loaded by Linux is the r8169 driver. If the r8168 driver is loaded, as it should be, then WOL is working again.

See also this information.

The trick is to blacklist the r8169 module. To do so, edit the /etc/moprobe.d/blacklist file and add a line reading 'blacklist r8169'

To make this permanent, issue the following commands as root or with sudo:

depmod -a

mkinitramfs -o /boot/initrd.img-$(uname -r) $(uname -r)

After a reboot, wake on lan should be working again.

This may be of interest to people who are as stupid as I am and write elaborate shell scripts instead of using a proper scripting language such as Python or Ruby. No I am deliberately not mentioning Perl here.

Anyway, testing is always an issue. With PPSS, I encountered many times that some change broke something in another place. Testing if some change screwed things up manually is just tedious and a pain.

As any person who is semi-serious about programming should have done already, I started to write some unit tests. For bash scripts, there is this unit test framework called Sunit2. It takes some effort to write tests. But once you have written some tests and witness how the tests that passed before now fail after you changed some code is priceless. Because often, you would not have found the issue before a long time.