Red Hat Bugzilla – Bug 217176
error installing grub on raid devices
Last modified: 2010-10-22 03:07:07 EDT
I'm trying to install grub on a software raid1 device with the following ks setup bootloader --location=mbr clearpart --all --initlabel part raid.01 --size=1 --grow --ondisk=sda part raid.02 --size=1 --grow --ondisk=sdb part swap --size=1024 --grow --maxsize=2048 --ondisk=sdb part swap --size=1024 --grow --maxsize=2048 --ondisk=sda raid / --fstype ext3 --level=raid1 raid.01 raid.02 The installations procedes fine but the systems won't reboot after the install process has completed. So I have to restart with the rescue image and install grub manually. In the anaconda.log I got MBR not suitable as boot device; installing to partition and in the anaconda-ks.cfg bootloader --location=partition --append="rhgb quiet" It's clear that the installer was not able to write to the MBR...
I was able to reproduce this bug on RHEL4u3 and in part on RHEL4u4 On rhel4u3: Installing from kickstart and specifying "bootloader --location=mbr" results in the bootloader being installed to the partition and are unable to boot the os after a reboot. You have to boot the rescue environment and re-setup grub. On rhel4u4: Installing from kickstart and specifying "bootloader --location=mbr" results in the bootloader being installed to the partition. Everything is fine on reboot. You can fail a drive with mdadm and boot from the 2nd drive (software raid1 2 drives) as expected. You can pull even pull out the 1st drive in Bay0 and reboot and the os will boot from the 2nd drive just fine. I can reproduce this reliably on both releases. I have yet to try update 5.
Being that this rears its ugly head frequently its high time I at least dropped in the kickstart magic needed to correct non-booting RAID setups. I'm using a %post script that installs grub to both sda and sdb so that the machine will still boot if sda fails. It attempts to correct the grub device map and installs grub into the MBR rather than the partitioning. This wipes whatever vendor black magic is in the MBR and allows the thing to boot. %post if ! grep "(hd1)" /boot/grub/device.map > /dev/null ; then echo "(hd1) /dev/sdb" >> /boot/grub/device.map fi /sbin/grub --batch << EOT device (hd0) /dev/sda root (hd0,0) setup (hd0) device (hd1) /dev/sdb root (hd1,0) setup (hd1) quit EOT
Created attachment 311385 [details] Install time logs
Created attachment 311386 [details] sosreport of affected system
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
A patch fixing this has been committed to the RHEL-4 anaconda branch: http://git.fedorahosted.org/git/?p=anaconda.git;a=commitdiff;h=1263e881d7029c85bb0cca42abd5851827751d17 This fix will be included in anaconda-10.1.1.92 .
Tested with reproducer from comment #0 anaconda-10.1.1.96-1: anaconda-ks.cfg has: bootloader --location=mbr the error message in anaconda.log from comment #0 is not present. Moving to VERIFIED.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-0978.html