Bug 733108 - After yum update, boot fails with "Unable to mount root fs unknown-block(0,0)"
Summary: After yum update, boot fails with "Unable to mount root fs unknown-block(0,0)"
Keywords:
Status: CLOSED DUPLICATE of bug 756559
Alias: None
Product: Fedora
Classification: Fedora
Component: grubby
Version: 15
Hardware: i386
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-24 19:11 UTC by Stef Walter
Modified: 2012-04-24 18:58 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-01-23 16:39:20 UTC


Attachments (Terms of Use)
Picture of the kernel panic (609.72 KB, image/jpeg)
2011-08-24 19:11 UTC, Stef Walter
no flags Details
List of all RPM's installed (42.32 KB, text/plain)
2011-08-24 19:27 UTC, Stef Walter
no flags Details

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?


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