Red Hat Bugzilla – Bug 452056
MBR gets installed in the wrong place on HP DL585
Last modified: 2009-11-30 05:36:23 EST
Description of problem:
During a fresh install or an update install, the MBR gets installed in the wrong
Version-Release number of selected component (if applicable):
Try to install or update install RHEL5.2 (from RHEL5.1 in this case) on a HP
Proliant that has both SW RAID and FCP LUNs attached. The MBR ends up on FCP LUN
0 (/dev/sda) and not on the SW RAID lun (/dev/cciss/c0d0)
Steps to Reproduce:
1.Any proliant with an SW RAID and an FCP HBA
2. Register the HBA's WWID so that LUNS appear upon boot (/dev/sda, /dev/sdb etc)
3. Do a initial or update install
The installer insists in the initial install case on putting the MBR on
/dev/sda, not on /dev/cciss/c0d0.
In the update install case, it automatically updates it to the wrong place.
In the UPDATE INSTALL case, /dev/cciss/c0d0 should continue to hold the MBR. In
the INITIAL INSTALL case, /dev/cciss/c0d0 should be as the boot device.
FCP HBA was a QLA 2312.
Luns supplied by a Netapp 960
SW RAID lun consisted of 4 36GB U320 drives configured as 1 RAID5 volume
The DL585 had 64GB of memory and 4 AMD 250 CPUs.
The BIOS IPL order had the PCI Embedded RAID appear before the Qlogic HBA
I've seen this as well on a Proliant BL680C. The storage configuration is the same (cciss and SAN luns).
Work around is as follows:
* Review partitions during install
* Select "Configure advanced boot loader options".
* From this screen you can change the Driver Order to place the local disk at the top of the list, and select c0d0 as the target for the MBR installation.
Anaconda should be smarter here, as we've already told it not to touch /dev/sd* on a previous screen.
There are 2 issues here:
1) anaconda can not reliable detect from which drive the BIOS will boot the system
this is always true, but esp. so in the case when booting from an add in card
with a separate option ROM. As this makes detecting which drive the BIOS is
set to boot from even harder. So we cannot automatically get this right.
Another example where we fail to get this right is when installing from a
usb stick, because then usually we do manage to find out which disk the
system is booted from through the EDD BIOS extension, but the BIOS then tells
us the system is booted from the usb stick, which is correct, but usually
not the place where the user wants to install the bootloader.
So there will always be cases where one needs to use the advanced bootloader
options as described in comment #1.
2) There are several scenario's where users want to not use a disk for
installation, yet still put the bootloader there, so we cannot assume that
if a disk is not used for installation, we should not put the bootloader there.