Bug 192626

Summary:	init does not load ext3 module if /etc/fstab has "ext3,ext2" as file system type
Product:	[Fedora] Fedora	Reporter:	David Bowen <david>
Component:	mkinitrd	Assignee:	Peter Jones <pjones>
Status:	CLOSED WONTFIX	QA Contact:	David Lawrence <dkl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5	CC:	davej, triage, wtogami
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:	bzcl34nup
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-05-06 15:55:59 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:

Description David Bowen 2006-05-21 23:02:26 UTC

Description of problem:
When installing a new kernel rpm it appears that the new initrd-*.img contains
an "init" script that is customized based at least partly on the contents of
/etc/fstab. Specifically, I had:
/dev/VolGroupZeroZero/LogVolZeroZero / ext3,ext2 defaults 1 1
LABEL=/boot /boot ext3,ext2 defaults 1 2

This seems to have caused the consequent "init" to no longer include the lines:
echo "Loading jbd.ko module"
insmod /lib/jbd.ko 
echo "Loading ext3.ko module"
insmod /lib/ext3.ko 

A kernel panic ensues as /dev/root can't be mounted.

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

How reproducible:
Occurred on two separate machines which I had customized in this way. Only tried
on kernel 2.6.16-1.2111_FC5.

Steps to Reproduce:
1. Have some drives setup to use ext3.
2. Update /etc/fstab to have ext3,ext2 as the file system type. I don't know if
it's specific to "/" or "/boot".
3. Install a new kernel using "yum update kernel" (assuming one is available)
4. Reboot
5. You will see the lvm messages go by then a problem occurs mounting /sysroot:
"mount: error mounting /dev/root on /sysroot as ext3,ext2: No such device".
Things go downhill from there and about 5 lines later end up with a "Kernel panic".
  
Actual results:
Machine fails to boot. Has to be manually reset (ctrl-alt-del does not work).

Expected results:
ext3 partition should be mounted as ext3 if possible, else ext2.

Additional info:
I got into this mess as my ext3 partition need fsck'ing. I have had success
going back to ext2 whilst sorting things out in the past and considered it a
good idea to make all my partitions drop back to ext2 automatically if ext3
failed. Hence I changed the fs_vfstype in /etc/fstab say "ext3,ext2". All went
OK until a new kernel arrived and it failed to boot. Going back to an old kernel
allowed it to boot.

Notably, uninstalling the new kernel using yum, updating /etc/fstab to simply
have "ext3" and then re-installing the kernel sorted me out.

Comment 1 Dave Jones 2006-10-16 21:46:52 UTC

A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.

Comment 2 David Bowen 2006-10-16 22:54:45 UTC

To do this experiment I have changed my fstab to include the "ext2" part:

# grep ext /etc/fstab
/dev/md0                /                       ext3,ext2    defaults        1 1
LABEL=/boot             /boot                   ext3,ext2    defaults        1 2

I then installed the 2.6.18-1.2200.fc5 kernel using yum:

# yum update *kernel*

I extracted the contents of the initrd into a clean folder:

# gzip -dc '/boot/initrd-2.6.18-1.2200.fc5.img' | cpio -id
5078 blocks

and then queried the contents of the new initrd:

# grep ext init
mkrootdev -t ext3,ext2 -o defaults,ro /dev/md0

Contrast this with the same exercise with an fstab that does not have the "ext2"
part:

# yum remove *kernel*2.6.18-1.2200*

# grep ext /etc/fstab
/dev/md0                /                       ext3    defaults        1 1
LABEL=/boot             /boot                   ext3    defaults        1 2

# yum update *kernel*

# gzip -dc '/boot/initrd-2.6.18-1.2200.fc5.img' | cpio -id
5850 blocks

# grep ext init
echo "Loading ext3.ko module"
insmod /lib/ext3.ko
mkrootdev -t ext3 -o defaults,ro /dev/md0

So it would appear that the problem persists because the "insmod /lib/ext3.ko"
line is missing from initrd-2.6.18-1.2200.fc5.img.

Comment 3 Dave Jones 2006-10-16 23:38:16 UTC

I'm not certain that this was ever intended to work this way, but it sounds like
an initrd feature rather than a kernel bug.

Comment 4 Bug Zapper 2008-04-04 02:56:41 UTC

Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers

Comment 5 Bug Zapper 2008-05-06 15:55:57 UTC

This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.