View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002752||CentOS-5||grub||public||2008-03-19 19:57||2014-02-09 17:54|
|Target Version||Fixed in Version|
|Summary||0002752: Damaged grub after running yum update on clean install of 5.1 i386|
|Description||Performed a clean install on 5.1. Ran yum update. Updated the install and got a corrupt grub. No multiple OS boot was setup, so that is not the issue. It happens everytime I install it. Tried netinstall, kickstart and local from DVD. DVD image passes the media check. I have three downloads of it. I fixed grub, but this should not happen on clean install and not modified grub.|
|Tags||No tags attached.|
more input on your hardware configuration would help diagnose your issue...
hard drive: IDE/SATA/SCSI...
If you are kickstarting the ks.cfg and the generated /root/* files.
/var/log/yum.log could tell us what was installed and when.
AFAIK, grub is not updated during 5.1 updates, so it might be the kernel update.
You are the only one reporting this issue, so I would guess it specific to your setup.
I am having the same problem.
Burned and installed fresh CentOS 5.1 DVD into a new server.
My server is an Asustek RS160-E4/PA4 Quad Core with 4GB Ram.
I have two 160GB Sata HDDs in RAID1.
Instalation from DVD works perfectly.
After upgrading the system to the latest packages and reboot, I get a Grub> prompt.
The problem is in fact the kernel upgrade - after it, the server no longer boots.
I've read that in CentOS 4 there was a similar problem and grub had to be configured renaming hd0 to sd0.
I would like to upgrade the kernel, but I am afraid it will waste my time and then I need to reinstall everything.
It would be great that someone look into this.
|If this is happening with fake raid, using soft raid might fix the issue. See http://bugs.centos.org/view.php?id=2568 for example.|
No, this is happening on a server with a real hardware raid controller.
I believe that grub is not modified, but the kernel upgrade becomes incompatible with the definitions in grub config file.
Please look into this, this is major blocker for CentOS users.
I have experienced the what i believe to be the same issue with the latest 5.1 kernel update.
Cannot currently boot.
System is a Dell Vostro 200 with Intel RAID controller and 2x 250GB WD SATA drives.
After loading 5.1 cd rescue mode, the command 'chroot /mnt/sysimage' produces a segmentation fault, so the suggested fix here does not work.
Has anyone found another workaround? I would like to try to avoide a re-install.
says it's raid for windows and linux only. Most probably FAKE raid, otherwise it would be OS agnostic.
on the running kernel, please attach the /var/log/messages boot lines, /etc/modprobe.conf and lsmod ouput.
not sure about your hardware check your disk bios settings (ide/raid/sata).
and same request as for kemoka (lspci/messages/modprobe.conf).
-> the mailing lists or the forum are the right places for support request
If that is ICHR9(7?) - that's a fake raid controller and yes, the latest kernel *does* have issues with that.
Software RAID under CentOS should perform better and works OOTB.
You are right and I was missinformed, my server is in reality the RS120-E5/PA4 and not RS160-E4/PA4, but anyway both have an ICH controller.
I am not familiar with Fake RAID, does this pose any threat to my server? Should I go with CentOS Software RAID instead of the BIOS one? What is the difference?
Anyway, it seems the Kernel has issues with that, which from point of view, is still a bug - I have working system which gets broken after an update - not a Good Thing.
This same thing had happened to me. After a bit of investegation I found that grub was actually looking for a AHCI controller.
I had setup the RAID1 array as per the motherboard instructions.
The first part was in the BIOS. It said to set the
SATA RAID/AHCI Mode to RAID
I went back into the bios and changed it to AHCI and all works fine now.
I can even see the second kernel in the grub boot menu.
This has fixed my problem. Maybe it could be yours as well.
|Does the bug submitter still have issues with this ? If not we can close this bug.|
I recently did an upgrade install of CentOS 5.1 from 4.6 on one of our servers and struck a very similar problem....
What it turned out to be in my case was that GRUB was installed to the wrong disk due to the mount id of disks being different during the install process than they are when booting from the system disk.
What I mean is that when booted from the install DVD, our Raid array was detected and set as /dev/sda (16x500GB drives in Raid 6 on a 3Ware SATA raid controller), and our system/boot disk (a 70GB WD Raptor) was detected as /dev/sdb. And when the system boots off the Raptor it does the reverse (raid is /dev/sdb and Raptor is /dev/sda)!
I assume that the install process installed grub wrongly to the RAID disk array, which is not what I wanted and didn't work. We have the boot partition on the system disk. I didn't twig to this as it was installing as I expected that the system disk would be /dev/sda (hd0) so had no problems with it doing this not knowing that it had actually installed it to our raid array.
To fix this I had to boot off the install disk to a 'linux rescue' console and run grub manually.
In Grub I used the 'find' command to locate the drive grub should boot from - in my case (as we have a seperate boot partition):
'grub> find /grub/stage1'
It reported it as (hd1,0) (disk 1, partition 0).
My grub.conf is set up to boot from hd0,0 - which is actually correct.
So to fix the grub boot problem I simply installed it to (hd1,0):
'grub> setup (hd1) (hd1,0)'
and re-booted off the system disk and it worked.
Don't get trapped by thinking that grub.conf should be configured for (hd1) as I did!
I have no idea if this is a CentOS install problem of just a bios disk selection issue which is different when booting off a CD/DVD etc. For example, using a gparted LiveCD boot also sets the drives the other way around. More knowledgable people than I can perhaps comment on this.....
Good luck and I hope the above helps in some way
Similar experience. Upgraded original 5.1 x86_64 DVD install (-53 version) to vmlinuz-2.6.18-92.1.6.el5 kernel and reboot put system into the grub prompt. Hardware is Dell T3400 with 2 250G disks in Intel array with BIOS RAID1.
Went into rescue, mounted /dev/sda1 and /dev/sdb1 and saw that new kernel was installed into sda1, with attendant grub.conf changes there as well. Took the advice to do a grub "setup (hd1) (hd1,0)" and that worked on reboot but there was no -92 choice, only -53 (since the upgrade went to sda1) and it came up OK. Looks like booting directly into grub chooses sdb1 and labels it "hd0". Running grub from rescue shows both a hd0 and hd1.
Looking to "fix" things, I ran rescue, copied sda1 *92* files over to sdb1, copied the grub.conf over and ran the same setup command. No go, grub prompt. Tried to manually load -92 but got Error 13, invalid executable format. Put back to original (i.e. rm *92* files and reverted grub.conf) and reran setup but still not working, grub shows only a -92 choice for some bizarre reason, and gets Error 13. Only thing that works now is to type in -53 kernel commands manually into grub on every boot :-(.
|So, it turns out the system is NOT correctly configured for BIOS RAID 1. Even though it was ordered as such, the Intel configuration utility needs to be run to complete configuration after setting the BIOS switch. When the BIOS was set back to AHCI I fixed grub by copying the grub.conf on /dev/sdb1 back over itself to rewrite correctly. The only problem with my system re kernel upgrade is that the new kernel files are written to sda1 and the system boots from sdb1. To fix, need to rescue, copy files over to sdb1 and run grub setup. Thanks for addition info in these notes.|
I hit this today too.. No RAID card in this box, no software raid.. just a boot partition, and the rest is LVM. I think the motherboard supports SATA and IDE, but all drives are IDE. Did not use kickstart for the install. I did notice this in my install.log:
grubby fatal error: unable to find a suitable template
But the first boot worked.. it wasn't until after the yum update that I ended up in an endless reboot cycle.. I found this link (http://www.linuxforums.org/forum/installation/125469-installed-centos-rebooted-stuck-grub.html) that seems to indicate it's something to do with kernel-headers, which I had installed after the yum update...
ATTENTION, PLEASE - it seems this bug is still present in CentOS 5.2, as I've hit it today (October 31, 2008). Probably it's the same on RHEL, too.
Please see details, including hardware information, in the bug I've opened at Red Hat's Bugzilla:
I have the same problem with a CentOS 5.2 installed over a fake-raid 1 (mirror) b two SATA 3GB disks.
The motherboard is an Asus P5K PRO with Intel P35/ICH9R chipset.
At grub prompt if I write the following commands
kernel /vmlinuz-2.6.18-92.el5 ro root=/dev/VolGroup00/LogVol01 rhgb quiet
then it boots.
Is range right when he sayd "Software RAID under CentOS should perform better and works OOTB." ?
I just encountered this too.
I updated from fresh install of Centos 5.2 from DVD. Then ran yum update. anaconda updated grub.conf to the following as well as updating the kernel to /vmlinuz-2.6.18-92.1.18.el5.
title Memtest86+ v2.01
title CentOS (2.6.18-92.1.18.el5)
kernel /vmlinuz-2.6.18-92.1.18.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
title CentOS (2.6.18-92.el5)
kernel /vmlinuz-2.6.18-92.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
After rebooting, it drops to the grub prompt. I had to load the kernal and boot manually.
|The upstream BZ is for CentOS only. Can anyone confirm this on RHEL? Might get more attention.|
I'm not able to confirm this on RHEL (since I have no RHEL systems around), but this IS present in Fedora 9 and Fedora 10. Actually, it's one of the most "visible" and annoying bugs of it... It happened on *every* machine I've upgraded from F9 to F10 (and a lot of times during F9 online updates). I'll bet this bug is in RHEL as well.
Please see bug 473306 in Red Hat's bugzilla (and related), including exact hardware details, via smolt.
As a hardware particularity, I use commodity Asus mainboards, which all have integrated NICs with RTL8111/8168B *revision 2* chipset on them - in Linux, a continuous source of unreliability, lately... :-(
Just got this on a server running Centos 5.3, with software RAID. Unfortunately the server is located in a datacentre 1000 miles away, so I had to pay extortionate rates for them to fix this. To me this is a fundamental flaw which really should get some serious attention, and doesn't seem to have been addressed in over a year.
Some extra info.
I have three partitions:
/dev/md1 on / type ext3 (rw,acl)
/dev/md0 on /boot type ext3 (rw)
/dev/md2 is the swap.
I set it up like this with /boot on its won partition due to advice I found when I was installing the server originally, which was actually meant to avoid this behaviour. Apparently not.
Some details from /var/log/yum.log. NB. Grub itself was not updated, just the kernel.
May 17 12:30:34 Updated: centos-release-notes - 5.3-3.i386
May 17 12:32:12 Updated: centos-release - 10:5-3.el5.centos.1.i386
May 17 12:32:17 Updated: kernel-headers - 2.6.18-128.1.10.el5.i386
May 17 12:32:39 Installed: avahi-compat-libdns_sd - 0.6.16-1.el5_2.1.i386
May 17 12:34:16 Updated: dmraid - 1.0.0.rc13-33.el5.i386
May 17 12:35:39 Installed: kernel - 2.6.18-128.1.10.el5.i686
May 17 12:35:40 Updated: system-config-lvm - 1.1.5-1.0.el5.noarch
May 17 12:36:32 Installed: kernel-devel - 2.6.18-128.1.10.el5.i686
May 17 12:37:46 Updated: yum - 3.2.19-18.el5.centos.noarch
Post Update grub.conf
# grub.conf generated by anaconda
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/md1
# initrd /initrd-version.img
title CentOS (2.6.18-128.1.10.el5)
kernel /vmlinuz-2.6.18-128.1.10.el5 ro root=/dev/md1
title CentOS (2.6.18-92.1.22.el5)
kernel /vmlinuz-2.6.18-92.1.22.el5 ro root=/dev/md1
title CentOS (2.6.18-53.1.4.el5)
kernel /vmlinuz-2.6.18-53.1.4.el5 ro root=/dev/md1
The upstream BZ closed:
"Due to lack of response closing as WONTFIX"
|2008-03-19 19:57||macfreak||New Issue|
|2008-03-20 20:42||tru||Note Added: 0007047|
|2008-04-16 22:36||kemoka||Note Added: 0007142|
|2008-04-17 17:30||toracat||Note Added: 0007145|
|2008-04-19 10:27||kemoka||Note Added: 0007149|
|2008-05-06 09:01||w022a||Note Added: 0007220|
|2008-05-06 09:27||tru||Note Added: 0007221|
|2008-05-06 09:33||range||Note Added: 0007222|
|2008-05-06 10:17||kemoka||Note Added: 0007223|
|2008-05-19 06:13||SharM||Note Added: 0007283|
|2008-05-22 13:12||timverhoeven||Note Added: 0007297|
|2008-06-06 05:22||radar_ken||Note Added: 0007380|
|2008-07-30 01:17||gdenton||Note Added: 0007773|
|2008-07-30 16:24||gdenton||Note Added: 0007776|
|2008-08-28 18:42||rstory||Note Added: 0007880|
|2008-10-31 18:44||rsandu||Note Added: 0008214|
|2008-11-02 07:57||eide||Note Added: 0008217|
|2008-11-03 01:firstname.lastname@example.org||Status||new => acknowledged|
|2008-11-19 22:50||scshuang||Note Added: 0008308|
|2008-12-12 15:23||prschaffner||Note Added: 0008433|
|2008-12-13 08:43||rsandu||Note Added: 0008445|
|2009-05-18 04:59||plutocrat||Note Added: 0009363|
|2013-03-19 14:26||toracat||Note Added: 0016772|
|2014-02-09 17:54||tigalch||Status||acknowledged => closed|
|2014-02-09 17:54||tigalch||Resolution||open => won't fix|