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.

Google now provide an open DNS service. At first I was scared that they use their service to get information about users.

However, their privacy statement tells us that no personal identifiable information is stored for longer than 48 hours. The permanent logs do not contain such information. The most notable information that is stored permanently is the requested domain. The other thing is that they record the location of the request on the city level. And even that info is only stored for two weeks. After that, only a small random sample of info is stored for permanent storage.

The main question is now: who do you trust more: Google or your ISP.

To be honest, I think I trust Google more than my ISP. I don't think my ISP adheres to the same privacy policy.

If you have some file that has been saved on a (Win)do(w)s host you may notice that all lines end with ^M.

To fix this, you can use the tool dos2unix. If however this tool is not at your disposal, you may have a problem. If vim is available, you do not have a problem:

The trick is to delete all occurances of ^M with this line:

:%s/ctrl-v ctrl-m//g

This will look like:

:%s/^M//g

Just save the file and you're done.