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 KohlDigital Equipment Corporation/MIT Project Athena (As usual, the opinions expressed above do not necessarily reflect the opinions of my employer. :-)