[MathBluster]

I was using the Gparted LiveCD to shrink my ntfs partition and expand my Linux partition. It was interrupted in the middle of the enlarging process.

GRUB provides me with an "Error 17" upon normal boot. Gparted sees the ntfs partition fine (and can boot to it upon request). The Linux partition is labelled as "unknown", and it informs me that it cannot detect the filesystem. Testdiks recognises it as a Linux partition, and will even let me look around inside it, revealing that my files are fine, just inaccesssible.

Ideally, this ends with me having a perfectly functional WinXP/Ubuntu system, as before, but I'd settle for a way to recover my data.

[saikee]

Your information suggests upon an interruption in shrinking a ntfs partition and expanding a Linux partition the shrunk ntfs partition boots OK but the Linux partition doesn't and regarded as "unknown".

Your Linux partition can only be regarded as unknown if its partition ID has been changed.

Grub may have a problem too because by expanding the partition the "hard-code" hard disk address may become invalid and I doubt if Gparted has obligation to fix it automatically for you.

Can you post here the output of "sudo fdisk -l" from any Live CD, say from the Ubuntu CD which is an installable Live CD if it is a recent one?

Just an observation when a user employs Gaprted, or any resizing tool for that matter, the safer approach is to shrink the ntfs partition first and test the result to your satisfaction first before expanding the Linux partition. Combining the two exposes yourself to unnccessary risk and you wouldn't be able to tell what has gone wrong if things don't work out.

[MathBluster]

Here's the output of sudo fdisk -l from the Ubuntu 6.06 LiveCD:

Disk /dev/hda: 200.0 GB, 200049647616 bytes
255 heads, 63 sectors/track, 24321 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/hda1 * 1 2550 20482843+ 7 HPFS/NTFS
/dev/hda2 4105 20677 133122622+ 83 Linux
/dev/hda3 24136 24321 1494045 5 Extended
/dev/hda5 24229 24321 746991 82 Linux swap / Solaris
/dev/hda6 24136 24228 746959+ 82 Linux swap / Solaris

Partition table entries are not in disk order

Disk /dev/sda: 512 MB, 512753664 bytes
16 heads, 63 sectors/track, 993 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 994 500704+ e W95 FAT16 (LBA)
Partition 1 has different physical/logical endings:
phys=(992, 15, 63) logical=(993, 8, 24)

/dev/sda/ is the thumbdrive that brought you this information.

[saikee]

From your disk information

 Device Boot Start End Blocks Id System
/dev/hda1 * 1 2550 20482843+ 7 HPFS/NTFS
/dev/hda2 4105 20677 133122622+ 83 Linux
/dev/hda3 24136 24321 1494045 5 Extended
/dev/hda5 24229 24321 746991 82 Linux swap / Solaris
/dev/hda6 24136 24228 746959+ 82 Linux swap / Solaris

It would appear that there are several gaps here.

Hda1 finishes at cylinder 2550 but hda2 starts at 4105 cylinder. That looks like a gap of 13Gb in between hda1 and hda2,

There is also a gap between hda2 and hda3, as the former finishes at 20677 cylinder but the latter doesn't start until cylinder 24136. A gap of 27Gb could be there with a spacing of 3549 cylinders.

The most worrying bit IMO is the logical partition hda5 and hda6. Normally the starting point of the first logical partition hda5 must coincide with the starting point of the extended partition that defines it and that would have to be 24136. However that is the starting point of hda6 and hda5 actually follows hda6 with the end of hda5 matching the end boundary of the extended partition hda3 at 24331 cylinder.

Both hda5 and hda6 are swap and that is highly irregular too.

Looking at your partition table I can not help speculating the partitions were being moved/shifted but were interrupted and had no time to put into the correct locations.

Your /etc/fstab will tell us what partitions were supposed to be available for mounting when Linux is booted.

Now on the salvage

I would in your case try to mount hda2, as this should be your Linux partition, with command in Ubuntu (Live CD) terminal

