Bug 206679 - Unable to do initial boot after install (no initrd).
Unable to do initial boot after install (no initrd).
Status: CLOSED DUPLICATE of bug 206453
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
6
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-15 12:53 EDT by Tom Horsley
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-18 09:48:41 EDT
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 Tom Horsley 2006-09-15 12:53:13 EDT
Description of problem:

I got around my previous install bug by telling it to use DHCP, but
now having completed the initial installation, and trying to boot
for the first time to fill in all the initial settings, it can't
seem to boot. On the console I see:

VFS: Cannot open root device "sda7" or unknown-block (0,0)

Version-Release number of selected component (if applicable):


How reproducible:

ONly tried once so far - perhaps if I try again it will work better.

Steps to Reproduce:
1. Install FC6t3 from DVD
2. Click the reboot button following the installation.
3.
  
Actual results:

Error above about root partition not being there

Expected results:

Bott into linux and start testing things.

Additional info:

The partitons seem to actually be there OK. An fdisk -l when booted
into FC5 on the same machine after installing FC6t3 shows perfectly
wonderful ext3 partitions with lots of stuff in them:

Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          13      104391   83  Linux
/dev/sda2              14          26      104422+  83  Linux
/dev/sda3              27          39      104422+  83  Linux
/dev/sda4              40       19457   155975085    5  Extended
/dev/sda5              40        6541    52227283+  83  Linux
/dev/sda6            6542       13043    52227283+  83  Linux
/dev/sda7           13044       19457    51520423+  83  Linux

Disk /dev/sdb: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1        1020     8193118+  82  Linux swap / Solaris
/dev/sdb2            1021       19457   148095202+  83  Linux

The grub.conf file it generated looks like:

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,2)
#          kernel /vmlinuz-version ro root=/dev/sda7
#          initrd /initrd-version.img
#boot=/dev/sda3
default=0
timeout=5
splashimage=(hd0,2)/grub/splash.xpm.gz
hiddenmenu
title Fedora Core (2.6.17-1.2630.fc6)
	root (hd0,2)
	kernel /vmlinuz-2.6.17-1.2630.fc6 ro root=/dev/sda7 rhgb quiet

and the device.map file looks like:

# this device map was generated by anaconda
(hd0)     /dev/sda

All that seems to be consistent with what I'd expect, though it is
strange to see if use the /dev/sda7 syntax instead of the LABEL=/
syntax it normally seems to use.

This board uses the nforce sata for the disks, but they have been working
fine in previous FC6 versions.
Comment 1 Tom Horsley 2006-09-15 13:06:15 EDT
I've tried booting a couple of more times, still get same error.
Also tried switch to the LABEL= syntax, also same error (modulo the
different device it says it can't find).

I'm changing priority to high, since I seem to be totally blocked
by this (and FC6t2 was working so well on this machine in the same
partitions :-).
Comment 2 Tom Horsley 2006-09-15 13:17:11 EDT
I was going to look at the initrd file in the /boot partition to see if the
init script was doing anything funny, but there is no initrd image. Does
this mean the problem is missing drivers for the sata disks? Should
there be an initrd image? Any anaconda log files I should attach to this?
Comment 3 Tom Horsley 2006-09-15 17:44:23 EDT
That seems to be it. I noticed that the same kernel was installed by
FC6t3 as I was running from the last update of t2, so I copied the
initrd from the t2 backup to the new t3 /boot and added the initrd
line to grub.conf, and was able to boot into FC6t3 OK. Somehow
anaconda seems to have neglected to build the initrd I seem to need.
Comment 4 Justin Farrelly 2006-09-16 20:18:34 EDT
Yup, similar to 206513 and my DVD instal on an Athlon x64 does exactly as you
describe. Am in process of trying to generate a functional initrd and install it
now, but this seems to be the problem/answer. Complete showstopper for me.
Comment 5 John Thacker 2006-09-18 09:48:41 EDT

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

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