There's a problem in e2fsprogs 1.15.  Occasionally
while doing a parallel file system check during init,
fsck.ext2 will return a signal 10 error, and then require a
reboot.  All the filesystems actually check out alright, and
on reboot sometimes this will happen again, sometimes it
won't.
The following is an e-mail from Ted Tso (e2fsprogs
maintainer/author) explaining the problem.  He also sent
me an e-mail today stating that it'll be fixed in a new
version to be released ASAP.

----------------------- start pasted e-mail ---------------

OK, if you're using e2fsck 1.15, I think I know what's going
on.
There's a race condition where fsck starts one fsck.ext2 to
start just
after another fsck finshes, and fsck sends a SIGUSR1 to the
first fsck
as a signal to tell it that it can start displaying its
progress bar.
If this happens before the first fsck has had a chance to
set up the
signal handler, then it will exit when it receives the
SIGUSR1.  It's
a pretty narrow window, which must be why I haven't seen
it.  I'll put
in some safeguards to prevent it from happening, though.

If you aren't using the 1.15 e2fsck, and you're not seeing
progress bars
when fsck needs to check a filesystem, then it's something
else.  Let me
know, and I'll see if I can find another explanation for
what's going
on.
-------------      end pasted e-mail. -------------------

------- Additional Comments From   10/19/99 11:04 -------
This came up on cartman-list over the weekend.  The suggested work
around from Bill Nottingham for the time being was to remove the -C
from the invocation of fsck in /etc/rc.d/rc.sysinit so that they do
not run in parallel.