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.