Newsgroups: comp.os.minix
Path: utzoo!utgpu!cunews!bnrgate!bmerh408!bmerh451!dgraham
From: dgraham@bmerh451.bnr.ca (Douglas Graham)
Subject: Re: /etc/update is hanging
Message-ID: <1991Mar17.191136.2097@bmerh408.bnr.ca>
Sender: news@bmerh408.bnr.ca (Usenet News Admin)
Organization: Bell Northern Research, Ottawa, Canada
References: <1991Mar12.225454.19910@viewlogic.com> <1991Mar15.170118.3983@dsuvax.uucp>
Date: Sun, 17 Mar 91 19:11:36 GMT

In article <1991Mar15.170118.3983@dsuvax.uucp> ghelmer@dsuvax.uucp (Guy Helmer) writes:
>In <1991Mar12.225454.19910@viewlogic.com> greg@suntan.viewlogic.com (Gregory Larkin) writes:
>
>>Also, when I run fsck after badblocks, I get weird messages
>>about duplicate zones and missing bitmaps?  Is this normal?
>
>fsck -r /dev/hd? has always fixed badblock's mistakes for me.

I haven't seen this new badblocks that everybody is talking about,
but the scariest thing about the one included with 1.5.10 is that
not only does it make a mess of the filesystem on which it is mapping
out the bad blocks, it also screws up the root filesystem as well.
The latter problem occurs because badblocks creates a directory on the
root filesystem as a mount point, and then removes the directory
using unlink() instead of rmdir().  There is code in FS which explicitly
allows root to unlink() a directory, but it doesn't do the complete
job.  I don't know if this is desired behaviour on the part of FS,
but it is certainly a bug in badblocks.

Anyway, like the man says, do an "fsck -r" on both the root filesystem
and the new filesystem immediately after running badblocks, and everything
should be hunky dory.
---
Doug Graham dgraham@bnr.ca	Bell-Northern Research, Ottawa Ontario Canada