2018-01-22 06:13 UTC

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002752CentOS-5grubpublic2014-02-09 17:54
Reportermacfreak 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionwon't fix 
Product Version5.1 
Target VersionFixed in Version 
Summary0002752: Damaged grub after running yum update on clean install of 5.1 i386
DescriptionPerformed 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.
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0007047

tru (administrator)

more input on your hardware configuration would help diagnose your issue...
hard drive: IDE/SATA/SCSI...
what motherboard?

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.

~0007142

kemoka (reporter)

Hi,

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.

Thank you!

~0007145

toracat (manager)

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.

~0007149

kemoka (reporter)

Hello toracat,

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.

~0007220

w022a (reporter)

I have experienced the what i believe to be the same issue with the latest 5.1 kernel update.

Cannot currently boot.
grub>

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.

~0007221

tru (administrator)

kemoka:
http://www.asus.com/products.aspx?l1=9&l2=40&l3=115&l4=0&model=1640&modelmenu=1
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.

w022a:
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

~0007222

range (administrator)

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.

~0007223

kemoka (reporter)

tru:

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.

Thank you!

~0007283

SharM (reporter)

Hi
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.
Cheers
Steve

~0007297

timverhoeven (developer)

Does the bug submitter still have issues with this ? If not we can close this bug.

~0007380

radar_ken (reporter)

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
Cheers,
Ken

~0007773

gdenton (reporter)

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 :-(.

~0007776

gdenton (reporter)

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.

~0007880

rstory (reporter)

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...

~0008214

rsandu (reporter)

Hello,

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:

https://bugzilla.redhat.com/show_bug.cgi?id=469384

Best regards,
Răzvan

~0008217

eide (reporter)

Hi,
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

 root (hd0,0)
 kernel /vmlinuz-2.6.18-92.el5 ro root=/dev/VolGroup00/LogVol01 rhgb quiet
 initrd /initrd-2.6.18-92.el5.img
 boot

then it boots.

Is range right when he sayd "Software RAID under CentOS should perform better and works OOTB." ?

Bye.

~0008308

scshuang (reporter)

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.

default=1
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Memtest86+ v2.01
        kernel /memtest86+-2.01
title CentOS (2.6.18-92.1.18.el5)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-92.1.18.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
        initrd /initrd-2.6.18-92.1.18.el5.img
title CentOS (2.6.18-92.el5)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-92.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
        initrd /initrd-2.6.18-92.el5.img

After rebooting, it drops to the grub prompt. I had to load the kernal and boot manually.

~0008433

prschaffner (reporter)

The upstream BZ is for CentOS only. Can anyone confirm this on RHEL? Might get more attention.

~0008445

rsandu (reporter)

Hello all,

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... :-(

Regards,
Răzvan

~0009363

plutocrat (reporter)

Hi,
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
cat /boot/grub/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
#boot=/dev/md0
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-128.1.10.el5)
    root (hd0,0)
    kernel /vmlinuz-2.6.18-128.1.10.el5 ro root=/dev/md1
    initrd /initrd-2.6.18-128.1.10.el5.img
title CentOS (2.6.18-92.1.22.el5)
    root (hd0,0)
    kernel /vmlinuz-2.6.18-92.1.22.el5 ro root=/dev/md1
    initrd /initrd-2.6.18-92.1.22.el5.img
title CentOS (2.6.18-53.1.4.el5)
    root (hd0,0)
    kernel /vmlinuz-2.6.18-53.1.4.el5 ro root=/dev/md1
    initrd /initrd-2.6.18-53.1.4.el5.img

~0016772

toracat (manager)

The upstream BZ closed:

"Due to lack of response closing as WONTFIX"
+Notes

-Issue History
Date Modified Username Field Change
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:31 kbsingh@karan.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
+Issue History