Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 161406 - Installer created deficient initial root disk image
Summary: Installer created deficient initial root disk image
Alias: None
Product: Fedora
Classification: Fedora
Component: mkinitrd
Version: 4
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Peter Jones
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2005-06-23 00:26 UTC by Joseph Teichman
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-01-22 20:36:34 UTC

Attachments (Terms of Use)
/etc/modprobe.conf - of the normal filesystem (deleted)
2005-07-08 13:46 UTC, Joseph Teichman
no flags Details
/tmp/modprobe.conf - of the install/resuce system (deleted)
2005-07-08 13:52 UTC, Joseph Teichman
no flags Details

Description Joseph Teichman 2005-06-23 00:26:12 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4

Description of problem:
After upgrading from Fedora Core 3 to Fedora Core 4 on an AMD64 machine, I could not boot into the system. The root partition was not recognized, and switchroot failed and I got a kernel panic. I found that I was able to boot and run this kernel both during install, and later using the rescue disk. I reasoned that the problem must be in the initial root disk image (initrd-2.6.11-1.1369_FC4.img). I booted into the system using the rescue disk, unpacked the initial root disk image. I saw right away that the image was missing the 'sata_via' module that is necessary for the kernel to see the hard disk on my computer. The initial ramdisk image only had on the image modules ext3 and jdb.
To make my system bootable, I 'chroot'ed into my file system 'chroot /mnt/sysimage' . I then ran '/sbin/mkinitrd /boot/initrd-2.6.11-1.1369_FC4-2.img 2.6.11-1.1369_FC4' to make a new root image. I checked the image and found all the necessary modules on it. Then I modified /boot/grub/grub.conf to use the new ramdisk image, and it booted perfectly. 
It seems to me that the problem is with the installer, for some reason it created deficient initial root disk images. This would only present a problem for people who are not using a regular ide drive and a file system other than ext2 or ext3.

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

How reproducible:

Steps to Reproduce:
1. Install FC-3 on a system that requires the sata_via module. (VIA mother board with an SATA hd)
2. Complete Upgrate to FC-4
3. Boot

Actual Results:  On booting the root partition was not recognized and I got a kernel panic. I examined the initrd.img, and found that it was missing required modules.

Expected Results:  The initd.img file should have contained the modules that would have allowed the system to boot.

Additional info:

I think that this problem might explain some other but reports that I have seen out there. This is severe since it leaves a system unable to boot. It might explain bug # 161169, bug # 160444 (and maybe #161255). Also, there are reports of problems in this forum which may be explained by this bug

Comment 1 Peter Jones 2005-07-06 22:36:37 UTC
Please attach your /etc/modprobe.conf ?

Comment 2 Matt Davey 2005-07-08 08:30:38 UTC
I had similar problem to that described in several fora:
mount: error 6 mounting ext3.

I have an acer laptop, and found I had to add the following modules to the
initrd that comes with fc4, in order to recognise my root partition:

ata_piix, libata, sr_mod, sd_mod, scsi_mod

Matt Davey

Comment 3 Joseph Teichman 2005-07-08 13:44:39 UTC
I have included my regular /etc/modprobe.conf. I have to question its relevance
to this problem though, as we are talking about mkinitrd running in the install
system setup and not the regular running filesystem (does in use chroot to run
under the filesystem?). I am attaching my mkinitrd just for reference as to what
my system needs, but I don't know if it is what my system sees during install
time when running from the installation disk. I found that when the install disk
goes into rescue mode, there is no /etc/modprobe.conf file on the filesystem
(the original modprobe.conf will be available at /mnt/sysimage/etc). You will
find a shortened version of modprobe.conf  on /tmp/modprobe.conf. I am attaching
that too for your reference. But I checked, and they both contain the necessary
modules. It could be that for some reason the modprobe.conf file was not
available or was messed up only during the system upgrade. I only had a chance
to look at the installation's modprobe.conf file now, by putting it in rescue
mode with the installation disk. 

I do not know how mkinitrd is being called within the root system. I suspect
that the way that mkinitrd is called within the install system is not the same
as it normally would be called. This is in part because the modprobe.conf is not
in its normal place, and the modules are also not in their normal place. I could
be wrong about this if they 'chroot' into the filesystem first. Since the
problem that I had with mkinitrd only came up while the installer was running,
and not at other times, I thought that the problem that I experienced was a
result of mkinitrd being called improperly or some of the files such as
modprobe.conf being set up improperly by the install system. That is why I
originally assigned this problem to the anaconda people. They reassigned it to

Comment 4 Joseph Teichman 2005-07-08 13:46:14 UTC
Created attachment 116515 [details]
/etc/modprobe.conf - of the normal filesystem

Comment 5 Joseph Teichman 2005-07-08 13:52:32 UTC
Created attachment 116516 [details]
/tmp/modprobe.conf - of the install/resuce system

You might notice that this modprobe.conf also contains modules for sata_promise
as oppose to the filesystem's modprobe.conf. Please be assured that it is not
what is making a difference for two reasons:
1- it is anyway the one that would be available to the install system.
2- I don't use the sata_promise module, it is for the raid controller and I
don't have any raid disks on my system.

Comment 6 Jon Anhold 2006-09-14 05:19:23 UTC
mkinitrd won't autodetect LVM if you have LABEL=/ in your fstab. Change it to
/dev/vg0/root (or whatever is appropriate) and re-mkinitrd, and you're golden.

Not sure if that is what's up here, but that just solved some of my headaches.

Comment 7 Joseph Teichman 2006-09-15 04:31:35 UTC
Thanks for the comments. This goes back a year ago. I hope that it isn't still
an issue on the newer versions of Fedora. In any case, I was not using LVM.

Comment 8 Christian Iseli 2007-01-20 00:38:20 UTC
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?


Comment 9 Joseph Teichman 2007-01-22 20:36:34 UTC
I have not experienced this problem with FC5 and FC6, so pursuant to Christian
Iseli's request, I am marking this bug "WONTFIX".

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