Today I decided to install all the latest updates (including the -06 kernel). The "yum update" seems to have run just fine (no errors), but when I rebooted the system it just sits there with the word "GRUB" in the upper left hand corner. I booted from the CentOS 4.5 install CD into rescue mode, did a "chroot /mnt/sysimage" and reinstalled grub and the latest kernel, but it still gets stuck in the same place. It's not that I can't boot the new kernel; I can't even get to the grub screen!
Any ideas? I am totally stuck at the moment...
Alfred
Today I decided to install all the latest updates (including the -06 kernel). The "yum update" seems to have run just fine (no errors), but when I rebooted the system it just sits there with the word "GRUB" in the upper left hand corner. I booted from the CentOS 4.5 install CD into rescue mode, did a "chroot /mnt/ sysimage" and reinstalled grub and the latest kernel, but it still gets stuck in the same place. It's not that I can't boot the new kernel; I can't even get to the grub screen!
I'll answer my own question. In addition to re-installing grub, a "grub-install /dev/sda" was required to get the system to boot. I thought that reinstalling grub via yum/rpm would take care of it, but apparently it didn't. Lesson learned, panic averted.
Alfred
Alfred von Campe spake the following on 9/24/2007 1:59 PM:
Today I decided to install all the latest updates (including the -06 kernel). The "yum update" seems to have run just fine (no errors), but when I rebooted the system it just sits there with the word "GRUB" in the upper left hand corner. I booted from the CentOS 4.5 install CD into rescue mode, did a "chroot /mnt/sysimage" and reinstalled grub and the latest kernel, but it still gets stuck in the same place. It's not that I can't boot the new kernel; I can't even get to the grub screen!
I'll answer my own question. In addition to re-installing grub, a "grub-install /dev/sda" was required to get the system to boot. I thought that reinstalling grub via yum/rpm would take care of it, but apparently it didn't. Lesson learned, panic averted.
Alfred
That is what most of us probably thought you meant when you said you re-installed grub.
On 25/09/2007, at 6:41 AM, Scott Silva wrote:
Alfred von Campe spake the following on 9/24/2007 1:59 PM:
Today I decided to install all the latest updates (including the -06 kernel). The "yum update" seems to have run just fine (no errors), but when I rebooted the system it just sits there with the word "GRUB" in the upper left hand corner. I booted from the CentOS 4.5 install CD into rescue mode, did a "chroot /mnt/ sysimage" and reinstalled grub and the latest kernel, but it still gets stuck in the same place. It's not that I can't boot the new kernel; I can't even get to the grub screen!
I'll answer my own question. In addition to re-installing grub, a "grub-install /dev/sda" was required to get the system to boot. I thought that reinstalling grub via yum/rpm would take care of it, but apparently it didn't. Lesson learned, panic averted. Alfred
That is what most of us probably thought you meant when you said you re-installed grub.
Out of interest, is this something that is always required when upgrading Grub?
i.e. should one always manually run "grub-install" /dev/XXX" after doing so?
Cheers,
Michael
Out of interest, is this something that is always required when upgrading Grub?
i.e. should one always manually run "grub-install" /dev/XXX" after doing so?
No, it shouldn't. But in my case, I didn't "upgrade grub". I simply did a "yum update" which installed, among other things, a new kernel, so a reboot was needed. And when I rebooted, grub wouldn't start. So I booted into rescue mode from the CentOS CD #1, and did a "rpm -e grub kernel" followed by "yum install grub kernel". This did not fix the problem. I had to boot into rescue mode again and do a "grub- install /dev/sda". The big question remains, what happened on my system that corrupted the MBR. I could have been anything at all since the last time I rebooted (about a month ago) and not necessarily the "yum update".
Alfred
On Tue, 2007-09-25 at 10:08 +0930, Michael Kratz wrote:
On 25/09/2007, at 6:41 AM, Scott Silva wrote:
Alfred von Campe spake the following on 9/24/2007 1:59 PM:
Today I decided to install all the latest updates (including the -06 kernel). The "yum update" seems to have run just fine (no errors), but when I rebooted the system it just sits there with the word "GRUB" in the upper left hand corner. I booted from the CentOS 4.5 install CD into rescue mode, did a "chroot /mnt/ sysimage" and reinstalled grub and the latest kernel, but it still gets stuck in the same place. It's not that I can't boot the new kernel; I can't even get to the grub screen!
I have seen this behavior before when the BIOS device order does not match what is seen by the running system. Seems that in such cases, running GRUB from the boot media also sees different device/controller ordering than the running system and can lead to GRUB being confused about where to find the stage1 part of the GRUB code. Either changing the device order in the BIOS settings (if that is an option) or changing the order controllers are found in /etc/modprobe.conf seems to help. In any case, check /boot/grub/device.map and assure that it matches what GRUB sees at boot time. Can check this with the GRUB shell "find" command.
I'll answer my own question. In addition to re-installing grub, a "grub-install /dev/sda" was required to get the system to boot. I thought that reinstalling grub via yum/rpm would take care of it, but apparently it didn't. Lesson learned, panic averted. Alfred
That is what most of us probably thought you meant when you said you re-installed grub.
The reinstall of GRUB seems to have been a noop in this case. Helping the boot-loader part of GRUB find the /boot/grub/stageX files by running grub-install was the fix. What is still open to question is what changed on the system to make GRUB lose its pointer to the /boot/grub directory. Usually takes a change in BIOS settings or actual hardware configuration to change the device order.
Out of interest, is this something that is always required when upgrading Grub?
i.e. should one always manually run "grub-install" /dev/XXX" after doing so?
AFAIK that should not be necessary.
Phil
Phil Schaffner wrote:
<snip>
I have seen this behavior before when the BIOS device order does not match what is seen by the running system. Seems that in such cases, running GRUB from the boot media also sees different device/controller ordering than the running system and can lead to GRUB being confused about where to find the stage1 part of the GRUB code. Either changing the device order in the BIOS settings (if that is an option) or changing the order controllers are found in /etc/modprobe.conf seems to help. In any case, check /boot/grub/device.map and assure that it matches what GRUB sees at boot time. Can check this with the GRUB shell "find" command.
</snip>
It's interesting that you mention this as it jogged my memory to a case that happened to me when I tried Fedora 8 recently. Since my system is quite a hodgepodge of drives when I booted F8, it detected the drives in an odd order. The OS installed fine but wouldn't boot afterwards. Upon booting into rescue mode I was able to make adjustments to the device map to get it to alter the way the system booted to match the way F8 saw it at install. It was very hit and miss and I just attributed it to being a beta. Anyways, my suggestion is to check all the drives in your system for said files as mentioned. If they are there, but not where grub is looking for you may have to make changes.
Anyways, my suggestion is to check all the drives in your system for said files as mentioned. If they are there, but not where grub is looking for you may have to make changes.
My system started its life with one drive and CentOS 4.3, and has been "yum updated" and is now at CentOS 4.5. I also added one additional drive to it over the last 18 months. The only time it has failed to boot was when I accidentally initialized the /boot partition. I believe this was an anomaly (something corrupted the MBR). I will soon find out when I do the "yum update" to the other 27 CentOS systems I manage if the update is indeed the culprit (I doubt it).
Alfred