Recovering data from a damaged FAT32 hard disk drive

I just want to wrap up how I managed to recover the data from a laptop’s damaged hard disk drive. The 40GB disk was formatted with FAT32, had a Windows XP and some serious I/O error problems preventing it from booting.

I cleaned up my external 80 GB HDD, plugged it via USB into the laptop and booted the system with the latest Knoppix-CD. I reformatted the entire disk (/dev/sda1) with the ext3 file system, mounted it with (# mkdir /media/sda1 ; mount -t auto /dev/sda1 /media/sda1) and gave full access to the entire disk (# cd /media/sda1 ; chmod 777 *).

Since Knoppix is missing the dd_rhelp script, I downloaded the latest package and put it on that external disk (into /media/sda1/dd_rhelp). The damaged disk in the laptop was /dev/hda1. I set disk-access parameters for that disk back to basic but safe, disabling DMA and higher level PIO mode access:
# hdparm -m 0 -d 0 -p 0 -A 0 -X 08 /dev/hda
This makes things horribly slow in copying the large chunks of good data, but it improved the overall process since it can handle bad blocks in a better fashion. Next, I edited the dd_rhelp script and set the values “max_bs=1024” and “min_bs=64” in /media/sda1/dd_rhelp/dd_rhelp. The standard values of dd_rhelp are fine, but slow down the copying of data if the disk is damaged to a larger degree.

Ready to copy the data. Change to root with “su” and then run
# /media/sda1/dd_rhelp/dd_rhelp /dev/sda1 /media/sda1/sda1_backup.img
This process makes a bit-per-bit copy of the entire disk and writes it to the image sda1_backup.img. Any bit that cannot be read by the program will be zero. This takes a while. Quite a while. For my 40GB about a week. Which had nothing to do with the hdparm above but with the overall state of the disk (I ran the process twice). You may kill the dd_rhelp and the dd_rescue processes at any time and continue later on. dd_rhelp writes a log file that keeps track of the overall progress that has been made.

When you are done make a copy of the rescued image /media/sda1/sda1_backup.img and get yourself another hard drive that is at least as big as the image you just rescued or make some space on another hard drive. You will have to create a new FAT32 partition that is at least as big as the image. If the file system of the disk from where you just rescued the data has file system X, create a new X partition of that size. In my case, that new partition mounted as /media/sdb6. Now, copy the data from the image to that partition with
# dd if=/media/sda1/sda1_backup.img of=/dev/sdb6
Mounted /dev/sdb6 and saw the data. You can now run any file system/data/rescue operations on that disk (or the image file) or copy what’s left of it.

Update: compiled some data in a How To: Recover Windows Partitions.

Fixing problems with Exim4 and ClamAV after apt-get upgrade

So this was one of the weeks where I learned Linux configuration the hard way. I simply thought of getting my virtual server up to the most recent version. It was/is running a Debian 3.1 (Sarge), I guess. You’ll probably realize by now that I know a lot about my server…

Anyway, I simply ran
apt-get upgrade
which brought about 20+ packages to the most recent version. Including exim, my mail agent, and clamav, a virus-scanner that runs with mail agents. I guess because of a version change in either exim, or clamav, or both I was asked to do so configuration stuff which I followed to my best knowledge and guess. However, I ended up with bouncing mails to my server. After a while, I found out that clamav got a version change, but the configuration on the system didn’t go with it. The exim4 logfile /var/log/exim4/paniclog kept telling me malware acl condition: clamd: unable to connect to UNIX socket /var/run/clamav/clamd.ctl (Connection refused) While exim4 was already properly calling clamav, clamav refused to answer.

A little bit of search with that phrase revealed the following page http://koivi.com/exim4-config/ which was quite instructive to me to some degree. There was a problem with the access privileges to the clamav runtime files from exim4. So gave some privileges:
adduser clamav Debian-exim
which was already done before. I then checked that /etc/clamav/clamd.conf contains a line that reads:
AllowSupplementaryGroups
Done. Then I gave permissions for the /var/run/clamav directory to allow for the correct user to use it:
chown Debian-exim.Debian-exim /var/run/clamav
Since /var/run/clamav/ contained a file freshclam.pid I also ran
chown Debian-exim.Debian-exim /var/run/clamav/freshclam.pid
Now a restart with
/etc/init.d/clamav-daemon restart
gave me an error that AllowSupplementaryGroups in /etc/clamav/clamd.conf requires a BOOL value. Luckily Ping! from the ClarkConnect Forums pointed out that

In my /etc/clamd.conf file, there was an error in every line that required a BOOL value. I had to add “yes” or “1” to the followin options to get the clamd to succeed

I did that to each line of /etc/clamav/clamd.conf that had no argument next to it and the
/etc/init.d/clamav-daemon restart
succeeded. However, I still got bouncing mails and /var/run/clamav/clamd.ctl was still missing. It appears that clamav and exim4 just need the existence of that file, no specific content, plus proper access rights. A
touch /var/run/clamav/clamd.ctl
chown Debian-exim.Debian-exim /var/run/clamav/clamd.ctl
/etc/init.d/clamav-daemon restart
did the trick. Thanks to aioshin.

update Well… that didn’t help… therefore I did it the hard way:
apt-get --purge remove clamav clamav-base clamav-daemon clamav-freshclam libclamav1
apt-get -t sarge install clamav clamav-daemon
adduser clamav Debian-exim
reboot
Thanks to D.J.Fan. After the apt install, I told the setup to take the package maintainer’s version of the configuration file. A choice I made wrong earlier… grrr.