well it seems my summary brought more interesting mail than
did the original posting.
original problem:
due to a hard crash the superblock had been corrupted.
I did a fsck -b 32 <filesystem>. and successfully checked
the disk. But upon reboot the system again complained of
a bad super block. The only way I found to correct the
problem was to dump/newfs/restore the partition. NOT fun
on a 500MB partition that is nearly full.
Question was how do you repair the superblock.
The most common answer was the method I described above. Not
the answer I wanted but at least it confirmed what I had found.
A number of responses indicated that the fsck -b followed by
a reboot -n , so the disks dont get synced, would fix it. I thought
so too but couldn't get this to work. I got a response from
kevins@Aus.Sun.COM (Kevin Sheehan {Consulting Poster Child})
and he stated that it is supposed to but was never implemented.
The way to fix the superblock is to copy a good alternate over
the primary. I havent actually used this techinique but it seems
logical.
>Another more interesting possibility involves using dd like this:
>
>dd if=/dev/rsd0a skip=32 of=/dev/rsd0a seek=16 count=16
>Note that the "skip" parameter is the number of the alternate superblock,
>seek is the number of the primary superblock (always 16 in SunOS), and count
>is 16 (8192 bytes, the size of the superblock in SunOS). Again, after doing
>something like this through the raw (character) device, you must reboot withOUT
>sync-ing the disks, or the kernel will overwrite what you just fixed with its
>bad, in-memory, copy of the superblock.
> From: Mike Raffety <miker@sbcoc.com>
secondly bzs@world.std.com (Barry Shein) writes:
>You should be able do it with dd in two minutes by just unmounting the
>file system, copying the backup superblock to the missing one, and
>fsck'ing the disk as normal to make sure everything gets updated.
>
>Or write a fairly trivial C program (see /usr/include/sys/fs.h) which
>just copies the superblock (the disk must be unmounted in either
>case.
A short c program followed but I'll delay distribution until
I can check it out thouroughly as barry indicates strongly that
it is not complete and not tested.
Malcolm Strickland chuck-strickland@orl.mmc.com
Phone: 407-356-5909
Martin Marietta Electronic Systems Fax: 407-356-5651
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:20 CDT