Red Hat Bugzilla – Bug 153060
"MBR not suitable as boot device" printed, then system hangs at reboot
Last modified: 2007-11-30 17:07:17 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20041013 Firefox/0.9.3 (Ubuntu)
Description of problem:
After creating a custom install kickstart script either by editing the anaconda-ks.cfg or making a completely new one using the X kickstart generator application we are attempting to load up a machine with a fresh install and a RAID hard drive configuration.
Shortly after the network is brought up, where it would usually ask you about the bootloader options, on one of the other virtual terminals it prints:
* MBR not suitable as boot device; installing to partition
The rest of the installation goes as planned. After rebooting, the system hangs once it tries to boot from the disk. It appears as though GRUB has not been installed. Note that we started with completely blank disks.
In the kickstart file we are listing the following options:
clearpart --all --initlabel
This only seems to occur when installing in a RAID1 configuration (SCSI or IDE). I also attempted the same installation, having the bootloader option commented out. Anaconda only gave me the option to install the bootloader to /dev/md0 rather than the MBR.
Manually installing GRUB in the MBR resolves the non-booting problem. We are also experiencing the same issue with Fedora Core 3, although not in RHEL3 or Fedora Core 2.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install RHEL4 using a kick"mbr not suitable as boot device"start file with at least two hard drives (IDE or SCSI) in a RAID1 configuration. The kickstart file must contain the following options.
clearpart --all --initlabel
Actual Results: System hangs when attempting to boot from the hard drive
Expected Results: GRUB should have come up and presented the boot menu.
Have attempted the same thing on several machines. Problem also occurs using Fedora Core 3.
Specifically, here is our SCSI RAID1 kickstart fragment:
part raid.00 --size 500 --ondisk=sda
part raid.01 --size 500 --ondisk=sdb
part raid.10 --size 2048 --ondisk=sda
part raid.11 --size 2048 --ondisk=sdb
part raid.20 --size 2048 --ondisk=sda
part raid.21 --size 2048 --ondisk=sdb
part raid.30 --size 2048 --ondisk=sda
part raid.31 --size 2048 --ondisk=sdb
part raid.40 --size 1 --grow --ondisk=sda
part raid.41 --size 1 --grow --ondisk=sdb
# Assemble the RAID devices.
raid / --fstype ext3 --level=RAID1 raid.00 raid.01
raid swap --fstype ext3 --level=RAID1 raid.10 raid.11
raid /var --fstype ext3 --level=RAID1 raid.20 raid.21
raid /usr --fstype ext3 --level=RAID1 raid.30 raid.31
raid /data --fstype ext3 --level=RAID1 raid.40 raid.41
The workaround for this is to not put /boot on RAID.
*** This bug has been marked as a duplicate of 114690 ***
FWIW, this is a kickstart configuration that successfully installed GRUB to both
disks in the RAID set in each of RH 7.3, 8.0, 9, EL3, FC1, and FC2. There must
have been a regression introduced in the development of FC3 and EL4.
grub-install hasn't *ever* supported doing this, until very recently in the FC4
Supported or not, the kickstart configuration described above used to result in
a bootable operating system.
I've successfully installed grub on the MBR of servers where both / and /boot
are RAID1 partitions dozens of times using WS 3. Logically, the choice of
whether to install grub on the MBR or the boot partition should not depend on
what the partition type is.
I think the following short patch would suffice to fix the problem in
anaconda-10. It will take me a while to get around to testing it though, and it
may not be appropriate for non-Intel machines.
--- fsset.py.raid-mbr 2004-12-14 13:25:04.000000000 -0800
+++ fsset.py 2005-04-21 12:20:23.188956840 -0700
@@ -1222,6 +1222,7 @@
if bootDev.getName() == "RAIDDevice":
ret['boot'] = (bootDev.device, N_("RAID Device"))
+ ret['mbr'] = (bl.drivelist, N_("Master Boot Record (MBR)"))
if iutil.getPPCMacGen() == "NewWorld":
I've just now tested the patch, and it works just as expected. The default
location for installing the boot loader was /dev/sda, and on the Advanced Boot
Loader options screen it gave me the choice to install it on either /dev/sda or
Oh, the patch is applied to anaconda-10.1.1.13-1.src.rpm from WS 4, by the way.
(Forgot to include the TLD in the diff.)