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: Always 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 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: http://forums.fedoraforum.org/showthread.php?t=59320 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
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 mkinitrd.
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 ? Thanks.
I have not experienced this problem with FC5 and FC6, so pursuant to Christian Iseli's request, I am marking this bug "WONTFIX".