Bug 126953 - Upgrading from RH9 to FC2 on with SATA root renders system unbootable: initrd doesn't include ata_piix
Upgrading from RH9 to FC2 on with SATA root renders system unbootable: initrd...
Status: CLOSED DUPLICATE of bug 121848
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
2
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Jeremy Katz
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-29 14:36 EDT by C.Laurence Gonsalves
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 14:04:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description C.Laurence Gonsalves 2004-06-29 14:36:57 EDT
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 14:50:19 EDT
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 14:54:07 EDT

*** This bug has been marked as a duplicate of 121848 ***
Comment 3 Red Hat Bugzilla 2006-02-21 14:04:17 EST
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.