Red Hat Bugzilla – Bug 119712
bad advice when mounting ext2/ext3 root filesystem fails
Last modified: 2014-03-16 22:43:47 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040312 Description of problem: When mounting the root filesystem fails, and /etc/fstab claims that it should be ext2 or ext3, then the console gives bad advice when it suggests "e2fsck -b 8193 <device>". This is only for non-sparse_super filesystems. Most ext2/ext3 filesystems are now sparse_super (this has been the default for a couple years), so the advice should be updated (and the corresponding block number is 32768 or 98304). Version-Release number of selected component (if applicable): initscripts-7.48-1 How reproducible: Always Steps to Reproduce: 1. Change /etc/fstab so that the mount point for the root filesystem does not exist, but the partition does contain an ext2 or ext3 filesystem with sparse_super. For example, for the root filesystem: ----- LABEL=/ /does_not_exist ext3 defaults 1 1 ----- 2. Reboot. 3. Actual Results: ----- Checking root filesystem fsck.ext2: /: The superIs a directory while trying to open / block could not be read or does not describe a correct ... e2fsck -b 8193 <device> ----- where the intermixing of stdout and stderr does occur, and one instance is quoted above. Expected Results: List the block number for sparse_super, too: e2fsck -b 8193 <device> # non-sparse_super [older or smaller] e2fsck -b 32768 <device> # sparse_super [typically newer] Additional info:
Ok, the first problem is the message. I have send the author of e2fsprogs an email about this. It will be fixed in the next version, I think. The second problem is that e2fsck is called with the -a flag. It should be considered to run fsck without -a, then fsck.ext2 and fsck.ext3 is repairing the filesystem automatically with trying backup blocks. Reassigning to initscripts.
Running without -a? I don't think we really want to start prompting.
Closing bugs on older, no longer supported, releases. Apologies for any lack of response. Please try to reproduce this on a current release, such as Fedora Core 4. If the issue persists, please open a new issue. I believe the original problem (the error message) has since been solved.