ckk+@andrew.cmu.edu (Chris Koenigsberg) (09/13/89)
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+@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.
kandler@lan.informatik.tu-muenchen.dbp.de (Matthias Kandler) (09/14/89)
This is what newfs on my ds3100,Wren configuration says: /dev/rrz0g: 1075616 sectors in 1992 cylinders of 15 tracks, 36 sectors 550.7Mb in 125 cyl groups (16 c/g, 4.42Mb/g, 2048 i/g) super-block backups (for fsck -b#) at: 32, 8720, 17408, 26096, 34784, 43472, 52160, 60848, 69536, 78224, 86912, 95600, 104288, 112976, 1 173024 605120, 613808, 622496, ..... ~~~ Matthias Kandler Inst. f. Informatik LOC=lan.informatik.tu-muenchen.dbp.de TU Muenchen kandler@LOC Postfach 20 24 20 kandler%LOC@{unido.uucp,relay.cs.net} D-8000 Muenchen 2 Telefon: (089) 2105 2025