Bug 116573 - Kernel failes to mount LVM ext2 error
Kernel failes to mount LVM ext2 error
Status: CLOSED DUPLICATE of bug 117575
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
rawhide
athlon Linux
medium Severity high
: ---
: ---
Assigned To: Bill Nottingham
:
Depends On:
Blocks: FC2Blocker
  Show dependency treegraph
 
Reported: 2004-02-23 07:35 EST by Douglas Furlong
Modified: 2014-03-16 22:42 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 14:01:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Use /initrd/dev/* inode for root fs fsck if possible. (1.72 KB, patch)
2004-03-08 09:49 EST, Stephen Tweedie
no flags Details | Diff

  None (edit)
Description Douglas Furlong 2004-02-23 07:35:35 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Gecko/20040207 Firefox/0.8

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):
kernel-2.6.3-1.97

How reproducible:
Always

Steps to Reproduce:
1. Boot system with kernel version 2.6.3-1.97
2.
3.
    

Actual Results:  Failed fsck.ext3 check, could not read superblock or
incorrect ext2 file system

Expected Results:  To boot with out errors.

Additional info:

LVM version
lvm-1.0.3-18
lvm2-2.00.08-3
Comment 1 Douglas Furlong 2004-02-25 04:35:58 EST
I have just attempted to use the kernel 2.6.3-1.100, I am receiving
the same error still.
Comment 2 Per-Stian Vatne 2004-02-27 15:10:17 EST
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
is ok.

So guess there was a problem with the -91 and/or -96/-97 kernel releases?
Comment 3 Stephen Tweedie 2004-03-08 09:48:10 EST
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
problem.
Comment 4 Stephen Tweedie 2004-03-08 09:49:31 EST
Created attachment 98369 [details]
Use /initrd/dev/* inode for root fs fsck if possible.
Comment 5 Stephen Tweedie 2004-03-08 09:52:39 EST

*** This bug has been marked as a duplicate of 117575 ***
Comment 6 Red Hat Bugzilla 2006-02-21 14:01:32 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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