Bug#483971: Fwd: Re: grub-installer: no support for dmraid and multipath for grub2

[Robert Millan]

On Tue, Jun 17, 2008 at 09:16:51AM +0200, Guido Günther wrote:
> On Mon, Jun 16, 2008 at 10:56:06PM +0200, Robert Millan wrote:
> > > No. The bios doesn't now anything about the multipathing. It sees a
> > > number of identical scsi devices sda[a-d] while Linux multipaths this to
> > > /dev/mapper/mpath0.
> > 
> > ... then /dev/mapper/mpath0 doesn't belong in device.map.
> O.k. So the device map only lists Bios/EFI devices?

It lists BIOS devices.  For the other platforms, it also has support for
Ieee1275 devices, but in general they're just dummy placeholders.

> > > > If it's just an alias for an existing device, we'll probably have to
> > > > think this through.
> > > /dev/mapper/mpath0 is kind of an alias for the underlying paths (e.g.
> > > /dev/sda[a-d]). So whenever grub wants to access /dev/sd? it should
> > > access the /dev/mapper/mpathX instead. Does this qualify as an alias?
> > > There are two ways to find out which /dev/sd? build up the multipath
> > > device: Looking at the multipath -l output or looking at the dm map
> > > (like I've implemented it in parted).
> > 
> > So how is this different from software RAID-1?
> I think it doesn't differ that much - this is why we could reuse most of
> the grub-installer code for grub1. The basic poinst is that we need grub
> to write the MBR onto /dev/mapper/mpathX and that the partitions are
> /dev/mapper/mapthX-partY instead of /dev/sdaY. 
> This is a bit of a special case but sufficient for the installer.

A proper fix belongs in GRUB, not grub-installer.  Please don't add hacks
there to workaround GRUB limitations.

I think I have enough info to sort this out now;  I'll give this a try,
maybe tomorrow, and come back with a patch for you to test.

Thanks

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)