Red Hat Bugzilla – Bug 116573
Kernel failes to mount LVM ext2 error
Last modified: 2014-03-16 22:42:32 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Description of problem:
I have just run up2date to get my system fully updated against the
default Fedora 2 mirrors (un modified up2date source files).
On reboot, I am greeted with a message saying.
Checking root filesystem
fsck.ext3: Invalid argument/dev/Volume00/LogVol01:
The superblock could not be read (blah blah blah), try running e2fsck
with an alternate superblock.
while trying to open /dev/Volume00/LogVol01 [FAILED]
*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.
The kernel version I am using is Fedora Core (2.6.3-1.97).
If I restart the system and choose the prior kernel version of Fedora
Core (2.6.3-1.91) every thing appears to start smoothly.
I have my root partition in/on an LVM volume.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot system with kernel version 2.6.3-1.97
Actual Results: Failed fsck.ext3 check, could not read superblock or
incorrect ext2 file system
Expected Results: To boot with out errors.
I have just attempted to use the kernel 2.6.3-1.100, I am receiving
the same error still.
I installed a fresh system (x86_64) from devel tree, using -91 kernel,
and when upgrading to 2.6.3-1.96 or -97 I get this exact same error.
Also see bug 116410, sort of related.
Upgraded to kernel releases 1.100, 1.106, 1.109 and 1.110 - does not
solve it. Reinstalled box yesterday based on develtree from 25/2
(2.6.3-1.106). Now everything works fine, and upgrades to 109 and 110
So guess there was a problem with the -91 and/or -96/-97 kernel releases?
This is nothing to do with the kernel, it's entirely a property of the
LVM2 interaction with initscripts.
LVM2 uses dynamic device major/minor numbers. You need to create
those device inodes before you can access an LVM device. To fsck
root, you need to create the inodes for the root fs. And you can't do
that on the root fs, because at that point it's readonly.
Bill's suggestion was to use the copy of the device inodes on the
initrd image for root fsck instead. The attached patch does that for
me. Please test!
Doing a re-upgrade probably just meant that the installer created
device nodes which happened to be correct on the next boot. That will
work a lot of the time, but when the device nodes change (as they can
after any kernel upgrade or initrd change), you'll be back to the same
Created attachment 98369 [details]
Use /initrd/dev/* inode for root fs fsck if possible.
*** This bug has been marked as a duplicate of 117575 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.