> Does that mean that my "wrong fs type, bad option, bad superblock..."
> error is in fact successfully reading the superblock, then? Omnibus
> errors like that are among my least favourite. "It could be A, or B,
> or C: I'll let you figure out which" :-(

You could still pick up the program's hint and check the output of the
'dmesg' command for any further information.

> Filesystem magic number: 0xEF53

This is interesting. The magic number of this superblock instance is
correct.

> >You could try working with 'debugfs' as a last resort.

Okay, this is not the last resort, as I point out at the end of this
mail.

> root@1[~]# debugfs /dev/hda1 debugfs 1.38 (30-Jun-2005) /dev/hda1:
> Can't read an block bitmap while reading block bitmap

I think the first super block is alright, but some group descriptors are
damaged. Bites me why e2fsck and even debugfs bail out. At least debugfs
should assume a "you know what you're doing and I'm doing my best to
help you at it" stance. This sucks.

> Now if I'm right that my "mount" attempts had got the right
> superblock, this seems rather strange. "Bad magic number" means I gave
> it a garbage block number, right?

Not necessarily. It could just be damaged partially.

> Does debugfs want these to be specified in a different format, like
> divided by 1024 or 4096 or something?

No.

> GRUB might be a great piece of software, but its ext2 support is
> really just a hack. If GRUB can do it, how hard can it be? I mean, I
> guess I should be grateful that anything works at all, but still.

At this point I have two other suggestions for you:

  1) Try some other file system driver, e.g. one from a BSD (there are
  Live CDs out there, just search distrowatch.com).

  2) Use forensic tools. A search on freshmeat.net for 'forensic' should
  produce lots of those. I think this is exactly what you need now.