Bug 440703

Summary: Installer completes, but creates insufficient initrd to boot
Product: [Fedora] Fedora Reporter: Brandon Mayes <bdmayes>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 8   
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-03 20:04:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Brandon Mayes 2008-04-04 15:09:26 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.13) Gecko/20080325 Fedora/2.0.0.13-1.fc8 Firefox/2.0.0.13

Description of problem:
This appears to be the same behavior reported in a Fedora Core 2 bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=126953


I installed Fedora 8 x86_64 on a newly added SATA-II drive in my system.  The installation process went fine, but when the computer rebooted, Fedora 8 would not load.  Instead, it kernel panics and I get this message:

VFS: Cannot open root device "sdb1" or unknown-block(0,0)
Please append a correct "root=" boot option; here are the available partitions:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)



My drives are partitioned as follows:

/dev/sda:
 1 NTFS partition running Windows XP

/dev/sdb:
 sdb1: ext3 for Fedora 8
 sdb2: 1GB swap
 sdb3: ext3 for Ubuntu
 sdb4: NTFS "data" partition


I was able to work around the problem by using the suggestion in the above:

1. reboot with the Fedora 8 DVD in the drive
2. enter the recovery mode
3. chroot /mnt/sysimage
4. mkinitrd --preload=scsi_mod --preload=sd_mod --with=ata_piix \
             /boot/initrd-2.6.23.1-42.fc8.img-sata 2.6.23.1-42.fc8
5. update menu.lst with the following information:

title           Fedora 8 (Werewolf)
root            (hd1,0)
kernel          /boot/vmlinuz-2.6.23.1-42.fc8 root=/dev/sdb1 rhgb quiet
initrd          /boot/initrd-2.6.23.1-42.fc8.img-sata
savedefault
boot

6. reboot and now the kernel loads

Version-Release number of selected component (if applicable):
kernel-2.6.23.1-42.fc8

How reproducible:
Always


Steps to Reproduce:
1. Install Fedora8 x86_64
2. Reboot after installer has finished and kernel will panic

Actual Results:
Kernel panic; Fedora 8 never finishes startup

Expected Results:
Fedora 8 should load

Additional info:
Here is some information about my system's hardware:

CPU:  Athlon64 3800+
MOTHERBOARD:  ASUS A8N-SLI Deluxe
HARD DISKS:  2 SATA-II (3 Gbps) drives
MEMORY:  2GB PC3200 DDR
GRAPHICS:  Nvidia 7600GT (by EVGA)

Comment 1 Chris Lumens 2008-04-22 14:33:49 UTC
Is this still a problem in F9 Preview?

Comment 2 Brandon Mayes 2008-04-25 13:20:32 UTC
I installed F9 preview and I tried to test it out.  Again, the installer
completed just fine but when I went to boot it, all I receive is this:

---------------------------------------
Error 2: Bad file or directory type

Press any key to continue...
---------------------------------------

Pressing a key returns me to the grub menu where I can load Ubuntu or Windows XP
just fine.  I am still trying to figure out how to fix this.  I have tried
numerous changes to menu.lst and none of them seem to make a difference, though
I'm honestly not even sure if this is related to menu.lst settings.

Once I get this fixed (hopefully I can), I will post with more information about
this particular bug report.

Comment 3 Brandon Mayes 2008-05-03 19:49:30 UTC
I have been able to successfully figure out the "Bad file or directory type"
issue from my previous comment.  It is caused by bug 443289.

I went ahead and installed Fedora 9 preview x86_64 (and let it write grub to the
MBR this time to avoid bug 443289) using the live DVD.  I was able to
successfully boot without needing to make a new initrd, so it appears this issue
has been resolved in F9.  I believe this bug can be closed at this point.