Subject: Re: [repost] --
To: Mike Long <mike.long@analog.com>
From: steve farrell <sfarrell@healthquiz.com>
List: netbsd-help
Date: 02/20/1997 11:58:11
thanks for the response!

now we're on to something.  every time i reboot i get:


/dev/rsd0a: UNREF FILE I=8569  OWNER=root MODE=100600
/dev/rsd0a: SIZE=0 MTIME=Feb 18 09:25 1997  (CLEARED)
/dev/rsd0a: FREE BLK COUNT(S) WRONG IN SUPERBLK (SALVAGED)
/dev/rsd0a: 895 files, 31819 used, 4420 free (148 frags, 534 blocks, 0.4% fragmentation)
/

and no matter how many times i fsck (and say i want to fix it), it
just stays there.

-------------

bash-2.00# fsck -f /dev/rsd0a
** /dev/rsd0a
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
UNREF FILE I=8569  OWNER=root MODE=100600
SIZE=0 MTIME=Feb 18 03:25 1997 
CLEAR? [yn] y

** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? [yn] y

898 files, 31829 used, 4410 free (138 frags, 534 blocks, 0.4% fragmentation)

MARK FILE SYSTEM CLEAN? [yn] y

--------------------

is there any way to fix this problem?  root is (naturally) a
relatively small partition, and i have another disk here, so i could
just reinstall on the other disk, and not use this bad root
partition. what's my best bet?

thanks again...

(btw -- i'm confused about this kind of error b/c i thought that SCSI
disks did automatic error detection, and didn't use bad blocks on the
disk *transparently*.  any pointers to more info about this?)

note that ranlib is on /dev/rsd0h, not /dev/rsd0a, and the file that's
being troublesome here is not executable. 

more:

it never occurred to me that this was a hardware problem, so i never
did the obvious: compile from the *identical* SS1 i've got here.  i
just did this over nfs and ranlib works fine.  so your diagnosis was
right on the money.

>
>>Date: Thu, 20 Feb 1997 06:56:37 -0600
>>From: steve farrell <sfarrell@healthquiz.com>
>>
>>--sorry-- not trying to be obnoxious, but i didn't get any responses
>>to this when i sent it a couple of days ago.  i'm thinking maybe
>>it never really made it to the list (?), or am i just coming from
>>another planet here? thanks for your help & time.
>
>Your first message made it to the list, but probably no one was able
>to figure out an answer.  You are more likely to get a response if you
>include all of the details, as you have in your second message.
>
>>incidentally, the machine in question was up for about a month without
>>incident, albeit under relatively light load (email, dns, light web,
>>user-ftp).  but when generating these core dumps, i actually got a panic!
>>i was very surprised.  here's the trace:
>
>Nothing ranlib can do should mangle your filesystems.  It's more
>likely that something else is the original source of the problem, and
>it was the pre-existing filesystem damage that caused ranlib to dump
core in the first place:
>
>>Feb 18 03:27:55 xxxxxxxx /netbsd: /usr: bad dir ino 42276 at offset 0: mangle
>d entry
>>Feb 18 03:27:55 xxxxxxxx /netbsd: panic: bad dir
>
>>Feb 18 03:28:04 xxxxxxxx /netbsd: /dev/sd0a: file system not clean; please fs
>ck(8)
>
>>so... what's the moral here?  is my kernel screwed up?  my disk?  also,
>>with respect to ranlib core dumps (assuming they're unrelated to this
>>panic...)  should i grab the ar and ranlib from -current?  is there a
>>known-bug in the 1.2 distribution here?
>
>The root filesystem on your sd0 disk is hosed, and needs to be fsck'ed.
>Is there any particular reason why /etc/rc does not fsck your disks
>automatically?  If /fastboot exists, nuke it.
>
>Regardless, you should shutdown to single user *now* and run:
>
># sync
># fsck /dev/rsd0a
># reboot
>
>>btw -- i should probably just read up on this, but do y'all have a way
>>to track bugfixed sources like freebsd-stable, or only the -current stuff?
>
>We don't have a -stable branch like FreeBSD's.  Hopefully, a jumbo
>patch will be released soon which will fix some of the more glaring
>misfeatures in 1.2.
>-- 
>Mike Long <mike.long@analog.com>     <URL:http://www.shore.net/~mikel>
>VLSI Design Engineer         finger mikel@shore.net for PGP public key
>Analog Devices, CPD Division          CCBF225E7D3F7ECB2C8F7ABB15D9BE7B
>Norwood, MA 02062 USA       (eq (opinion 'ADI) (opinion 'mike)) -> nil


........................................................................

Stephen Farrell 
voice: 773.834.0485 
<URL:http://www.people.healthquiz.com/sfarrell/>