finding alternate superblocks on a CDC WrenV

[Chris Koenigsberg]

Forgive me, I have not been reading this newsgroup for a while so I
apologize if this was already discussed recently. (someone please send
me mail if it was! to ckk+ at andrew.cmu.edu)

I have to recover some files for someone off the G partition of a CDC
WrenV disk. The workstation is a Decstation 3100 ("pmax"), running
Ultrix 3.0. Can anyone offer me some advice?

Somehow it seems to have gotten the original (#16) and first alternate
(#32) superblock corrupted. Fsck says the magic number is wrong.
/etc/dumpfs shows things that don't look too good either (I don't have
the machine right here on hand so I don't remember exactly what dumpfs
showed us but we really didn't know how to read it anyway :-).

They were running a nonstandard kernel in which they had changed some
partition table information in the file scsi_data.c, adding an entry for
the CDC WrenV. They wanted to use the full 700+ megs on the disk. (I
wonder if it was really necessary for them to modify the kernel - I know
someone else who manages by just changing /etc/disktab and not touching
the kernel!). They also have a modified /etc/disktab but I think the
size of the G partition is slightly different between the default in
their kernel and in their /etc/disktab.

Anyway, I was asked to put a different kernel on their machine (one with
support for the remote Andrew FileSystem). So I put on a new vmunix,
saved the old as vmunix.saved, and by accident, autobooted it so it
started running their /etc/rc........I had copied a modified rc which
went with the new kernel but I forgot to rename it as /etc/rc.

For some strange reason they had put "/etc/chpt -d" as the first line of
their rc file, I don't understand why (maybe due to the inconsistency
between their kernel's default partitions and their /etc/disktab).
Anyway, the AFS kernel came up, presumably ran this chpt command to put
ITS default partition table onthe disk......... and fsck failed on the G
partition, saying "Cannot read block 16".

After this, neither the new nor the old kernel would boot - they would
get a "panic:vstab" every time.

So we attached the disk to another system with a good disk already on it
and another kernel, and played around with /etc/chpt -pg to rewrite the
partition table by hand, restoring the values they had been using. (we
could read their partition table from their A partition)

After this, we could boot their original kernel again, and it could read
the A partition just fine, but the G partition still had problems.
Instead of "Cannot read block 16", however, fsck would say "Invalid
superblock: wrong magic number". We would try guessing other numbers for
alternate superblocks, starting with 32, and fsck always says the magic
number is wrong. 

So even though we thought we put back the partition table to the state
it was in before I came along to help them :-), the G is still
unreadable. Attempts to mount it w/o fscking fail with "/dev/rz1g - No
such device or address".

I am hoping that something strange has offset things so the superblocks
are really there but we can't find them until we fix something. Or that
the first few superblocks in the first few cylinder groups were trashed
somehow, but that we can find an alternate one farther out on the disk,
and fsck can use that to repair the disk.

These people really have a directory with about 30 files that they
really want to recover off this G partition. I am now thinking of
strategies for proceeding. Any advice?

We've thought of:

Running fsck in a dumb loop, trying each and every block as a superblock
until we either find a good one or run off the end of the disk.

Writing a program based on fsck and mkfs that will read through the disk
block by block, telling us when it finds one that looks like a valid
superblock.

Somehow reading through the raw disk, searching for the names of the
files they want, going to the inodes where they are, and reading them
off.