John Fleming wrote:
"yum" did not mess this up. Yum could not complete the update since it had no location to write the kernel and grub updates into.- From your partition table, it looks strongly to me like your real boot partition is at /dev/hda1. So all you need to do is edit the /etc/fstab about LABEL=/boot to read instead there /dev/hda1
/dev/hda1 /boot ext3 defaults 1 2
keep the rest of the file the same. You'll need to be root when you
edit /etc/fstab. Make sure it's right, save, then that's it, reboot.
BIG THANKS guys! That fixed it. I then did rpm -e kernel.....2179 again, then ran up2date again and it installed the 2179 kernel without error. THIS TIME, however, on reboot, I got the new kernel in the graphical boot screen as the default choice, and things are back to normal. Now, who knows how this got messed up in the yum update process?? ;-)
The problem originated with fstab using the LABEL=/boot, and you had 2 devices the machine saw with the /boot label
It can occur when another device in the machine (as has already been stated) has the same label.
I saw it when I installed a new drive and did a clean install to the new drive, while the old drive was disconnected. I did not remove the labels on the old drive and when I reconnected it as a second drive the problem you saw surfaced.
In your case, you could still boot since grub does not use mounted filesystems to boot. However, once the system was up, /boot was not mounted so nothing could use it's contents.
Now, confessions of a newbie, AKA the rest of the story - When I used vim to edit fstab, I managed to make an error, and that really messed things up when rebooting! However, I booted with a Knoppix CD and managed to mount / and correct my fstab typo. Then another reboot and things were fine!
Thanks again to Andy and everyone that helped sort this out. - John
