Red Hat Bugzilla – Bug 161406
Installer created deficient initial root disk image
Last modified: 2007-11-30 17:11:08 EST
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):
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
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.
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 http://forums.fedoraforum.org/showthread.php?t=59320&page=1&pp=15 which may be explained by this bug
Please attach your /etc/modprobe.conf ?
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
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
Created attachment 116515 [details]
/etc/modprobe.conf - of the normal filesystem
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.
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.
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.
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 ?
I have not experienced this problem with FC5 and FC6, so pursuant to Christian
Iseli's request, I am marking this bug "WONTFIX".