GRUB2 and Fedora 12 Intel FakeRAID

[John Sheu]

First post.  Well, this better be good.

I've been having issues with trying to install GRUB2 on a system
running Fedora 12.  My disk setup is one fakeRAIDed RAID5 array (of 4
disks), partitioned into a few OS partitions.  On the OS partition
where Fedora 12 is living, I've broken up the space into the usual /,
/home, swap, etc. partitions using LVM2.  So I'm essentially dealing
with a LVM2-root-on-Intel-fakeRAID setup of doubled complication.  But
the LVM2 is not what's giving me trouble.

During the execution of grub-install, I get this snippet of debug
spew.  Note that the fake-RAID array is designated /dev/md127:

---- begin spew ----
pulsar grub-1.98 # grub-install /dev/md127 --debug
    <snip>
+ /sbin/grub-setup --verbose --directory=/boot/grub
--device-map=/boot/grub/device.map /dev/md127
/sbin/grub-setup: info: Cannot stat `/dev/mapper/raid0', skipping.
/sbin/grub-setup: info: the size of gentoo_10-root is 41943040.
/sbin/grub-setup: info: the size of gentoo_10-root is 41943040.
/sbin/grub-setup: info: the size of gentoo_10-root is 41943040.
/sbin/grub-setup: info: the size of gentoo_10-root is 41943040.
/sbin/grub-setup: info: changing current directory to /dev.
/sbin/grub-setup: info: changing current directory to gentoo_10.
/sbin/grub-setup: info: changing current directory to md.
/sbin/grub-setup: info: changing current directory to snd.
/sbin/grub-setup: info: changing current directory to by-path.
/sbin/grub-setup: info: changing current directory to net.
/sbin/grub-setup: info: changing current directory to fedora_12.
/sbin/grub-setup: info: changing current directory to disk.
/sbin/grub-setup: info: changing current directory to by-label.
/sbin/grub-setup: info: changing current directory to by-uuid.
/sbin/grub-setup: info: changing current directory to by-path.
/sbin/grub-setup: info: changing current directory to by-id.
/sbin/grub-setup: info: changing current directory to raw.
/sbin/grub-setup: info: changing current directory to mapper.
/sbin/grub-setup: info: getting the size of /boot/grub/boot.img.
/sbin/grub-setup: info: reading /boot/grub/boot.img.
/sbin/grub-setup: info: getting the size of /boot/grub/boot.img.
/sbin/grub-setup: info: getting the size of /boot/grub/core.img.
/sbin/grub-setup: info: reading /boot/grub/core.img.
/sbin/grub-setup: info: getting the size of /boot/grub/core.img.
/sbin/grub-setup: info: the size of gentoo_10-root is 41943040.
/sbin/grub-setup: info: the size of /dev/sdd is 625142448.
/sbin/grub-setup: info: setting the root device to `gentoo_10-root'.
/sbin/grub-setup: info: dos partition is -1, bsd partition is -1.
/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless
disk.  This is a BAD idea..
/sbin/grub-setup: error: embedding is not possible, but this is
required when the root device is on a RAID array or LVM volume.
+ exit 1
---- end spew ----

All right, that was fun.  I popped open gdb and traced down the issue
to this, at line 781 in util/i386/pc/grub-setup.c:

---- begin code ----
  if (dest_dev[0] == 'm' && dest_dev[1] == 'd'
      && dest_dev[2] >= '0' && dest_dev[2] <= '9')
    {
      char **devicelist;
      int i;

      devicelist = grub_util_raid_getmembers (dest_dev);

      for (i = 0; devicelist[i]; i++)
        {
          setup (dir ? : DEFAULT_DIRECTORY,
                 boot_file ? : DEFAULT_BOOT_FILE,
                 core_file ? : DEFAULT_CORE_FILE,
                 root_dev, grub_util_get_grub_dev (devicelist[i]), 1, force, 
fs_probe);
        }
    }
---- end code ----

So there's the issue.  GRUB2 is assuming that destination devices of
the form /dev/md# must be Linux software RAID.  I'm inferring that the
way Linux software RAID is done, the MBR on each RAID member is not
actually RAIDed itself, so GRUB2 finds it necessary to install itself
to the MBR of each RAID member individually.  For fakeRAID setups,
which are normally handled through dmraid, it should be done as a
straight-up write to the RAID set, as the BIOS will present the set as
a simple "int 0x13" disk device on bootup, and GRUB2 doesn't actually
have to work software RAID magic to read the MBR in that case.  A
problem arises in Fedora 12 because this distro uses mdadm to handle
fakeRAID setups, instead of using dmraid.  So instead of creating a
device under /dev/mapper, fakeRAID devices also show up as /dev/md#
devices, which means GRUB2 thinks it's a Linux software RAID set, and
it tries to do the per-member MBR install.  This fails when GRUB2
tries to read the partition table on each member, as being RAIDed, the
MBR contents are invalid (being striped/parity-calculated/whatever).

At this point, I think the solution is a more robust detection of
whether the underlying destination device is a Linux software RAID
(i.e. mdadm raid), or a fakeRAID (i.e. dmraid) array.  Doing this by
just checking for "md#" isn't cutting it.

Is this evaluation correct?

Thanks,
-John Sheu