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.
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
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 tree.
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[0], N_("Master Boot Record (MBR)")) return ret 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 /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.)