Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ucsd!helios.ee.lbl.gov!nosc!crash!pnet01!jca
From: jca@pnet01.cts.com (John C. Archambeau)
Newsgroups: comp.unix.xenix
Subject: Re: Corrupted Filesystem * IDEAS *
Message-ID: <2544@crash.cts.com>
Date: 6 May 90 19:36:12 GMT
Sender: root@crash.cts.com
Organization: People-Net [pnet01], El Cajon CA
Lines: 63
X-Local-Date: 6 May 90 12:36:12 PDT

rick@crash.cts.com (Rick Stout) writes:
>In article <2527@crash.cts.com> jca@pnet01.cts.com (John C. Archambeau) writes:
>>rick@crash.cts.com (Rick Stout) writes:
>>>In article <3295@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>>>>>I've yet to see a disk drive without a second superblock at 16 (/etc/fsck -b16)
>>>>
>>>>I've seen plenty of them.
>>>>
>>>>Some of them were running the BSD file system; they had it at 32, not 16.
>>>
>>>Whats the purpose of a second superblock?
>>>If the first one is corrupted can you boot off the second?
>>
>>Or if a bad spot manifests itself at the first superblock.
>> 
>So how do you boot off the second superblock?
>
>Do you have to boot off a boot and root floppy, mount the
>hard disk and recover the superblock somehow?

Depends on how bad the superblock is damaged.  If you get a disk write error
during a sync, then the primary superblock has manifested a bad spot, but if
your file system supports backup superblocks, then the writes to the
subsequent superblocks will be ok, just that the write to the first superblock
didn't take so you're going to have to start reading from the backup
superblocks.

If your root file system has the the bad superblock and reading the backup
superblock(s) just doesn't help.  I am sorry to say that your root file system
is gone.  But if you are smart in laying on your file systems, the only thing
you should have in your root file system should be those things that you can
reload off of your distribution master tape or disk.  You could try dinking
with a file system debugger, but that can be messy business and sometimes can
make matters worse.  Someone suggested doing a dd of your superblock every
night.  Now that actually is a good idea because if your superblock is blown
away, you are going to have some serious problems.

You can try booting from floppy in single user mode and do an fsck and set the
option to read the backup superblock(s) instead of the primary.  If that
works, you're in business.  Backup your file system with the bad superblock
and do a surface analysis of the file system immediately.  If you have a bad
spot, better let Xenix know about it.

Unfortunately, I'm not well versed in Xenix file system specifics.  I'm
relaying my knowledge of the BSD 4.2 file system since I support Sun
workstations.  I am getting more well versed with SCO Xenix, but it has been
a problem setting aside time just to pick up Xenix specifics since it's not
really System V or BSD 4.2, it's to some degree in the middle from my (little)
understanding.

I just started with Xenix about a month ago and I'm still trying to get the
can and can nots down.
 
     // JCA

 /*
 **--------------------------------------------------------------------------*
 ** Flames  : /dev/null                     | Xenix is the ONLY thing
 ** ARPANET : crash!pnet01!jca@nosc.mil     | Microsoft did right.
 ** INTERNET: jca@pnet01.cts.com
 ** UUCP    : {nosc ucsd hplabs!hd-sdd}!crash!pnet01!jca
 **--------------------------------------------------------------------------*
 */