grub-installer should also support setting up dmraid and multipath when
grub2 is selected.

clone 477090 -1
retitle -1 support for multipath
reassign -1 grub2
thanks

The attached patch should add support for multipath.  However, I can't
test it myself.

If someone can confirm it works, I'll get it applied in upstream.

Calling grub-mkdevicemap detects the mp devices and adds them to
/boot/grub/device.map - in this case /dev/mapper/mpath0 is added as
(hd4). However doing a:
grub-install --no-floppy --grub-setup=/bin/true "(hd4)"
(similar to what the postinst does) gives:

grub-probe: unknown device

The reason is that grub_util_get_grub_dev treats mp as LVM. I'll fix
this up but I'm unsure what grub_util_get_grub_dev is supposed to
return?
Cheers,
 -- Guido

grub_util_get_grub_dev() returns the corresponding GRUB drive for a given
Linux device.  This can be (hdX), (mdX) or (some-lvm-name).

The question here is how GRUB should treat your multipath device.  If it
is like any normal device, in that the BIOS will report it to GRUB as a
disk, you should arrange grub_util_get_dev_abstraction() to return
GRUB_DEV_ABSTRACTION_NONE.

If it's just an alias for an existing device, we'll probably have to
think this through.

And if it's something fancier like RAID or LVM, it'll take some work to
implement.

Ah, o.k. that's why there's LVM names and hdX mixed - I see now. So if
my device.map is:

(hd0) /dev/sda
(hd1) /dev/sdb
(hd2) /dev/mapper/mpath0

this should simply return (hd2)?
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.
/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).
Looking at the LVM code that's probably not necessary. I'll have another
stab at the code when I'm near some test hardware again next week.
Cheers,
 -- Guido

Yes, but ...

... then /dev/mapper/mpath0 doesn't belong in device.map.

So how is this different from software RAID-1?

O.k. So the device map only lists Bios/EFI devices?
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.
 -- Guido

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

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

retitle 483971 support for device-mapper multipath
thanks

Hello,

upstream has now added support for the `mdadm' multipath.
This report seems to be more for the device-mapper ones, so I just
retitle it.

found 483971 1.98+20100804-14
fixed 483971 1.99-12
thanks

grub2 1.99-12 (from sid) works fine, but I ran into this upgrading our
multipathed lenny machines to squeeze. Attached is the patch from #442382
that fixes this, updated for squeeze's grub2 (1.98+20100804-14).

FWIW, unmodified 1.98+20100804-14 on squeeze fails with:

[jwm@syslog01.roch.ny:pts/4 ~> sudo dpkg-reconfigure grub-pc
Generating core.img
/usr/sbin/grub-probe: error: no such disk.
Auto-detection of a filesystem of /dev/mapper/rootvol-part1 failed.
Please report this together with the output of "/usr/sbin/grub-probe --device-map=/boot/grub/device.map --target=fs -v /boot/grub" to <bug-grub@gnu.org>

john