Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 153060 - "MBR not suitable as boot device" printed, then system hangs at reboot
Summary: "MBR not suitable as boot device" printed, then system hangs at reboot
Status: CLOSED DUPLICATE of bug 114690
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: anaconda
Version: 4.0
Hardware: i386
OS: Linux
Target Milestone: ---
: ---
Assignee: Anaconda Maintenance Team
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2005-04-01 06:15 UTC by Anchor Systems Managed Hosting
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-04-01 16:39:19 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Anchor Systems Managed Hosting 2005-04-01 06:15:03 UTC
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:

bootloader --location=mbr
zerombr yes
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):

How reproducible:

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.

bootloader --location=mbr
zerombr yes
clearpart --all --initlabel

2. Reboot

Actual Results:  System hangs when attempting to boot from the hard drive

Expected Results:  GRUB should have come up and presented the boot menu.

Additional info:

Have attempted the same thing on several machines. Problem also occurs using Fedora Core 3.

Comment 1 Anchor Systems Managed Hosting 2005-04-01 07:19:58 UTC
Specifically, here is our SCSI RAID1 kickstart fragment:

# /
part raid.00 --size 500      --ondisk=sda
part raid.01 --size 500      --ondisk=sdb
# swap
part raid.10 --size 2048     --ondisk=sda
part raid.11 --size 2048     --ondisk=sdb
# /var
part raid.20 --size 2048     --ondisk=sda
part raid.21 --size 2048     --ondisk=sdb
# /usr
part raid.30 --size 2048     --ondisk=sda
part raid.31 --size 2048     --ondisk=sdb
# /data
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

Comment 2 Peter Jones 2005-04-01 16:39:19 UTC
The workaround for this is to not put /boot on RAID.

*** This bug has been marked as a duplicate of 114690 ***

Comment 3 Anchor Systems Managed Hosting 2005-04-04 00:46:00 UTC
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.

Comment 4 Peter Jones 2005-04-04 17:08:08 UTC
grub-install hasn't *ever* supported doing this, until very recently in the FC4

Comment 5 Anchor Systems Managed Hosting 2005-04-05 00:39:28 UTC
Supported or not, the kickstart configuration described above used to result in
a bootable operating system.

Comment 6 Trevin Beattie 2005-04-21 19:24:45 UTC
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.

---   2004-12-14 13:25:04.000000000 -0800
+++    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[0], N_("Master Boot Record (MBR)"))
             return ret
         if iutil.getPPCMacGen() == "NewWorld":

Comment 7 Trevin Beattie 2005-04-22 02:11:42 UTC
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- from WS 4, by the way.
 (Forgot to include the TLD in the diff.)

Note You need to log in before you can comment on or make changes to this bug.