Bug 91094 - e2fsck fails causing boot to fail, among other issues
e2fsck fails causing boot to fail, among other issues
Product: Red Hat Linux
Classification: Retired
Component: installer (Show other bugs)
i586 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2003-05-17 18:04 EDT by Bill Catlan
Modified: 2007-04-18 12:53 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-06-13 17:21:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bill Catlan 2003-05-17 18:04:48 EDT
From Bugzilla Helper:

Description of problem:
Well, I experienced three problems during my "upgrade" from RedHat Linux 7.1 to
RedHat Linux 9.  I should note that I indicated that I wanted to upgrade the
filesystem from ext2 to ext3.

First, a simple packaging error in a kde language module.  A reboot to deselect
that package allowed the install to complete.

Second, lilo did not get run to execute the changes made to lilo.conf.  Plus, my
original kernel image was erased, so the second entry in lilo pointing to that
image was invalid.  I manually commented out the old lilo settings, ran lilo,
and could finally boot properly from the MBR on /dev/hda.

Lastly, e2fsck fails, complaining that /dev/hda1 is mounted and the file system
could not be checked.  I entered maintenance mode and tried to force a check
using the -f option.  (I previously tried just putting the empty file
'forcefsck' in the root path to trigger it, and it failed to do so.)  This was
not sufficient and e2fsck continues to fail to this moment during the boot
sequence, causing the boot to fail, unless i override the result code.  I was
able to run e2fsck in maintenance mode after forcing it to do so even though
doing so may cause "SEVERE damage to the filesystem."  Even though /dev/hda1 was
mounted rw when I enter maintenance mode (This I think is the problem - my
/etc/lilo.conf file says "read-only", don't know what gives.), I figured I was
in single user mode and should be ok.  I hoped that doing so would eliminate the
attempt to do a fsck next boot, but it did not eliminate the attempt.  The
second time I did an e2fsck in maintenance mode, it resulted in certain inodes
being cleaned and /etc/rc.d/rc.sysinit being deleted.  When this happened, the
fsck was not attempted next boot, and my system booted next time, with some
complaints.  I then manually installed the initscripts package to get my
rc.sysinit file back, and modified /etc/rc.d/rc.sysinit to override the fsck
results code in order to allow me to boot.

Well, I'd like to get the e2fsck working properly, even though I have soe notion
that its not required on an ext3 filesystem.  Not in familiar territory on that,
so some clue would be much appreciated.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. upgrade (not reinstall) from 7.1 to 9.0

Additional info:
Comment 1 Jerry Hicks 2003-06-05 01:14:20 EDT
I encountered the same e2fsck boot-time hangup (RH9) by setting /etc/fstab 

LABEL=/           /            ext3    defaults,sync   1 1

(duh, that probably doesn't make much sense for ext3?)
Comment 2 Jerry Hicks 2003-06-05 01:17:27 EDT
Additionally, this happens when booting kernel-2.4.20-18.9 but does not happen 
when booting 2.4.20-8 (same fstab entries)
Comment 3 Jerry Hicks 2003-06-05 13:19:02 EDT
(this is with the probably-wrong 'default,sync' fstab entry on ext3 2.4.20-18.9)

'shutdown -f ...' allows a clean restart (fsck skips the already mounted filesystem) and all is well.

Just 'shutdown ...' 100% failure for this case here.  fsck - already mounted filesystem

I imagine quite a few folks may hit this issue upgrading though.  It's pretty easy to trash an 
installation if one isn't thinking too clearly (like me :-)
Comment 4 Jeremy Katz 2003-06-13 17:21:02 EDT
Added some code to handle some of this better in cvs

Note You need to log in before you can comment on or make changes to this bug.