Bug#489850: multipath-tools-boot: fails to boot from a slow devices

[Guido Günther]

On Mon, Jul 28, 2008 at 09:39:25PM +0200, Janusz Dziemidowicz wrote:
> 2008/7/25 Guido Günther <agx at sigxcpu.org>:
> > On Fri, Jul 25, 2008 at 04:03:01AM +0200, Janusz Dziemidowicz wrote:
> > [..snip..]
> >> Unfortunately it does not work. /dev/mapper/wwid entry is not created.
> >> When I launch this manually from within initrd shell with -v2 I get:
> >> : failed to get sysfs information
> > Hmmm.weird - seems there's s.th. in multipath's sysfs code broken - I'll
> > check that once I have access to a MP system myself again. What about:
> 
> Maybe those would help:
> http://git.kernel.org/gitweb.cgi?p=linux/storage/multipath-tools/.git;a=commit;h=88f88d11ecee7d753e9b43d67001d58c56789eb1
> http://git.kernel.org/gitweb.cgi?p=linux/storage/multipath-tools/.git;a=commit;h=3aaecad682efef27ce6196c6d29db4cb93c9f2fb
> Didn't check it myself, will try next time I have some MP server for tests.
Yes, we should include these (intended to do so since quiet some time)
but not before the lenny release since this needs lots of testing. So
help with testing these would (of course) be welcome again.

> > This should hopefully do the trick. As a last resort:
> >
> > ACTION=="add", SUBSYSTEM=="block", RUN+="/sbin/multipath -v0 /dev/%k"
> >
> > should work too. Could you try that?
> 
> This works (although I see that the cleanest solution would be to use
> major:minor).
Thanks a lot for testing! I'll use this for lenny then. It's not as nice
as major:minor but the advantage is rather academic - having stable
multipath in lenny is more important. I just noticed that We also need
to care about change events:

ACTION=="add|change", SUBSYSTEM=="block", RUN+="/sbin/multipath -v0 /dev/%k"

> If I understand correctly, you want to get rid of
> /usr/share/initramfs-tools/scripts/local-top/multipath completely.
> I've tried to do that (with the /dev/%k trick) and it isn't so simple.
> There is a problem with loading dm-multipath module, it is not loaded
> automatically when needed, so /sbin/multipath fails if it was not
> loaded before udev event handlers from RUN were called. One solution
> was to add dm-multipath to /etc/initramfs-tools/modules, but I don't
> think it is the nicest way.
I meant /etc/init.d/multipath-tools-boot (doing the module loading in a
udev rule too). We can strip down
/usr/share/initramfs-tools/scripts/local-top/multipath then too.
But I'd say we go for a minimal fix for lenny and delay these things for
afterwards. 
Thanks again for you help,
 -- Guido