HELP resized partition and lost all data
 

I was resizing a fat32 storage partition on my laptop. I resized using YAST2 in Suse. Originally it was ~39GB and I resized it to ~37GB to make more space for the linux parition. However, after the resize, I could not add the extra space to the linux partition. What is worse is that I could not longer mount the drive. Also, when I boot into windows, it is no longer recognized as a formatted drive.

Most of my important data is on this partition and I need to get it back. How can I recover the data? YAST2 will not let me resize the partition back to its original size. When I try to use parted, it says the partition table is incorrect. How do I fix this?

Please help!

Thanks in advance!

Neil

gpart and sfdisk are your first level friends. If those don't help, use lde. Remember to take backups from every bit you overwrite when you do your recovering attemps. This way you can't make the situation worse.

Here is my /etc/fstab

/dev/hda6 / reiserfs acl,user_xattr 1 1
/dev/hda1 /windows/C ntfs ro,users,gid=users,umask=0002,nls=utf8 0 0
/dev/hda3 swap swap pri=42 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0
proc /proc proc defaults 0 0
usbfs /proc/bus/usb usbfs noauto 0 0
sysfs /sys sysfs noauto 0 0
/dev/cdrecorder /media/cdrecorder subfs fs=cdfss,ro,procuid,nosuid,nodev,exec,iocharset=utf8 0 0

fdisk -l

Disk /dev/hda: 60.0 GB, 60011642880 bytes
16 heads, 63 sectors/track, 116280 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

Device Boot Start End Blocks Id System
/dev/hda1 * 1 20321 10241406 7 HPFS/NTFS
/dev/hda2 20321 116265 48355650 f W95 Ext'd (LBA)
/dev/hda3 116266 116280 7560 82 Linux swap
/dev/hda5 20322 99147 39728304 c W95 FAT32 (LBA)
/dev/hda6 * 101587 116150 7340224+ 83 Linux

Oh, and I would recommend turning into local linux/filesystems guru from the neibourhood to get him/her to help you. If there is none available, I might be willing to help with the issue.

If your job/ass/life/over a monts work is dependant on those files, it might be better to use some professionals to do the job.

Gpart output


Begin scan...
Possible partition(Windows NT/W2K FS), size(10001mb), offset(0mb)
Possible partition(DOS FAT), size(39997mb), offset(10001mb)
Possible partition(Linux swap), size(7mb), offset(57224mb)
End scan.

Checking partitions...
Partition(OS/2 HPFS, NTFS, QNX or Advanced UNIX): primary
Partition(DOS or Windows 95 with 32 bit FAT): primary
Partition(Linux swap or Solaris/x86): primary
Ok.

Guessed primary partition table:
Primary partition(1)
type: 007(0x07)(OS/2 HPFS, NTFS, QNX or Advanced UNIX)
size: 10001mb #s(20482808) s(63-20482870)
chs: (0/1/1)-(1023/15/63)d (0/1/1)-(20320/4/59)r

Primary partition(2)
type: 011(0x0B)(DOS or Windows 95 with 32 bit FAT)
size: 39997mb #s(81915372) s(20482938-102398309)
chs: (1023/15/63)-(1023/15/63)d (20320/6/1)-(101585/9/63)r

Primary partition(3)
type: 130(0x82)(Linux swap or Solaris/x86)
size: 7mb #s(15120) s(117195120-117210239)
chs: (1023/15/63)-(1023/15/63)d (116265/0/1)-(116279/15/63)r

Primary partition(4)
type: 000(0x00)(unused)
size: 0mb #s(0) s(0-0)
chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

parted gives me this output;

Warning: Unable to align partition properly. This probably means that another
partitioning tool generated an incorrect partition table, because it didn't have
the correct BIOS geometry. It is safe to ignore,but ignoring may cause
(fixable) problems with some boot loaders.

If I fix the partition table back to what it was before the resize, will the original partition be intact?

btw... dont know any linux gurus around here

Hmm.. the partition table looks quite sane. Is it this hda5, that is not working?
I see no mount directives in fstab for it.

yes hda5 is the one i tried to resize. The Gpart output shows the correct size (39997mb). However, now the partition goes from cylinder 20322 to 99147. If i resize it back to the original size of 20322-101586 will that cause any problems? Also, how do i do that?

Thanks for all your help

also hda5 is not in /etc/fstab because i umounted before resizing. I dont remember exactly how it was mounted. It was a fat32 drive. I tried remounting the resized drive but I cant remember the type and i get an error

I don't think that helps. If there is a problem accessing some files or directories, that might help, but a mounting problem sounds more like the starting offset is out of track. Could you give the output of "fdisk -l -u /dev/hda"?


PS. I sent you email about how contacting me in realtime, so we could have more dynamic conversation.

fdisk -l -u /dev/hda

Disk /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 20483568 99940175 39728304 c W95 FAT32 (LBA)
/dev/hda6 * 102398751 117079199 7340224+ 83 Linux

Issue resolved.

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