[SOLVED] Error shrinking Ext2 partition

Thanks for the really quick response. 

Sorry to mislead you, when I say it 'bombed out', gparted didn't actually crash - it gave up with an error message "Either the superblock or the partition table is likely to be corrupt".   I dont recall the exact text but the text I get  when I try to boot the PC is very similar...

Partition end 153174765  Superblock says 19146845

Lets' call the first *A* and the 2nd *B*.  It then goes on to say:

Checking root file system: filesystem size (according to superblock) is *A* blocks.  
The physical size of the device is *B* blocks.  
Either the superblock or the partition table is likely to be corrupt.
/dev/hda1: UNEXPECTED INCONSISTANCY: run fsck manually.

Gparted is now no longer able to do anything with hda1 (sda1 on the liveCD) - it says unable to read the contents of this filesystem.  (Incidently, I had thought the partition was ext2, but gparted is now reporting it as ext3.  I was probably just assuming ext2 as thats what I normally use.)

I hope I didn't mislead with the vagueness on the error message in my original post.

I tried running sudo testdisk.  I think that matches the partition table - its a bit hard for me to tell as it's reporting in CHS, while sfdisk and parted are in sectors and blocks.

80Gb 156301488 sectors
CHS 9729 255 63
Current partition structure
No Ext2, JFS, Reiser, cramfs or XFS marker
1 * Linux 0   0  2   2575  67  52  41371647
line repeated
2 E Extended  9534 175 32  9729 80 63  3126722
No Ext2 , JFS etc,
5 L Linux  9534  175 33  9729  80 63  3126721
line repeated

I think this matches the sfdisk sectors & the cylinders match the sfdisk -l values, so I think that's ok.  On that basis I'll try and work out how to get testdisk to rewrite the partition table tonight.

Thanks again for the help.

I have the problem fixed.  It turned out not to be the partition table at all, rather it was the superblock that was corrupted.    During the shrink process I suspect that the superblock was either not written to, or written incorrectly.  I dont know if gparted writes to the superblock before or after writing the partition table - I suspect both have to agree before it will even read the contents of the filesystem.

For anyone having similar issues, here's what I did to resolve the problem.  I believe you can skip steps 1 through 3:
1) Zero'ed out the partition table with cfdisk (on the gparted cd)
2) Rewrote the partition table with sfdisk with the original cylinder values.  I couldn't get fdisk to accept sector start of less than sixty-something, which is why I used sfdisk.
3) Rebooted the live CD.

At this point gparted still refused to read the filesystem - showing the partition with an exclamation mark.  After some reading tried to check the superblock.
4) Ran e2fsck

sudo e2fsck -vnf /dev/sda

The v=verbose, f=force a check even if things look ok, n=don't make any changes to disk
This reported a bad superblock.  (Note that in retrospect I dont think using the drive 'sda' is valid - and it might always report a bad superblock, I think I should have used the partition 'sda1'). 
I wasnt sure if e2fsck was the right tool for ext3 (subsequent reading showed it will work on ext2 and 3) so I double checked...
5) I ran fsck - this seemed to just call e2fsck

sudo fsck -nv /dev/sda1

This gave the message that the superblock or the partition table are corrupt, which was the original problem.  This also noted a block where reading the inodes failed.
It seems that you have to run e2fsck (or fsck) on the partition (/dev/sda1 in this case), rather than the drive (/dev/sda).
6a) To repair the superblock, I ran sudo testdisk.  This showed the backup superblocks locations being at 32768, 98304, 163840 & several more.  According to this informative link http://www.linuxcertified.com/linux-recovery.html, the location of the backup superblocks (for ext2 anyway) depends on the filesystem blocksize.
Another way to find the location of the backup superblocks, without wading through testdisks menus, is
6b) dumpe2fs

sudo dumpe2fs /dev/sda1 | grep -i superblock

7) Verify the backup is ok

sudo e2fsck -v -n -f -b 32768 /dev/sda1

where
v=verbose,
n=don't write any changes back to disk (we're just checking at this point)
f=force (check it anyway)
b 32768 = sector of backup block to check, determined from testdisk or dumpe2fs
/dev/sda1 = partition that has the bad superblock that gparted cant read.

8) If no errors are reported you can, rerun e2fsck without the '-n' which tells it to fix the primary superblock using the info from the backup.

sudo e2fsck -v -f -b 32768 /dev/sda1

If errors were reported at step 7 you can either try the next backup superblock (eg 98304), or run it again without the '-n' then answer yes when prompted to let e2fsck try to fix the errors.   

To verify the problem is fixed, run e2fsck (or fsck) on the partition again [step 5] and see that no errors are reported.

I could then run gparted ok.

It sounds a lot worse than it is.  The steps were fairly simple - it was finding it all out that took me ages.