Bug 234724

Some more info.
I tried to install the MBR manually and got a bit further:

###
[root@localhost ~]# grub --device-map=/dev/null

    GNU GRUB  version 0.97  (640K lower / 3072K upper memory)

 [ Minimal BASH-like line editing is supported.  For the first word, TAB
   lists possible command completions.  Anywhere else TAB lists the possible
   completions of a device/filename.]

grub> device (hd0,1) /dev/mapper/sil_ahaeabccebbg2

grub> device (hd0) /dev/mapper/sil_ahaeabccebbg 

grub> root (hd0,1)
 Filesystem type is ext2fs, partition type 0x83

grub> setup (hd0)
 Checking if "/boot/grub/stage1" exists... yes
 Checking if "/boot/grub/stage2" exists... yes
 Checking if "/boot/grub/e2fs_stage1_5" exists... yes
 Running "embed /boot/grub/e2fs_stage1_5 (hd0)"...  15 sectors are embedded.
succeeded
 Running "install /boot/grub/stage1 (hd0) (hd0)1+15 p (hd0,1)/boot/grub/stage2
/boot/grub/grub.conf"... failed

Error 22: No such partition

grub> find /boot/grub/stage
 Possible files are: stage1 stage2

grub> find /boot/grub/stage1
 (hd0,1)

grub> find /boot/grub/stage2
 (hd0,1)

grub> find /boot/grub/grub.conf
 (hd0,1)

grub> setup (hd0)
 Checking if "/boot/grub/stage1" exists... yes
 Checking if "/boot/grub/stage2" exists... yes
 Checking if "/boot/grub/e2fs_stage1_5" exists... yes
 Running "embed /boot/grub/e2fs_stage1_5 (hd0)"...  15 sectors are embedded.
succeeded
 Running "install /boot/grub/stage1 (hd0) (hd0)1+15 p (hd0,1)/boot/grub/stage2
/boot/grub/grub.conf"... failed

Error 22: No such partition
###

Still failed ... have yet to see how far it boots.

Some more info from when I activated my RAID ... this should have been before
the rest as grub will not let you define these as devices until you activate them:

###
[fedora@localhost ~]$ su -
[root@localhost ~]# dmraid -s
*** Set
name   : sil_ahaeabccebbg
size   : 625140400
stride : 0
type   : mirror
status : ok
subsets: 0
devs   : 2
spares : 0
[root@localhost ~]# dmraid -ay
[root@localhost ~]# dmraid -s
*** Active Set
name   : sil_ahaeabccebbg
size   : 625140400
stride : 0
type   : mirror
status : ok
subsets: 0
devs   : 2
spares : 0
[root@localhost ~]# ls -la /dev/mapper/ {pressed tab}
control            livecd-rw          sil_ahaeabccebbg   sil_ahaeabccebbg1 
sil_ahaeabccebbg2  sil_ahaeabccebbg3  
[root@localhost ~]# 
###

(In reply to comment #1)
> Still failed ... have yet to see how far it boots.

Now the stage1 is installed in the MBR of the RAID set but I get a continuous
never-ending stream of "GRUB Loading stage1.5" messages even when I pull out the
second SATA drive of the RAID set.

I am now getting to the point where I get a grub prompt and then can't boot to a
kernel because when I try to set the boot partition I get the following error:
Error 18: Selected cylinder exceeds maximum supported by BIOS
... even though installing and booting to one single disk of the ones used in
teh RAID set works fine.

I am under the impression that most people just recommend that users do software
RAID even if there is some hardware-assisted RAID on their controller card.

I would be happy with an anaconda solution that allows Linux to just completely
ignore the dmraid-ness of the machine when it is enabled in the BIOS and just
install grub and initrd as if it was a plain software RAID 1. That would allow
me to have my Windows partition (that has no concept of plain software RAID) to
use the BIOS RAID and my Linux partition to happily use pure software RAID.

I'm not sure if the Sil 3112 RAID BIOS would actively interfere with this scheme
though.

Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp