Bug 153060 - "MBR not suitable as boot device" printed, then system hangs at reboot
"MBR not suitable as boot device" printed, then system hangs at reboot
Status: CLOSED DUPLICATE of bug 114690
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: anaconda (Show other bugs)
4.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-01 01:15 EST by Anchor Systems Managed Hosting
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-01 11:39:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Anchor Systems Managed Hosting 2005-04-01 01:15:03 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:

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

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 02:19:58 EST
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 11:39:19 EST
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-03 20:46:00 EDT
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 13:08:08 EDT
grub-install hasn't *ever* supported doing this, until very recently in the FC4
tree.
Comment 5 Anchor Systems Managed Hosting 2005-04-04 20:39:28 EDT
Supported or not, the kickstart configuration described above used to result in
a bootable operating system.
Comment 6 Trevin Beattie 2005-04-21 15:24:45 EDT
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[0], N_("Master Boot Record (MBR)"))
             return ret
 
         if iutil.getPPCMacGen() == "NewWorld":
Comment 7 Trevin Beattie 2005-04-21 22:11:42 EDT
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
/dev/md0.

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

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