Ok, I know there are many threads about recovering damaged superblocks. I've spent 3 evenings reading them and trying what they suggest. Invariably the commands do nothing except to report bad or missing superblocks. I've removed the physical disk from the machine and am working with a dd image file (/mnt/image). I can mount what used to be hdc1 and read its files with no problem. I'm trying to recover partions hdc6 and hdc7.

$ mmls /mnt/image -b

DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

Slot Start End Length Size Description
00: ----- 0000000000 0000000000 0000000001 0512B Primary Table (#0)
01: ----- 0000000001 0000000062 0000000062 0031K Unallocated
02: 00:00 0000000063 0031262489 0031262427 0014G Linux (0x83)
03: 00:01 0031262490 0320159384 0288896895 0137G DOS Extended (0x05)
04: ----- 0031262490 0031262490 0000000001 0512B Extended Table (#1)
05: 01:01 0031262491 0169935569 0138673079 0066G DOS Extended (0x05)
06: ----- 0031262491 0031262491 0000000001 0512B Extended Table (#2)
07: ----- 0031262492 0031262615 0000000124 0062K Unallocated
08: 02:00 0031262616 0169935569 0138672954 0066G Linux (0x83)
09: 02:01 0169935570 0311066594 0141131025 0067G DOS Extended (0x05)
10: ----- 0169935570 0169935570 0000000001 0512B Extended Table (#3)
11: ----- 0169935571 0169935632 0000000062 0031K Unallocated
12: 03:00 0169935633 0311066594 0141130962 0067G Linux (0x83)
13: ----- 0311066595 0311066657 0000000063 0031K Unallocated
14: 01:00 0311066658 0320159384 0009092727 0004G Linux Swap / Solaris x86 (0x82)
15: ----- 0320159385 0320173055 0000013671 0006M Unallocated

$ fdisk -ul /mnt/image
Disk /mnt/image: 0 MB, 0 bytes
255 heads, 63 sectors/track, 0 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xcd6dc8a3

Device Boot Start End Blocks Id System
/mnt/image1 * 1 1946 15631213+ 83 Linux
Partition 1 has different physical/logical endings:
phys=(1023, 254, 63) logical=(1945, 254, 63)
/mnt/image2 1947 19929 144448447+ 5 Extended
Partition 2 has different physical/logical beginnings (non-Linux?):
phys=(1023, 254, 63) logical=(1946, 0, 1)
Partition 2 has different physical/logical endings:
phys=(1023, 254, 63) logical=(19928, 254, 63)
/mnt/image5 19364 19929 4546363+ 82 Linux swap / Solaris
/mnt/image6 1947 10578 69336477 83 Linux
/mnt/image7 10579 19363 70565481 83 Linux

Partition table entries are not in disk order

------------------------

I gather from other threads that the standard way to restore a superblock is to use dumpe2fs to get the duplicate superblock offsets and then use fsck to restore one of them. However, all the examples of dumpe2fs I've seen specify a filesystem mount point, such as "dumpe2fs /dev/hdc6", which seems like Catch-22 since I can't mount the partitions. If I try dumpe2fs on the image file here is the result:

$ dumpe2fs /mnt/image

dumpe2fs 1.40.8 (13-Mar-2008)
dumpe2fs: Bad magic number in super-block while trying to open /mnt/image
Couldn't find valid filesystem superblock.

===========================

Am I using dumpe2fs correctly? Or is this "bad magic number" the problem? How do I extract the locations of the superblock copies from a disk image file?

===========================

In another LinuxQuestions.org thread a guy who was getting similar errors was able to mount his partition by computing an offset. Unfortunately I closed that tab and can't find the thread again, but here's what happened when I used his command and changed the numbers to fit my situation. As you can see from the above listing, 1947 is the starting point of my image6 partition.

$ mount -t ext3 -o loop,offset=$[(1947-1)*8225280+63*512] /mnt/image /mnt/hdc6

mount: wrong fs type, bad option, bad superblock on /dev/loop1,
missing codepage or helper program, or other error
In some ases useful info is found in syslog - try
dmesg | tail or so

$ dmesg | tail

[309165.929083] EXT3 FS on loop0, internal journal
[309165.929107] EXT3-fs: mounted filesystem with ordered data mode.
[309394.798288] CIFS VFS: cifs_mount failed w/return code = -22
[309402.645926] VFS: Can't find ext3 filesystem on dev loop1.
[309424.307418] EXT3-fs: journal inode is deleted.
[309431.881229] EXT3-fs: journal inode is deleted.
[319938.367887] CIFS VFS: No writable handles for inode
[319938.367959] CIFS VFS: No writable handles for inode
[324978.276767] VFS: Can't find ext3 filesystem on dev loop0.
[326227.446251] EXT3-fs: journal inode is deleted.

-------------------------

From what I've read it seems like fsck might fix things if only I could determine where the superblocks are. But how?

Your image is presumably a full disk image - dumpe2fs will require you to resolve to a valid filesystem (within a partition) before you can use it. Go search for posts by jschiwal and you'll probably find the calculation you were looking for.