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.
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?
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
Created attachment 519698 [details] List of all RPM's installed
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.
I agree that it's hard to duplicate, but when it does happen it's pretty disastrous for a non-technical user.
or a problem with new-kernel-pkg ... please post /var/log/dracut.log
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
(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
*** This bug has been marked as a duplicate of bug 756559 ***
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?