Resolution
 

Thanks to the gracious help of linux guru Tonit I was able to recover my lost hard drive partition and all the data. We used the following tools to diagnose and fix the problem: losetup, sfdisk, gpart.

Here is how it was done.

The error occurred when I tried to resize hda5 to make it 1.2GB smaller. I used the partition manager in the SUSE control panel. Apparently what it did was to just rewrite the partition table to make the partition smaller. It did not move any of the data or fix the file system. After the Suse partition manager did that, the partition was no longer usable. This was because both the start and end were alterred. The file system information was no longer accessible and I could not mount the drive. The start of the drive was pushed 630 sectors forward and the end was shortened by 10000 sectors or so.

Looking at the information from fdisk (a utility that outputs the current parition table (fdisk -u -l)) we saw that the new hda5 starts at 20483568 and ends at 99940175. The next partition (linux) starts at 102398751. This was the current partition table. There must be an error with this table because /dev/hda5 is unmountable. This was verified using a file -Ls /dev/hda5 command. This command identifies what data is currently at that location in the drive.

file -Ls /dev/hda5 output "data" for that partition

for a normal partition the output would be

/dev/hda1: x86 boot sector, code offset 0x52, OEM-ID "NTFS ", sectors/cluster 8, reserved sectors 0, Media descriptor 0xf8, heads 255, hidden sectors 63, dos < 4.0 BootSector (0x80)

So now that the partition table for dev/hda5 is incorrect. How do we find out what the real start and end points of the partition are? If you have backed up your old partition you can simply look at that file. However, I did not so I was more difficult. The next step was to analyze the drive. This is done with gpart. In my previous post you see the gpart output. It states that partition 2 (hda5) starts at sector 20492938. This is 630 sectors earlier than what the partition table says. Is that the real start of the file system?

In order to figure out if this is the real start of the drive we have to mount it and try to read the files. But how do we mount something thats not a device in the partition table. The solution is losetup. losetup allows you to set up a loopback device with an offset. Basically what this does is allow you to create a device (/dev/loop0) that starts at any point in the drive.

First we tested losetup with hda1. Since hda1 starts at sector 63 the offset we use is 63*512 (512 is the sector size). The command is "losetup -o 32256 /dev/loop0 /dev/hda". This sets up a device that starts at sector 63 of hda. Usine 'file -Ls /dev/loop0' we verified that the output matches 'file -Ls /dev/hda1'. Now we can set up a loopback device to our old location of hda5. The hda5 starts at sector 20492938, therefore the loopback offset is 20492938 * 512. Using the same losetup command as before with the new offset (after deleting the old loopback device with losetup -d) we created a device that approximated the old hda5 partition. Using 'file -Ls' on this device it shows that it was in fact the start of the file system for that partition. When I mounted this loopback device I could access my files again!!

Next we checked if the file system was intact. This was done with 'fsck /dev/loop0' which returned no significant errors. Now that we know the drive is intact we can change the partition table back to the original settings. hda5 starts at 20492938 and ends right before hda6.

We used sfdisk to do this. First we saved rent the current config using "/sbin/sfdisk -d /dev/hda > hda.original_layout". This saves a file with the start and size information for each partition. Next we edited this file to make hda5 start at 20482938 and end at 102398750. We did some simple addition to make sure that hda5 did not overlap with hda6. This file was saved as hda.new_layout. Now we have to apply these changes.
This is done using ' sfdisk -O hda.sectorbackup /dev/hda < hda.new_layout'. This command saves the old sector info in hda.sectorbackup and write the new partition table.

However, this command complained that it did not like the table. Since we knew the old partition table was wrong and we had to change it we simply forced the changes using: 'sfdisk --force --no-reread -O hda.sectorbackup /dev/hda < hda.new_layout' the --no-reread option prevents the kernel from reading the table automatically. After this the partition table was corrected.

To force the kernel to re-read the table we used 'blockdev --rereadpt /dev/hda'. However this command complained that hda6 was in use. THus I had to reboot to allow the changes. However, if the reboot did not work I could recover the old settings using 'sfdisk -l hda.sectorback /dev/hda' using the sector backup from before.

After I rebooted everything was fine! I could mount the drive again and read all the data. I ran another fsck to make sure the fs was intact. I booted into windows and the drive was back to normal! This is the final fdisk ouput:

isk /dev/hda: 60.0 GB, 60011642880 bytes
16 heads, 63 sectors/track, 116280 cylinders, total 117210240 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
/dev/hda1 * 63 20482874 10241406 7 HPFS/NTFS
/dev/hda2 20482875 117194174 48355650 f W95 Ext'd (LBA)
/dev/hda3 117195120 117210239 7560 82 Linux swap
/dev/hda5 20482938 102398749 40957906 c W95 FAT32 (LBA)
/dev/hda6 * 102398751 117079199 7340224+ 83 Linux

Everything was back to normal!

Thanks to Tonit for all his help in saving my data! Hopefully if anyone else has this problem this will help. I am never going to use the Suse partition manager to resize partitions.

Does anyone know if using partition magic is a bad idea for a dual-boot linux system?

Thanks,

Neil