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
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
There's a race condition where fsck starts one fsck.ext2 to
after another fsck finshes, and fsck sends a SIGUSR1 to the
as a signal to tell it that it can start displaying its
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
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
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
------------- 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.
I have exactly this problem on my system, with the wrinke that this
only happens for my largest partition (4.9 gigs or so) and only if I
am bringing the system up single-user. Needless to say, this is quite
a disconcerting bug and I hope that a fix is issued promptly.
Actually, the -C says not to show progress bars. They still do run in
parallel,so removing the -C isn't that bad.
Fixed in the latest e2fsprogs.