*BSD News Article 6619


Return to BSD News archive

Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!sgiblab!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Corrupted directory
Message-ID: <1992Oct16.033843.9805@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University  (Ogden, UT)
References: <1bd165INNrfe@iskut.ucs.ubc.ca> <Bw4Fv7.M4L@unx.sas.com> <5232.9210151353@thor.cf.ac.uk>
Date: Fri, 16 Oct 92 03:38:43 GMT
Lines: 50

In article <5232.9210151353@thor.cf.ac.uk> spedpr@thor.cf.ac.uk (Paul Richards) writes:
>In article <Bw4Fv7.M4L@unx.sas.com> sastdr@torpid.unx.sas.com (Thomas David Rivers) writes:
>|
>|Regarding this infinite reboot cycle; I recently applied the entire
>|beta patchkit (from a new, clean, installation of 386bsd 0.1) and
>|began getting this problem.
>|
>|I.e. If I have to shut down for some reason, or the power goes out; the
>|     machine reboots.  Root gets fsck'd and repaired; and the
>|     machine reboots again.  Then there is another problem with the
>|     fsck of root, and the machine reboots, etc... encountering the
>|     same problem over and over.
>|
>| I've now seen this happen on two machines to which I applied the beta
>| patchkit.  It did *not* happen on these machines using the kernel I 
>| had patched together from news articles.   This means (at least to me)
>| there is some patch applied by the patchkit which I had not otherwise
>| applied in my kernel, that is causing the problem.

I -think- the offending patch is patch00038, which updates the error
reporting mechanism for bad sector reporting for read errors being reported
to user programs (with this patch in place, trying to install the bin01
distribution from files located on a bad sector actually fails where you
would want it to, rather than in the decompression some time later).

Backing out this patch does not require deinstallation of other patches.  It
should be noted that the correct fix is to adjust the fsck code (or to return
the expected value to the fsck code) so that the checking is not aborted by
the error.

Generally, this error will not occur on disks installed with a dist.fs with
the patches applied; instead, it will occur on disks installed on top of
bad sectors (without the error being caught) and to which the patches are
later applied.

I don't know how the author of the patch (Frank Maclachlan) handles this on
his drives, but I suspect that he does one of the two approaches above.


					Terry Lambert
					terry@icarus.weber.edu
					terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-- 
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------