Suggestions after gpart and e2retrieve both failed?

[parted . mexon]

Hi,

In an attempt to repartition my hard drive using parted, I appear to 
have wrecked it :-(  Now I'm trying to recover the data as best I can. 
I've already tried gpart and e2retrieve, neither of which seems to work. 
  But there are hints that in fact this situation is recoverable.  So 
I'm looking for suggestions as to what to try next.

What I originally wanted to do was free up 5GB or so on my disk for a 
Windows 2000 install.  My disk is ~160GB big.  The existing layout was 
one huge primary ext3 partition at the start, then an extended partition 
containing a gig or so of swap space.

Using parted under Knoppix, I tried using "resize" to free up about 10GB 
at the end of the ext2 partition.  I then made a new win32 partition in 
the space.  I had a dim memory that Windows always wanted to be the 
first partition, but I couldn't remember if that was actually the first 
*disk*.  Anyway, I thought it couldn't do much harm to try, so I did. 
The Windows 2000 install failed with a message about a disk error.  I 
rebooted into my Linux partition, and all was well.  Phew.

So I tried again.  This time I used SystemRescueCd, which I'd found on 
the internet and thought looked interesting.  I deleted the win32 
partition.  Then I tried to move the existing partition up a few GB.  I 
knew that "move" doesn't like moving to overlapping partitions, so I 
used "resize" instead.  I don't know the exact command, but it was 
something like "resize 1 5000 <some large number>".  This simply resized 
my partition to its original position, at the *start* of the disk; no 
free 5GB at the start.  I think I then tried "move".  At this point 
parted segfaulted, and I gave up.  Note that I can't be 100% sure about 
this sequence of events - but I didn't run any commands except "resize" 
and "move", and the version of parted on SystemRescueCd most definitely 
segfaulted.

Then, when I tried to reboot Linux, it refused to boot.  Interestingly, 
GRUB actually manages to find the right kernel file: even when I edit 
the command and "tab out" the filename.  The kernel file does boot: it's 
only when it tries to mount the root filesystem that it fails.  So 
somehow, someway, some recovery tool should be able to recover my kernel 
image, and probably more besides.

I tried running gpart to see if the partition table was confused. 
Unfortunately, it seemed to recognise some vestigial win32 partition 
instead of the ext2 partition I was really after:

Begin scan...
Possible partition(DOS FAT), size(6495mb), offset(145000mb)
Possible extended partition at offset(151495mb)
   Possible partition(Linux swap), size(1129mb), offset(151495mb)
End scan.

Checking partitions...
Partition(DOS or Windows 95 with 32 bit FAT, LBA): primary
Partition(Linux swap or Solaris/x86): primary
Ok.

Guessed primary partition table:
Primary partition(1)
   type: 012(0x0C)(DOS or Windows 95 with 32 bit FAT, LBA)
   size: 6495mb #s(13301820) s(296961525-310263344)
   chs:  (1023/254/63)-(1023/254/63)d (18485/0/1)-(19312/254/63)r

Primary partition(2)
   type: 130(0x82)(Linux swap or Solaris/x86)
   size: 1129mb #s(2313296) s(310263408-312576703)
   chs:  (1023/254/63)-(1023/254/63)d (19313/1/1)-(19456/254/62)r

Primary partition(3)
   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

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

I then tried e2retrieve, putting the results on an NFS mount. 
Unfortunately, this appeared to throw some kind of exception before it'd 
recovered a single file:

99.24% (7/70/2440372 different superblocks, 94241 dir. stubs) 
829128282:57:35/8
99.25% (7/70/2440577 different superblocks, 94241 dir. stubs) 
829128282:57:36/8
99.26% (7/70/2440775 different superblocks, 94241 dir. stubs) 
829128282:57:37/8
99.27% (7/70/2441049 different superblocks, 94243 dir. stubs) 
829128282:57:38/8
99.28% (7/70/2441377 different superblocks, 94243 dir. stubs) 
829128282:57:39/8
99.29% (7/70/2441581 different superblocks, 94244 dir. stubs) 
829128282:57:40/8
99.30% (7/70/2441783 different superblocks, 94244 dir. stubs) 
829128282:57:41/8
100.00% (7/70/2441351 different superblocks, 94291 dir. stubs)

Scan finished

Superblocks:
 #1 (155131640 Ko) : copy 0 1 3 5 7 9 25 27 49 81 125 243 343 625 729
 #2 (155131640 Ko) : copy 0 0 0 0
 #3 (155131640 Ko) : copy 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 #4 (155131640 Ko) : copy 0
 #5 (155131640 Ko) : copy 0 0
 #6 (155131640 Ko) : copy 0 0
 #7 (155131640 Ko) : copy 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0
 #8 (60000 Ko) : copy 0 1 3 5 7
Superblock #7 has been choose.

*** glibc detected *** double free or corruption (!prev): 0x0805b428 ***
Aborted

I don't really understand what that information means, but #1 looks far 
more promising to me than #7.  Clearly #8 is one of the smaller 
partitions I attempted to create.  As far as I can tell, e2retrieve 
doesn't have any way for me to override which superblock it uses.

Here's what my partition table looks like now:

Information: The operating system thinks the geometry on /UNIONFS/dev/hda is
19457/255/63.  Therefore, cylinder 1024 ends at 8032.499M.
(parted) p
Disk geometry for /UNIONFS/dev/hda: 0.000-152627.835 megabytes
Disk label type: msdos
Minor    Start       End     Type      Filesystem  Flags
1          0.031 151495.773  primary   ext3        boot
2     151495.774 152625.344  extended
5     151495.805 152625.344  logical   linux-swap

Well, that's all the information I can think of including here.  Please 
let me know if you have any suggestions.  I guess my next step is to try 
to modify the source code of e2retrieve to make it use the right 
superblock: but I have no idea about ext2 filesystems, and I don't even 
know what a "superblock" is, so I'd rather not if I can avoid it. 
Another possibility is to try e2salvage; but to do that, I'll need to 
buy a whole new 160GB hard disk, in case it fails and trashes my system 
even worse.  And since it's not at all guaranteed to work, I'd rather 
leave that solution until last.

Thanks,
Matthew Exon