Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!jtkohl
From: jtkohl@athena.mit.edu (John T Kohl)
Newsgroups: comp.unix.aux
Subject: Re: Some notes on problems in A/UX
Summary: Root filesystem lossage
Keywords: Root filesystem
Message-ID: <6713@bloom-beacon.MIT.EDU>
Date: 17 Aug 88 13:23:43 GMT
References: <17331@gatech.edu> <15011@apple.Apple.COM> <7903@mhuxu.UUCP> <571@sequent.cs.qmc.ac.uk> <5123@hoptoad.uucp>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: jtkohl@athena.mit.edu (John T Kohl)
Organization: Massachusetts Institute of Technology
Lines: 21

In article <5123@hoptoad.uucp> hugh@hoptoad.uucp (Hugh Daniel) writes:
> ...
>	(Question: Has anyone else run into cases where fsck finds a 
>	problem, reboots, then finds ANOTHER problem so bad it has to
>	reboot a second time?  I have seen this in A/UX and never 
>	elsewhere.)
> ...

Yes.  We see this very often here at Project Athena, with the BSD
filesystem.  If /etc/passwd gets corrupted in some fashion (say, a bad
link count), fsck will happily re-set it and cause a reboot.  But since
fsck uses /etc/passwd to display owner names of broken files, the kernel
will update the inode when fsck closes the file.

So fsck has absolutely no chance of ever fixing this problem; each
reboot turns up the same problem.  Manual intervention is needed.

John Kohl 
Digital Equipment Corporation/MIT Project Athena
(As usual, the opinions expressed above do not necessarily reflect the
opinions of my employer. :-)