Red Hat Bugzilla – Bug 615066
yum updated kernel v. 2.6.32.16-141 won't boot
Last modified: 2010-07-22 07:18:03 EDT
Description of problem: After yum update to latest sw, including kernel, machine will not boot. Using grub previous kernel version, machine boots normally. Version-Release number of selected component (if applicable): 2.6.32.16-141.fc12.i686.PAE Note: may be initrd image rather than kernel: initrd /initramfs-2.6.32.16-141.fc12.i686.PAE.img How reproducible: Always. Steps to Reproduce: 1. Run yum update 2. Reboot, selecting grub default 3. Wait forever for boot. Actual results: Blinking VGA hyphen cursor; same as one which presents before BIOS screen loads. Expected results: Usual bootup text messages, followed by Gnome login. Additional info: My machine is Dell Dimension 1100 (DE051) with stable BIOS v. A01. Memory is 1.2 GB; plenty of disc space. grub.conf lines are identical for failing kernel and previous (still working) kernel, except for the version numbers. Previous (working) kernel version is 2.6.32.14-127.fc12.i686.PAE
Last night, I yum-updated a Compaq with the same files as in the case above: The machine booted normally, so this problem seems to be machine-specific and almost certainly can not be because of a bad .rpm file.
Can you edit grub.conf and remove 'rhgb' and 'quiet' from the options for the broken kernel, then try booting and see if any messages show up?
I always boot without these options, because they slow down the boot. The only grub option was "text". grub.conf apparently never loads, so I think that grub options would have no effect anyway.
OOPS! Sorry: Grub.conf IS loaded, but system does not proceed after allowing the 141 kernel to be booted.
Nothing prints at all, not even the "probing EDD" message?
To answer your question, there was nothing at all on screen, after selecting the 141 kernel in grub, except a blinking VGA cursor -- horizontal bar or hyphen cursor. BUT, I found the problem: After a disc crash yesterday and fsck cleanup (a few zeroed inodes), I reinstalled the 141 kernel rpm's (4 of them) using rpm -iv --force. This fixed the problem, which apparently was because of a bad block somewhere in the new kernel image(s). NOTE: Initially, I did try yum --reinstall, but yum refused to reinstall a kernel, even though the running kernel was not the one to be reinstalled! This is a limitation in yum with no obvious reason. Anyway, because of it, I didn't try to reinstall immediately, which SHOULD have been the first thing to do to troubleshoot this problem. I suggest closing this bug, which seems to have been because of a hard disc defect.