Bug 116573

Summary: Kernel failes to mount LVM ext2 error
Product: [Fedora] Fedora Reporter: Douglas Furlong <bugzilla_rhn>
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED DUPLICATE QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: rawhideCC: gbpeck, katzj, rvokal, sct
Target Milestone: ---   
Target Release: ---   
Hardware: athlon   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-21 19:01:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 114961    
Attachments:
Description Flags
Use /initrd/dev/* inode for root fs fsck if possible. none

Description Douglas Furlong 2004-02-23 12:35:35 UTC
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 09:35:58 UTC
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 20:10:17 UTC
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 14:48:10 UTC
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 14:49:31 UTC
Created attachment 98369 [details]
Use /initrd/dev/* inode for root fs fsck if possible.

Comment 5 Stephen Tweedie 2004-03-08 14:52:39 UTC

*** This bug has been marked as a duplicate of 117575 ***

Comment 6 Red Hat Bugzilla 2006-02-21 19:01:32 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.