sudo mkdir /mnt/hda2
sudo mount /dev/hda2 /mnt/hda2
ls /mnt/hda2

If the "ls" shows up you have /boot, /etc, /home, etc then your Ubuntu is alive and you can go to the desktop to see them with the file manager.

Report finding up to here and post the /etc/fstab inside hda2 (by cat /mnt/hda2/etc/fstab) here.

You can use the same instruction of mounting hda2 to mount hda1 (by changing all references of hda2 to hda1) and list its content to satisfy that the ntfs partition is in good nick.

[MathBluster]

I can mount hda1 fine, which is handy, as it means I'll always be able to play Deus Ex and Diablo 2. It's not exactly important to me.

I can't mount hda2, though. It says I need to specify a filesystem.

As for the two swap partitions, they're not a symptom of this problem, it's always been like that.

EDIT: /etc/fstab reveals unionfs, tmpfs, and the two swap partitions.

[saikee]

The filing system of hda2 should be indicated in /etc/fstab. You just add " -t ext3 " etc immediately after mount command.

If you can't mount it then that could be problem because the operating system can't read its file header to obtain the indexing system.

[MathBluster]

mount: wrong fs type, bad option, bad superblock on dev/hda2, missing codepage or other error

That's bad, isn't it?

[saikee]

The superblock is the boot sector area where the boot loader as well as the filing indexing system are kept. The operating system needs to acquire this information in order to know which file is located in where in the hard disk.

If you accidentally trash this area you will destroy the means of accessing the files. You must have done some formatting on the area or written something over it before the information could disappear. The superblock is not part of the filing system and so cannot be accidentally overwritten.

It is possible while the hda2 was in transit an interruption occurred resulting the vital information held in the temporary area disappeared.

[axis77]

i found this not to long ago about recovering boot partitions, hope it helps
http://www.swerdna.net.au/linhowtorecoverboot.html

[MathBluster]

Well, I've gotta say, saikee's diagnosis really bummed me out, so I sought a second opinion from doctor TestDisk. The good doctor couldn't find the superblock either, but it did provide me with some very encouraging news. I got it to privide me with a list of partitions, which was the same as we've been seeing, and it not only recognised the big one as a Linux partition, it gave me the option to list the files on it. My files are there. It looks normal. In light of this discovery, I'm not quite willing to write off my files quite yet.

And, axis, I'm not really feeling this as a boot issue. If I get to the point where booting is my main problem, I'll count myself lucky.

Well, now that I know my files exist, though they can't be mounted or anything, is there any way to recover them? I've got a stack of blank DVDs that's what it takes, though, of course, mounting the partition is a prerequisite.

[saikee]

The Dos version of Testdisk has a facility to write the re-built partition table. I haven't used the Linux version myself but I expect this version of Testdisk to write the partition too, otherwise what is the point of salvage the information.

[MathBluster]

I'm back! Ish. I'm using the same old Ubuntu LiveCD, and I can mount my Linux partition. Somehow, in the mayhem, something happened to the NTFS one, but hey, nobody cares.

Thanks so much for all of your help, saikee. All that's left is getting it bootable again. That shouldn't be too bad, should it?

[saikee]

Piece of cake to make a Linux bootable, I would say.

Just boot up Ubuntu, click accessory then terminal and type

sudo grub
geometry (hd0)
find menu.lst

Grub should confirm to you the first boot disk (hd0) has 4 partitopn number 0, 1, 4 and 5 reprresenting hda1, hda2, hda5 & hda6, as Grub counts from 0. The geometry command is to check (hd0) is indeed your hda disk as you should have another disk with that number of partitions. I am just trying to play safe not to mess up anything.

The last command makes Grub report back to you where Grub is hiding in the disk as a partition has menu.lst is where Grub hangs out. You should get an answer like

(hd0,1)

That confirms hda2 has the Linux inside. So you tell Grub this is the root of the Linux you are interested so set itself up in the MBR of (hd0) by command

root (hd0,1)
setup (hd0)
quit
sudo reboot

Your Linux should now boot.