Bug 733108

Summary: After yum update, boot fails with "Unable to mount root fs unknown-block(0,0)"
Product: [Fedora] Fedora Reporter: Stef Walter <stefw>
Component: grubbyAssignee: Peter Jones <pjones>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 15CC: bcl, dracut-maint, gansalmon, harald, itamar, jonathan, kernel-maint, madhu.chinakonda, mads, pjones
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-01-23 16:39:20 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:
Attachments:
Description Flags
Picture of the kernel panic
none
List of all RPM's installed none

Description Stef Walter 2011-08-24 19:11:32 UTC
Created attachment 519694 [details]
Picture of the kernel panic

Description of problem:

After doing a yum update, and then later rebooting, the boot fails with the kernel panic "Unable to mount root fs unknown-block(0,0)"


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

How reproducible: Not sure if this is easily reproducible, but a kernel package seems at fault.
  
Actual results: No boot


Expected results: Computer should boot.


Additional info: I'll attach pictures and version info as I debug the problem.

Comment 1 Josh Boyer 2011-08-24 19:20:08 UTC
2.6.40 is f15-only.

It sounds like either an initramfs didn't get created or something was corrupted with it.  Can you see if there is an initrd line in the grub.conf file for that kernel?  Did you see any errors during the yum update?

Comment 2 Stef Walter 2011-08-24 19:27:00 UTC
I didn't catch the errors during yum update, sadly. You're right, it seems that an entry was left (or added) to grub's menu.list without an appropriate initrd line. In addition the initramfs for the kernel in question was missing.

I managed to fix the problem by commenting out the first 'item' (title, root, kernel) of grub's menu.lst.

Contents of /boot:

total 45424
  120 config-2.6.38.6-26.rc1.fc15.i686
  124 config-2.6.40.3-0.fc15.i686
  124 config-2.6.40-4.fc15.i686
    4 efi
  176 elf-memtest86+-4.20
    4 grub
13612 initramfs-2.6.38.6-26.rc1.fc15.i686.img
14160 initramfs-2.6.40-4.fc15.i686.img
  176 memtest86+-4.20
 1812 System.map-2.6.38.6-26.rc1.fc15.i686
 1792 System.map-2.6.40.3-0.fc15.i686
 1828 System.map-2.6.40-4.fc15.i686
 3716 vmlinuz-2.6.38.6-26.rc1.fc15.i686
 3824 vmlinuz-2.6.40.3-0.fc15.i686
 3952 vmlinuz-2.6.40-4.fc15.i686




Contents of /boot/grub/menu.lst:

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You do not have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /, eg.
#          root (hd0,0)
#          kernel /boot/vmlinuz-version ro root=/dev/sda1
#          initrd /boot/initrd-[generic-]version.img
#boot=/dev/sda
default=0
timeout=0
splashimage=(hd0,0)/boot/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.40.3-0.fc15.i686)
	root (hd0,0)
	kernel /boot/vmlinuz-2.6.40.3-0.fc15.i686 ro root=UUID=ce95272a-8c4c-4df4-9550-c4eb2c4f1f05 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=dvorak rhgb quiet
title Fedora (2.6.40-4.fc15.i686)
	root (hd0,0)
	kernel /boot/vmlinuz-2.6.40-4.fc15.i686 ro root=UUID=ce95272a-8c4c-4df4-9550-c4eb2c4f1f05 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=dvorak rhgb quiet
	initrd /boot/initramfs-2.6.40-4.fc15.i686.img
title Fedora (2.6.38.6-26.rc1.fc15.i686)
	root (hd0,0)
	kernel /boot/vmlinuz-2.6.38.6-26.rc1.fc15.i686 ro root=UUID=ce95272a-8c4c-4df4-9550-c4eb2c4f1f05 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=dvorak rhgb quiet
	initrd /boot/initramfs-2.6.38.6-26.rc1.fc15.i686.img

Comment 3 Stef Walter 2011-08-24 19:27:26 UTC
Created attachment 519698 [details]
List of all RPM's installed

Comment 4 Josh Boyer 2011-11-29 20:21:08 UTC
OK.  That seems like a problem with dracut not creating the initramfs in the %posttrans section of the kernel.spec.

We've seen this a few times over the past few months.  Since this isn't really a kernel problem, I'm reassigning to dracut.  Being honest, unless you can somehow hit this regularly with all kernel updates, I'm not sure there is much to be done.

Comment 5 Stef Walter 2011-11-29 20:50:09 UTC
I agree that it's hard to duplicate, but when it does happen it's pretty disastrous for a non-technical user.

Comment 6 Harald Hoyer 2011-12-02 07:32:34 UTC
or a problem with new-kernel-pkg ...

please post /var/log/dracut.log

Comment 7 Stef Walter 2011-12-02 07:52:46 UTC
Its empty. Does it get truncated every time you update the kernel?

[stef@stef-desktop gnome-keyring]$ sudo ls -l /var/log/dracut.log
-r-------- 1 root root 0 Nov 28 08:31 /var/log/dracut.log

Comment 8 Harald Hoyer 2012-01-23 09:25:07 UTC
(In reply to comment #7)
> Its empty. Does it get truncated every time you update the kernel?
> 
> [stef@stef-desktop gnome-keyring]$ sudo ls -l /var/log/dracut.log
> -r-------- 1 root root 0 Nov 28 08:31 /var/log/dracut.log

no, it means, that dracut probably wasn't called by "/sbin/new-kernel-pkg"
also, there is no initramfs line in grub.conf

Comment 9 Brian Lane 2012-01-23 16:39:20 UTC

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

Comment 10 Mads Kiilerich 2012-04-24 18:58:21 UTC
I really doubt this is a duplicate of bug 756559 - I don't see any evidence that it should be the same problem.

Do you still see the problem?