Ubuntu
multipath-tools package

Device nodes for partitions on multipathed device are not created

Bug #320156 reported by Etienne Goyer
6
Affects Status Importance Assigned to Milestone
multipath-tools (Ubuntu)
Fix Released
High
Unassigned

Bug Description

Binary package hint: udev

I marked the bug as udev, although I am not 100% if it really falls under udev, kpartx or multipath-tools.

Device node for partition on multipathed block device are not created. The multipathed block device nodes appears just fine under /dev/mapper, just not the nodes for partition on them. For example, given a multipathed block device /dev/mapper/emc0, calling "sudo kpartx -a /dev/mapper/emc0" would create nodes such as /dev/mapper/emc0p1, /dev/mapper/emc0p2, etc, just fine. But they are not created automatically on boot

Tested on intrepid (8.10), not sure about other releases.

Revision history for this message
Etienne Goyer (etienne-goyer-outlands) wrote :

I believe it could be related to Debian bug #376161. I was fixed by implementing dmsetup_env, but dmsetup_env was later removed in a Ubuntu-specific upload by Soren in 0.4.8-10ubuntu1.

I noticed that the udev rules for both kpartx and multipath are run at 95. Could it be that the kpartx udev rule get invoked before the multipath block device appears?

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Confirming on jaunty. You can try changing the order, and rebuilding the initramfs to see if it matters. I believe I've tried that but it didn't help.

Changed in multipath-tools:
importance: Undecided → High
status: New → Confirmed
Revision history for this message
Soren Hansen (soren) wrote :

> I noticed that the udev rules for both kpartx and multipath are run at
> 95. Could it be that the kpartx udev rule get invoked before the
> multipath block device appears?

No, that's not how it works. Once the multipart block devices appear,
udev starts from the beginning again, applying rules to those devices.
E.g. devices that appear as a consequence of something in 99-foo.rules
still get the rules in 01-bar.rules applied as well.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

I've merged the latest version from debian, and included dmsetup_env again, and it seems to work here. I'll upload after testing a bit.

Changed in multipath-tools:
status: Confirmed → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package multipath-tools - 0.4.8-14ubuntu1

---------------
multipath-tools (0.4.8-14ubuntu1) jaunty; urgency=low

  * Merge from debian unstable, remaining changes:
    - control:
     + Bump debhelper dependency to install udev rules to
      /lib/udev/rules.d, bump udev dependencies as well.
     + multipath-udeb must not depend on multipath-modules,
      because the Ubuntu kernel already includes the modules and no
      package provides m-m.
    - initramfs/hooks: Install rules from /lib/udev/rules.d.
    - kpartx.udev, multipath-tools-boot.init:
      Replace multipath-tools-boot init script with udev rules.
    - multipath-tools.preinst: Fix preinst script to modprobe dm-multipath.
      This will make sure that multipathd will be able to start.
    - multipath-tools.prerm: Add prerm script to not fail when upgrading
      from a broken version of multipathd.
    - patches/1000--set-umask-in-multipathd.patch: Set umask in multipathd.
    - rules: Move udev rules to priority 95, because rules that load
      modules should be >90.
  * Fix bugs (LP: #316851, #320156)
  * multipath-tools.prerm/preinst: Remove checks for old ubuntu
    versions, we don't support upgrading from them anymore.

 -- Timo Aaltonen <email address hidden> Thu, 12 Feb 2009 15:07:42 +0200

Changed in multipath-tools:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.