*BSD News Article 19592


Return to BSD News archive

Newsgroups: comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!math.ohio-state.edu!cs.utexas.edu!wotan.compaq.com!moxie!limbic!gil
From: gil@limbic.ssdl.com (Gil Kloepfer Jr.)
Subject: Re: bad144 problem?
Organization: Southwest Systems Development Labs, Sugar Land, TX
References: <1993Aug15.214815.3942@limbic.ssdl.com> <D> <9322908.27770@mulga.cs.mu.oz.au>
Message-ID: <1993Aug17.121710.1498@limbic.ssdl.com>
Date: Tue, 17 Aug 1993 12:17:10 GMT
Lines: 34

In <9322908.27770@mulga.cs.mu.oz.au> Jan Jaeger <janj@acci.com.au> wrote:
[Mentions badsect flag, checking location of bad144 table, and problem
with no disklabel]
>Jan Jaeger

These are all really good points -- of the three, I have handled the
badsect flag and the disklabel just fine.  I haven't checked the location.
I'll look into that.

For those who have had the disklabel problem - I discovered this bug several
weeks back, and the problem is that one of the patches undoes setting the
DKFL_QUIET flag when accessing the raw partition (/dev/rwd?d - not c as some
of the comments imply).  I checked with the author of the patch and he
agrees that this is a problem, and I forwarded the bug (and fix) to the
central bug reporting address via sendbug.  Basically this problem will
complain you don't have a disklabel, and when you try to put one on the
disk, it will still complain you don't have one!  A good interim fix is
to boot the install kernel and label your disks using that kernel, then
boot your custom/updated kernel and make whatever changes to the label
you need to make.

I suspect that my bad144 table is in a "good" area of the disk.  I have
reason to believe from the one e-mail reply that I've gotten that there
are some problems with bad144.  I have shut down my system with the two
ESDI drives and brought the same system (sans bad files) to my other
system (using IDE drives) and made a stripped-down system enough to keep
my netnews/mail feeds going.  I'm going to see if I can identify completely
and fix the problem with bad144 checking and post my results to the net.
However, I would really prefer not to have to reinvent the wheel, so if
anyone knows of a solution to this (other than using both forms of
bad block control and facing my computer toward Mecca) please let me know.

Gil
(gil@limbic.ssdl.com)