Newsgroups: comp.unix.xenix.sco
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!frnkmth!bill
From: bill@franklin.com (bill)
Subject: Re: fsck fails on /dev/root under SCO (was Re: fsck Recovery From Crashes)
Message-ID: <4Jun91.151011.345@franklin.com>
Keywords: inode file directory lost+found
Organization: Franklin Electronic Publishers
References: <35@metran.UUCP> <1991Jun02.184143.15566@virtech.uucp> <3206@artcom0.north.de>
Date: Tue, 4 Jun 91 15:10:11 GMT

When fsck'ing the root file system, you must always reboot your
system immediately after the fsck, if fsck changes anything, and
you must do so without syncing. (There are some exceptions, but
why bother?)

There is probably an option on your fsck that will cause it to do
the necessary reboot automatically. You should use it if it is
there. If fsck won't do an automatic reboot but will return an
indication that it has changed the file system, you should have
your startup script immediately bring your system down when fsck
indicates a change. NB: the shutdown script will do the sync, so
you can't use it. You may have a command like uadmin or something.

In article <3206@artcom0.north.de> pf@artcom0.north.de (Peter Funk) writes:
: The superblock or the free list header (I not familar enough with the
: internals) is NOT correctly rewritten from fsck, leaving the whole file
: system somehow corrupt under certain circumstances.

What happens is this: fsck is doing I/O directly to the disk. When
it updates the superblock, it writes the correct thing to the
disk. However, there is a copy of the superblock sitting in the
kernel somewhere, which is *not* updated (for what may have been
an adequate reason way back when but for what is now no good
reason at all). If anything causes that old copy of the superblock
to be written to the disk, you lose.

: Since I've discovered this problem, we instruct our customers to use
: a specially prepared "emergency boot"-floppydisk, which automatically runs
: 'fsck' from floppy on /dev/hd0root.  This workaround solves the problem,
: but the manual handling is ... uh.... cumbersome ? In german I would
: call it "nervig" ;-)

If you don't have some way with fsck to force a reboot, what you
want to do is this: make sure that your systems come up in single
user mode. Instruct your customers to run fsck on the root
manually, reboot without *any* other commands being entered after
the fsck, and then enter the normal operating mode (via init 3 or
whatever).

: P.S.: Excuse my awful english grammar and spelling

Actually, it is quite good. There are many supposedly literate
natives who don't do as well. The only glaring things were those
extra capital letters. We're nowhere near as consistent as you
Germans on what we capitalize. :-)