Bug 126953 - Upgrading from RH9 to FC2 on with SATA root renders system unbootable: initrd doesn't include ata_piix
Summary: Upgrading from RH9 to FC2 on with SATA root renders system unbootable: initrd...
Keywords:
Status: CLOSED DUPLICATE of bug 121848
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 2
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-06-29 18:36 UTC by C.Laurence Gonsalves
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-02-21 19:04:17 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description C.Laurence Gonsalves 2004-06-29 18:36:57 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Gecko/20040324 Galeon/1.3.14

Description of problem:
After upgrading from RedHat 9 to Fedora Core 2, my system won't boot.
It panics with the message:

  Kernel panic: VFS: Unable to mount root fs on unknown-block(0,0)


How reproducible:
Always


Steps to Reproduce:
1. Upgrade to Fedora Core 2
2. Attempt to boot upgraded system

    

Actual Results:  Kernel panics. Here are the last 5 lines of output
transcribed from my screen:

  Loading ext3.ko module
  Creating block devices
  VFS: Cannot open root device "LABEL=/" or unknown-block(0,0)
  Please append a correct "root=" boot option
  Kernel panic: VFS: Unable to mount root fs on unknown-block(0,0)


Expected Results:  Successful boot.


Additional info:

This install was tricky. I have an ASUS P4P800 motherboard so I had to
use the ISO from comment #122 of bug #121819 to actually get the
installer running. The install went pretty smoothly after that modulo
two small oddities:

First, I noticed that the installer thought that my HDD was
"/dev/sda". RH9 called it "/dev/hdb", so I was a bit confused. I did
some searches on Google, and found a bunch of pages which indicate
that the 2.6 kernal often considers SATA drives to be SCSI. This is
apparently okay though.

The other oddity was that it couldn't find a boot loader installed. I
told it to install GRUB. This seemed odd to me because I already had
GRUB installed from my RH9 install.

After the install, I can't boot because of the above-mentioned panic.
Google turned up a number of people with similar problems (with
various Linux distros) and possible solutions. These all involved
tweaking the "root=" kernel parameter, or adding a "vdso=0" kernel
parameter. I added the "vdso=0" param, and then I tried changing the
root param to each of the following values (some are a bit off the
wall, but I'm grasping at straws here...):

  LABEL=/     (this is what worked in RH9, and also what the FC2
               installer put)
  /dev/hda3
  /dev/hdb3
  /dev/sda3
  /dev/sdb3
  303
  343
  803
  813

All of them gave essentially the same panic message, modulo the (0,0)
and "LABEL=/".

My root volume is the third partition on the hard drive hooked up to
the first SATA connector. (there are two SATA connectors, and two
parallel connectors on my motherboard) This is the only HDD in the
machine. It has three partitions: /boot, swap, and / (root).

When I use the FC2 "rescue" boot I'm able to mount the root and boot
from my SATA drive without any problems. 'df' reports that the root is
/dev/sda3.

Comment 1 C.Laurence Gonsalves 2004-06-30 18:50:19 UTC
It looks like the problem was due to the initrd being incomplete. In
particular, I think it was missing the ata_piix module. To fix this, I
ran the following:

  mkinitrd --preload=scsi_mod --preload=sd_mod --with=ata_piix \
             /boot/initrd.img-2.6.5-sata 2.6.5-1.358

and then I modified my grub parameters in two ways:

  - I changed the initrd line to refer to the output of the above
    command

  - I changed the root= option to use /dev/sda3

My system is now able to boot again. So there appears to be a problem
in the way the FC2 installer constructs the initrd that it installs on
some systems.

Comment 2 Jeremy Katz 2004-10-07 18:54:07 UTC

*** This bug has been marked as a duplicate of 121848 ***

Comment 3 Red Hat Bugzilla 2006-02-21 19:04:17 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.


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