Red Hat Bugzilla – Bug 112858
fedora core kernels cannot boot from S-ATA disk on ICH5 controller
Last modified: 2015-01-04 17:04:16 EST
Description of problem:
A regression from redhat 9...
The fedora core 1 kernels (currently vmlinux-2.4.22-1.2135.nptlsmp )
cannot boot from my S-ATA (seagate 120Gb) drive connected to my Asus
P4P800 motherboard (intel ich5 s-ata controller). This fails with
"kernel panic cannot mount root fs 00:00" and "cannot find device
root="LABEL=/"" when the kernel goes to mount the root file system. I
have tried configuring the bios into both "compatible" and "enhanced"
modes, but get the same error in each.
The wierd thing is - the Redhat 9 kernel has no problwm with this
system when the bios ide settings are set to "compatible".
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Select a fedora kernel from grub
2. Kernel starts but cannot find root filesystem
No booting unless one installs an old redhat 9 kernel (in my case
vmlinuz-2.4.20-20.9smp ) and selects it from the grub menu
System boots in both compatible and enhanced IDE modes.
Using grub as my boot loader.
Looks similar to bug #110543.
Same problem with fedora core 2 kernels. The initrd mechanisms for
loading scsi disk ( necessary for libata ) and libata are not working.
I had to build a custom kernel with SCSI, SCSI disk and libata in
kernel ( _not_ as modules ) to get it to boot.
I've tried the latest FC2 fedora kernel updates - they still have this
How about attempting to build the mkinitrd image manually? I noticed
that sometimes not all the sata modules get included in the initrd image.
Try using the regular, modular kernel and create the initrd image with:
mkinitrd --preload=scsi_mod --preload=sd_mod --with=ata_piix
Excellent - thanks Kaj. Rebuilding the initrd meant that I could use
the stock fedora core 2 kernels.
Hopefully fedora core 3 will include the ata_piix modules by default
in initrd. Its fairly common hardware :)
Kay: Do you have any idea on how to run that command in rescue mode?
mkinitrd wants /lib/modules/version-nbr as input, whereas I built
modules in a different library!!!!! I do not see if mkinitrd can
Alex: In the mean time I suggest not to use mkinitrd at all (it makes
no difference to think about including a module in the kernel, as to
do it with mkinitrd). Another good reason: no source is available...
> Another good reason: no source is available...
mkinitrd itself is shell script.. you have the source, Manfredo. Hmmm
I think I stumbled on the problem (and fix) in bug #129745. :)
Its easier to say stupid things, than to accept you said them...
is this fixed in the current releases ?
Yes, its fixed in FC3.