Bug 112858 - fedora core kernels cannot boot from S-ATA disk on ICH5 controller
Summary: fedora core kernels cannot boot from S-ATA disk on ICH5 controller
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 2
Hardware: All Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-01-04 11:48 UTC by Alex Hornby
Modified: 2015-01-04 22:04 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-11 22:46:38 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Alex Hornby 2004-01-04 11:48:10 UTC
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):

How reproducible:
Every boot

Steps to Reproduce:
1. Select a fedora kernel from grub
2. Kernel starts but cannot find root filesystem
Actual results:
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

Expected results:
System boots in both compatible and enhanced IDE modes.

Additional info:
Using grub as my boot loader.

Comment 1 Kaj J. Niemi 2004-01-04 22:49:30 UTC
Looks similar to bug #110543.

Comment 2 Alex Hornby 2004-07-18 11:28:22 UTC
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

Comment 3 Kaj J. Niemi 2004-07-18 12:01:35 UTC
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
/boot/initrd.img-2.6.7-1.492 2.6.7-1.492

Comment 4 Alex Hornby 2004-07-24 10:15:44 UTC
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 :)

Comment 5 Manfredo Hopp 2004-08-06 00:10:37 UTC
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
redirect input....

Comment 6 Manfredo Hopp 2004-08-12 16:54:20 UTC
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...

Comment 7 Arjan van de Ven 2004-08-12 16:56:00 UTC
> Another good reason: no source is available...


Comment 8 Kaj J. Niemi 2004-08-12 17:11:55 UTC
mkinitrd itself is shell script.. you have the source, Manfredo.  Hmmm
I think I stumbled on the problem (and fix) in bug #129745. :)

Comment 9 Manfredo Hopp 2004-08-15 15:15:14 UTC
Its easier to say stupid things, than to accept you said them...

Comment 10 Dave Jones 2005-01-11 04:52:15 UTC
is this fixed in the current releases ?

Comment 11 Alex Hornby 2005-01-11 22:04:01 UTC
Yes, its fixed in FC3.

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