This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Fixed in booty-0.80.4-6 .

pjones,
can you clarify the exact steps to reproduce here? 
In particular looking at the original BZ the reporter seems to use both
partitions and discs in his comments. How many discs and partitions we have here
and what is installed where?

Thanks.

In dmraid, you have multiple disks in a RAID, which we treat as one normal disk
(with a strange path) in the installer.  On the combined raid, install like
normal i.e. a /boot and a LVM PV with / in a Logical Volume, and ask the
installer to install the bootloader on the first partition of the raid.  That
is, install it to /boot on /dev/mappper/isw_Volume_0p1 , not to the MBR on
/dev/mapper/isw_Volume_0 .

Steps to reproduce with hardware RAID (disc  cciss/c0d0 - Compaq Smart Array):
1) Install a system with 4 partitions: /boot, /data, / and swap
/dev/cciss/c0d0
     cciss/c0d0p1 - /boot
     cciss/c0d0p2 - /data
     cciss/c0d0p3 - /
     cciss/c0d0p4 swap

2) Install GRUB on MBR [/dev/cciss/c0d0  Master Boot Record (MBR)]
3) Complete the install and boot into the system. Edit /boot/grub/grub.conf as
if there was another OS on c0d0p2 (/data). We'd like to chainload this OS later.
Also I have an entry for Anaconda to boot into the install (not relevant for
this bug)

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/cciss/c0d0p3
#          initrd /initrd-version.img
#boot=/dev/cciss/c0d0
default=0
timeout=50
serial --unit=0 --speed=38400
terminal --timeout=5 serial console
title Red Hat Enterprise Linux Server (2.6.18-88.el5)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-88.el5 ro root=LABEL=/ console=ttyS0,38400
        initrd /initrd-2.6.18-88.el5.img

title Second Installation
        rootnoverify (hd0,1)
        chainloader +1

title Anaconda
        root (hd0,0)
        kernel /vmlinuz-anaconda console=ttyS0,38400
        initrd /initrd.img-anaconda

4) Perform a second install and select c0d0p2 as / (format if you want). leave
other partitions untouched.
/dev/cciss/c0d0
     cciss/c0d0p1 - untouched (no mount point, was previously /boot)
     cciss/c0d0p2 - / (was previously /data)
     cciss/c0d0p3 - untouched (no mount point, was previously /)
     cciss/c0d0p4 - swap
5) Install GRUB on the first sector of root partition 
   [/dev/cciss/c0d0p2 First sector of boot partition]
6) Complete install and reboot

Results:
* with RHEL 5.1:
The bootloader of the second install gets installed on MBR overwriting the
previous one. Hence the 2nd OS is loaded. The customizations are lost (actually
they are in the c0d0p1 partition and if you mount it you can see them, but this
instance of GRUB is not loaded)

with RHEL5.2 snap #4:
* MBR is not overwritten. GRUB from the 1st install is loaded and all
modifications can be seen from the grub menu. Boot loader of the 2nd OS is
installed on the first sector of its root partition (where we told it to
install). Chainloading works as expected. Booting into 1st OS also works as
expected.

Did the system in comment #11 have a dmraid capable controller? Most systems
with CCISS don't and afaik, it is a requirement to reproduce this bug.

Created attachment 301538 [details]
The patch which was applied

This is the patch applied to fix the problem; it should affect any device using
the 'disk#p#' partition naming scheme.

breeves: test was correct but only because CCISS uses the same naming scheme
nstraz: so an install to an aoe or mpath device would exercise the code too

The test in comment #11 turned out to be enough. No need to test with dmraid
explicitly.

Hello Alexander,

Yes I have access to the rhel 5.2 Snapshots -
please read also 225548 ( which concerns fedora ).
I will do additioal tests, nevertheless I found it very hard to deal with 
dmraid - you get one item fixed and then you find the next problem.
You should have also a look at 164550 in Issue Tracker, here I saw that
my problem with dmraid with 2 dmraids seem to be FastTrak unique -
I could install a rhel5.2 Snapshot3 on a Primergy TX200-S3 (ESB2) on 2 RAID1, 
but after reboot I only saw the sata disks ( /dev/sda .... /dev/sdd ) instead 
of /dev/mapper/dff1_.....

Winfrid,
the root cause of the problem was a bug in the code which affected devices that
used the 'disk#p#' partition naming scheme. dmraid is one of the cases. 
If you have the time you can retest this issue with dmraid setup although we
believe the test in comment #11 was enough to verify the fix of this issue.

Thanks.

Alexander,

I have verified that a bootrecord is written to the requested partition, 
but ...

on my booted system I see /dev/sda7 instead of /dev/mapper/ddf1_.......p7 !
On the same system I installed fedora 8 and there everything looks good.
But fedora 9 does not install at all !

Winfrid

PS.: I know this is a new bugzilla entry, but send me some advice, that 
     I can prepare as much information as possible.

Winfrid,
if your disk was named /dev/sda7 then the code path that got fixed was not
executed (see comment #16, #17).

Please open another bug with the following information:
* Version of RHEL/Fedora and your hardware setup where you saw differences in
disk naming between Fedora and RHEL. If you've been trying to use dmraid on RHEL
it may have silently failed without you noticing that.

* If you're trying to test the same environment with Fedora 9 then ensure you
have a tree that is installable in a default environment (e.g. lvm). If this is
the case then file a bug against Rawhide with the information from the failure.
You'd probably want to post to fedora-test-list _at_ redhat.com to seek more
advise. 


Please do not use this issue to track dmraid failures or other Fedora issues. It
was created to track the issue where boot loader was not installed on the
requested partition but on MBR.


Thanks.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2008-0444.html