Multipath devices take long to initialize during initramfs

Bug #1431650 reported by Mauricio Faria de Oliveira on 2015-03-13
40
This bug affects 5 people
Affects Status Importance Assigned to Milestone
multipath-tools (Ubuntu)
High
Mathieu Trudel-Lapierre
Trusty
High
Mathieu Trudel-Lapierre

Bug Description

[Impact]
Impacts any user of multipath, regardless of release. Users who do not currently see issues may see them on upgrade to a newer version of systemd/udev.

[Test case]
See below. Test case can be summarized as "boot on a multipath system".

[Regression potential]
This changes the behavior on locking devices for multipath, to avoid a deadlock with udev. Since this changes the locking behavior of multipath this may also affect other scripts or applications depending on multipath doing an exclusive lock, so scripts or applications could fail because they acquired a lock on the devices prematurely, before multipath was finished. In most cases this shouldn't happen, as it should be limited to an isolated multipath step in the boot process (in initramfs).

---

Problem: during initramfs, multipath devices takes long to initialize (~30 seconds?)

Symptom:
 <...>
 Loading, please wait...
 <...>
 [ 4.492303] device-mapper: multipath: version 1.7.0 loaded
 [ 4.643053] random: nonblocking pool is initialized
 worker [116] /devices/vio/71000002/host0/target0:0:0/0:0:0:0/block/sda is taking a long time
 worker [117] /devices/vio/71000002/host0/target0:0:2/0:0:2:0/block/sdc is taking a long time
 worker [121] /devices/vio/71000002/host0/target0:0:1/0:0:1:0/block/sdb is taking a long time
 worker [123] /devices/vio/71000002/host0/target0:0:3/0:0:3:0/block/sdd is taking a long time
 <... here's the delay ...>
 timeout '/sbin/multipath -v0 /dev/sda'
 slow: '/sbin/multipath -v0 /dev/sda' [181]
 timeout '/sbin/multipath -v0 /dev/sdb'
 slow: '/sbin/multipath -v0 /dev/sdb' [178]
 timeout '/sbin/multipath -v0 /dev/sdc'
 slow: '/sbin/multipath -v0 /dev/sdc' [180]
 timeout '/sbin/multipath -v0 /dev/sdd'
 slow: '/sbin/multipath -v0 /dev/sdd' [182]
 worker [116] /devices/vio/71000002/host0/target0:0:0/0:0:0:0/block/sda timeout; kill it
 seq 1059 '/devices/vio/71000002/host0/target0:0:0/0:0:0:0/block/sda' killed
 worker [117] /devices/vio/71000002/host0/target0:0:2/0:0:2:0/block/sdc timeout; kill it
 seq 1079 '/devices/vio/71000002/host0/target0:0:2/0:0:2:0/block/sdc' killed
 worker [121] /devices/vio/71000002/host0/target0:0:1/0:0:1:0/block/sdb timeout; kill it
 seq 1069 '/devices/vio/71000002/host0/target0:0:1/0:0:1:0/block/sdb' killed
 worker [123] /devices/vio/71000002/host0/target0:0:3/0:0:3:0/block/sdd timeout; kill it
 seq 1089 '/devices/vio/71000002/host0/target0:0:3/0:0:3:0/block/sdd' killed
 worker [116] terminated by signal 9 (Killed)
 worker [117] terminated by signal 9 (Killed)
 worker [121] terminated by signal 9 (Killed)
 worker [123] terminated by signal 9 (Killed)
 <...>
 <login prompt>

Reason:
 When udev starts to handle the block device, it acquires a lock on it, then processes the rules.
 Therefore, by the time 'multipath' runs (called in udev rules), the block device is already locked.

 For 'multipath' to finish, it must acquire a *exclusive* lock on the block device.
 Thus it fails (exclusive mode doesn't succeed with another lock in place).

 So it loops, trying again until the lock is acquired.
 (messages: "failed to create map (in use)" / "restart multipath configuration process").

 Sure enough, it will keep looping.. until killed by time-out (message: "timeout '/sbin/multipath -v0 /dev/sda'").

 Only then (after rule-processing) udev releases the lock.

 The next call to the 'multipath' command succeeds (out of udev rules, in /scripts/local-top/multipath).
 This happens because, by that time, udev has finished handling all devices (i.e., 'udev settle' in /scripts/init-bottom/udev, which is run earlier),
 so there's no more the udev worker lock to the underlying block device(s).

Steps to reproduce:
 Do a multipath install (disk-detect/multipath/enable=true), and boot.

Solution:

 left as an exercise for the reader :)

 I guess the udev 95-multipath.rules shouldn't be in the initramfs.
 (i.e., add_udev_rules() in /usr/share/initramfs-tools/hooks from
  multipath-tools-boot)

 Booting on multipath devices would still be possible because there's
 another call to 'multipath' on initramfs/scripts/local-top/multipath,
 before mounting root.

 Not sure about the behavior during system operation; e.g., hotplug
 a new disk.. the multipath command would be called from the udev rule
 in the root filesystem now (i.e., /lib/udev/rules.d/ from rootfs, not
 initramfs). I'm now sure of how multipathd is related to that now.

Analysis:

 Checking out why '/sbin/multipath -v0 /dev/sda' is timing out.

 Boot with:
  break=top,pre-multipath,post-multipath

  <...>
  Spawning shell within the initramfs
  <...>
  (initramfs)

 Increase verbosity on multipath and udevd, and show udevd
 And, to save time/output, reduce the udev timeout, and restrict that command
 to only a single disk (e.g., sda).

  udevd:

  (initramfs) grep udevd /scripts/init-top/udev
  /lib/systemd/systemd-udevd --daemon --resolve-names=never

  (initramfs) sed '/systemd-udevd/ { s:--daemon:--debug --event-timeout=5: ; s:$: 2>\&1 \&: }' -i /scripts/init-top/udev

  (initramfs) grep udevd /scripts/init-top/udev
  /lib/systemd/systemd-udevd --debug --event-timeout=5 --resolve-names=never 2>&1 &

  multipath:

  (initramfs) grep -F 'multipath -v' /lib/udev/rules.d/95-multipath.rules
  ACTION=="add|change", SUBSYSTEM=="block", RUN+="/sbin/multipath -v0 /dev/$name"

  (initramfs) sed '/multipath -v/ { s:-v0:-v3: ; s:^:KERNEL=="sda", : }' -i /lib/udev/rules.d/95-multipath.rules

  (initramfs) grep -F 'multipath -v' /lib/udev/rules.d/95-multipath.rules
  KERNEL=="sda", ACTION=="add|change", SUBSYSTEM=="block", RUN+="/sbin/multipath -v3 /dev/$name"

 Let initramfs continue:

  (initramfs) exit

 The udevd output rolls out.
 The output of the multipath command is looping. Looking closer, it's always
 restarting the multipath configuration process. At the end of each iteration
 (it's looping..), there is this block:

  '/sbin/multipath -v3 /dev/sda'(out) 'Mar 12 13:44:48 | mpath0: set ACT_CREATE (map does not exist)'
  '/sbin/multipath -v3 /dev/sda'(out) 'Mar 12 13:44:48 | mpath0: failed to create map (in use)'
  '/sbin/multipath -v3 /dev/sda'(out) 'Mar 12 13:44:48 | mpath0: domap (4294967295) failure for create/reload map'
  '/sbin/multipath -v3 /dev/sda'(out) 'Mar 12 13:44:48 | restart multipath configuration process'

 Searching multipath-tools source package for what causes that error message "failed to create map (in use)".

  # apt-get source multipath-tools
  # cd multipath-tools-*
  # grep -r 'failed to create map (in use)' .
  ./libmultipath/configure.c: condlog(3, "%s: failed to create map (in use)",

 And there it is, in domap() (also mentioned in the error):

  extern int
  domap (struct multipath * mpp)
  {
  ...
   case ACT_CREATE:
    if (lock_multipath(mpp, 1)) {
            condlog(3, "%s: failed to create map (in use)",
                    mpp->alias);
            return DOMAP_RETRY;
    }

 The error thus comes from lock_multipath(), in the same file:

  static int
  lock_multipath (struct multipath * mpp, int lock)
  {
  ...
            if (lock && flock(pp->fd, LOCK_EX | LOCK_NB) &&
                errno == EWOULDBLOCK)
                    return 1;

 So, basically, it's trying to lock a file w/ exclusive access flock(fd, LOCK_EX).

 To check what file is that, on another system, which is booted already, let's use strace:

  # strace -f strace.multipath multipath -v0 /dev/sda
  <...>
  26362 open("/dev/sda", O_RDONLY) = 5
  <...>
  26362 flock(5, LOCK_EX|LOCK_NB) = 0
  <...>

 OK; it tries to lock the same device that is passed as argument.

 In order to discover the owner of the lock in the initramfs... hm..
 there's no lsof or something.

 Let's use a script to check every process's open files
 (if a file is locked, it must be open; e.g., flock operates on an open file descriptor).

 Reboot to that point again, in the initramfs (i.e., break=..., sed ...; NOT exit).

  break=top,pre-multipath,post-multipath
  (initramfs) sed '/systemd-udevd/ { s:--daemon:--debug --event-timeout=5: ; s:$: 2>\&1 \&: }' -i /scripts/init-top/udev
  (initramfs) sed '/multipath -v/ { s:-v0:-v3: ; s:^:KERNEL=="sda", : }' -i /lib/udev/rules.d/95-multipath.rules

 But now *REPLACE* the multipath command to a script which searches for an
 open fd for the device specified (expect sda, per the restriction inserted),
 and list some details of the owning process.

 note: we replace (not append) just to avoid the flock from multipath,
       for not to confuse us.

  (initramfs) sed 's:/sbin/multipath -v. /dev/:/find.sh :' -i /lib/udev/rules.d/95-multipath.rules
  (initramfs) grep -F 'find.sh' /lib/udev/rules.d/95-multipath.rules
  KERNEL=="sda", ACTION=="add|change", SUBSYSTEM=="block", RUN+="/find.sh $name"

  (initramfs) cat <<EOF >/find.sh
  #!/bin/sh
  #set -x
  for dir in /proc/*
  do
      [ -d "\$dir/fd" ] || continue
      ls -l \$dir/fd | grep -q \$1 || continue

      echo "FD FOUND"
      echo "process: \$dir"
      ls -l \$dir/exe
      echo "cmdline: \$(cat \$dir/cmdline | tr '\0' ' ')"
      echo "file descriptors:"
      ls -l \$dir/fd
  done
  EOF

 OK; let's go for udev.

 (initramfs) exit

 Lots of udev output..
 Searching back for the scripts' output (find.sh).. Tip: use 'screen'.

 Got it.
 The lock is from udevd.
 See fd 6.

  <...>
  '/find.sh sda'(out) 'FD FOUND'
  '/find.sh sda'(out) 'process: /proc/369'
  '/find.sh sda'(out) 'lrwxrwxrwx 1 0 /proc/369/exe -> /lib/systemd/systemd-udevd'
  '/find.sh sda'(out) 'cmdline: /lib/systemd/systemd-udevd --debug --event-timeout=5 --resolve-names=never '
  '/find.sh sda'(out) 'file descriptors:'
  '/find.sh sda'(out) 'lr-x------ 1 64 11 -> pipe:[8569]'
  '/find.sh sda'(out) 'lrwx------ 1 64 10 -> socket:[8352]'
  '/find.sh sda'(out) 'lrwx------ 1 64 9 -> anon_inode:[eventpoll]'
  '/find.sh sda'(out) 'lrwx------ 1 64 8 -> socket:[8351]'
  '/find.sh sda'(out) 'lr-x------ 1 64 7 -> pipe:[8568]'
  '/find.sh sda'(out) 'lr-x------ 1 64 6 -> /dev/sda'
  '/find.sh sda'(out) 'lr-x------ 1 64 5 -> anon_inode:inotify'
  '/find.sh sda'(out) 'lrwx------ 1 64 4 -> anon_inode:[eventpoll]'
  '/find.sh sda'(out) 'lrwx------ 1 64 3 -> anon_inode:[signalfd]'
  '/find.sh sda'(out) 'lrwx------ 1 64 2 -> /dev/console'
  '/find.sh sda'(out) 'lrwx------ 1 64 1 -> /dev/console'
  '/find.sh sda'(out) 'lr-x------ 1 64 0 -> /dev/null'
  '/find.sh sda' [422] exit with return code 0

 And if you search backwards for that PID, it reaches the fork of a udev worker:

  seq 873 forked new worker [369]

 Looking at udevd code for a worker:

  # apt-get source systemd
  # cd systemd-*
  # grep -r worker .
    hmm.. udevd.c.. ah, "worker_new".. looking.

  static void worker_new(struct event *event) {
   <...>
    fd_lock = open(udev_device_get_devnode(d), O_RDONLY|O_CLOEXEC|O_NOFOLLOW|O_NONBLOCK);
    if (fd_lock >= 0 && flock(fd_lock, LOCK_SH|LOCK_NB) < 0) {
   <...>

           /* apply rules, create node, symlinks */
           udev_event_execute_rules(udev_event,
   <...>
           safe_close(fd_lock);
  }

 And there's a very meaningful comment above it:

                /*
                 * Take a shared lock on the device node; this establishes
                 * a concept of device "ownership" to serialize device
                 * access. External processes holding an exclusive lock will
                 * cause udev to skip the event handling; in the case udev
                 * acquired the lock, the external process can block until
                 * udev has finished its event handling.
                 */

 Specially:

  in the case udev
                 * acquired the lock, the external process can block until
                 * udev has finished its event handling.

 AH.
 So, that explains it all.

 See:
 1) udevd/worker acquires a lock of the block device (shared access),
 2) process the udev rules (e.g., 95-multipath.rules)
 3) *afterwards*, release the lock.

 So, the 'multipath' command that is run inside the udev rule
 that handles the add event of a block device (e.g., sda),
 will never finish (will keep looping until killed by timeout),
 because it requires an exclusive lock of that device..

 however, that device already has a lock in place (locked by
 udev worker before rule processing), which will only be
 released after the rule processing (after multipath ends.)

The work-around in use:

  Remove the multipath udev rules from the initramfs.
  Note: this doesn't remove multipath support from it; there's more in there.
            Boot from multipath devices works normally (and faster :-)

 $ grep 'for rules in' /usr/share/initramfs-tools/hooks/multipath
   for rules in 95-multipath.rules; do

 $ sudo sed '/for rules in/ s:95-multipath.rules::' -i /usr/share/initramfs-tools/hooks/multipath

 $ grep 'for rules in' /usr/share/initramfs-tools/hooks/multipath
   for rules in ; do

 $ sudo update-initramfs -u
 update-initramfs: Generating /boot/initrd.img-3.19.0-7-generic

 $ sudo reboot

FYI, this doesn't affect Trusty nor Utopic.

That udev code lock code was introduced in 2014-04-14:

  systemd commit 3ebdb81ef088afd3b4c72b516beb5610f8c93a0d [1]

[1] http://cgit.freedesktop.org/systemd/systemd/commit/?id=3ebdb81ef088afd3b4c72b516beb5610f8c93a0d

bugproxy (bugproxy) on 2015-03-16
tags: added: architecture-ppc64le bugnameltc-122821 severity-critical targetmilestone-inin1504

------- Comment From <email address hidden> 2015-03-16 17:31 EDT-------
*** Bug 121787 has been marked as a duplicate of this bug. ***

bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2015-03-16 18:08 EDT-------
*** Bug 122793 has been marked as a duplicate of this bug. ***

bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2015-03-17 17:11 EDT-------
*** Bug 122793 has been marked as a duplicate of this bug. ***

The workaround seems good, but there still tends to be issues bringing up the multipath devices on boot with QEMU in my testing; just the workaround isn't always sufficient: break=pre-multipath then resuming helps out there.

I think this all goes back to multipath-tools updates that would help a whole lot; but they may be a little too intrusive past feature freeze -- I'm looking into just updating the udev rules now.

Changed in multipath-tools (Ubuntu):
status: New → In Progress
importance: Undecided → Medium
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
importance: Medium → High

Hi Mathieu,

> The workaround seems good, but there still tends to be issues bringing up
> the multipath devices on boot with QEMU in my testing; just the workaround
> isn't always sufficient: break=pre-multipath then resuming helps out there.

May you describe the issues you're seeing?
I guess I have hit more than a few so far.

Specifically, check bug 1429327 ('multipath' runs *before* all disks show up), and bug 1432062 (udev rules fail w/ disk-names w/ spaces when user_friendly_names isn't set).

I see delays in the devices being detected, which means after running through the initramfs scripts and other startup scripts, the installed system will come up using /dev/sdb1 (for example) rather than the equivalent device mapper device, and no swap.

If you can point me to the bug you filed that better matches this, I can fix it first before taking on the other reports.

This looks like bug 1429327 ('multipath' runs *before* all disks show up).

This commit should fix this bug, and probably bug 1429327 as well.
   https://github.com/hreinecke/multipath-tools/commit/841977fc9c3432702c296d6239e4a54291a6007a

It should allow multipath to be run in udev rules w/out timeout/killing (fixes this bug),
and thus restore the functioning of event-based multipath discovery
(which should fix bug 1429327, as the SCSI disks found after initramfs/local-top/multipath
should be found during the wait-for-root call in initramfs/local).

It just happens not to be upstream yet, and maybe not reviewed.
I'll take a look at it tomorrow.

Hi Mathieu,

I did some research for the commit mentioned in comment #10.

Its description clarifies (how/why) it solves this problem, and even others we would probably hit later (e.g., after booting, SCSI disks added/removed re-trigerring udev rules, and then involving multipathd).

It's been written by a multipath/enterprise hardware guy for the suse distros.
I see it in opensuse [1], with a patch named after 'sles12', which also names the branch in his github repo [2].

It looks good to go, combined with another fix applied to the initramfs script (the udev settle thing we talked about, but on a slightly different place). Patch attached.

With it applied, the udev timeout/killing disappears as expected, and with the earlier 'udevadm settle' call in place, so disappears the random dm ioctl() failures (race condition w/ multipath in udev rules):

    device-mapper: create ioctl on mpathX-partY failed: Device or resource busy
    create/reload failed on mpathX-partY

In summary, the attached patch restores event-based multipath discovery.. and we no longer need to remove the 95-multipath.rules from initramfs.

Links:
    [1] https://build.opensuse.org/package/revisions/openSUSE:Factory/multipath-tools
    [2] https://github.com/hreinecke/multipath-tools/tree/sles12

Updated replies to earlier comments:

comment #6
> I think this all goes back to multipath-tools updates that would help a whole lot; but they may be a little too intrusive past feature freeze -- I'm looking into just updating the udev rules now.

Just to clarify/respond to that (earlier than patch) comment with regards to the patch attached.

Given that the patch introduces only 2 changes, which are minimal/small (and one may sometimes be a nop), and is totally contained in multipath stuff, I think it'd be OK to get it in.
(Very respectfully,) it should not make multipath less functional than it is now. :) And can't break non-multipath stuff.

comment #8
> the installed system will come up using /dev/sdb1 (for example) rather than the equivalent device mapper device,

The patch should help* with that issue (described in bug 1429327 comment #10), because the multipath disks now may* show up before the wait-for-root call.. but a proper fix should probably follow the discussion in there. I'll try to get something addressing this too, according to Steve's suggestion.

> [...] and no swap.

This one should be fixed w/ 1430074.
The /etc/fstab file used to have the incorrect/p separator for the swap device too, so it wasn't found/timed out.

The attachment "multipath-tools_shared-lock.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

tags: added: patch

Well, not necessarily. The swap issue is the same as the rootfs one-- at some point multipath times out, and other init jobs would also timeout trying to bring up the swap (which can't be identified from the UUID) whereas the rootfs got brought up on a single path using the UUID.

The debdiff looks quite good; I'll add in the removal of scsi_wait_device which is just useless (that module no longer exists).

> Well, not necessarily. The swap issue is the same as the rootfs one

Ah, yes, you're right.

I was thinking with the assumption that the workaround/patch for the timeout was in place.
Indeed, if it's not in place, there'll be no swap nor anything multipath'ed at all.

In the particular case the workaround/patch is applied, what I've seen is a job waiting/timing out for the swap device (now) incorrectly specified in /etc/fstab.

Thanks for pointing that out.

> The debdiff looks quite good; I'll add in the removal of scsi_wait_device which is just useless (that module no longer exists).

Cool :) thanks!

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package multipath-tools - 0.4.9-3ubuntu11

---------------
multipath-tools (0.4.9-3ubuntu11) vivid; urgency=medium

  [ Mauricio Faria de Oliveira ]
  * Added debian/patches/0015-shared-lock-for-udev.patch (LP: #1431650)
  * debian/initramfs/local-top: wait for udev to settle before running
    'multipath' in order to avoid race condition on device-mapper calls.

  [ Mathieu Trudel-Lapierre ]
  * Drop scsi_wait_scan from the multipath initramfs script: that module
    no longer exists.
 -- Mathieu Trudel-Lapierre <email address hidden> Mon, 23 Mar 2015 14:56:37 -0400

Changed in multipath-tools (Ubuntu):
status: In Progress → Fix Released
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2015-03-24 12:30 EDT-------
Thanks, Mathieu.
I just re-tested w/ the fix-released packages; all fine!

------- Comment From <email address hidden> 2015-03-26 13:29 EDT-------
*** Bug 122060 has been marked as a duplicate of this bug. ***

Alexandre Anoutchine (xirius) wrote :

"This bug was fixed in the package multipath-tools - 0.4.9-3ubuntu11"

I have 0.4.9-3ubuntu12 but it still occurs to me. 5 minutes boot time :(
So how to fix it ?

@xirius

I'm debugging a similar issue that happens w/ hundreds of paths.
They're so many that the boot just takes a really long time.

How many paths are expected on your scenario?

Alexandre Anoutchine (xirius) wrote :

@mauricfo

Sorry for the late response. 31 paths are expected on mine and it takes ages to boot.

@xirius

Well, I guess that's a different problem.
Sorry, I can't help w/ debugging that, but I'd suggest you to track/compare boot times w/ a increasing number of paths, or from different adapters/storage systems, until you rule out the slow-down factor.

Changed in multipath-tools (Ubuntu Trusty):
status: New → In Progress
Changed in multipath-tools (Ubuntu Vivid):
status: New → In Progress
Changed in multipath-tools (Ubuntu Trusty):
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
Changed in multipath-tools (Ubuntu Vivid):
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
Changed in multipath-tools (Ubuntu Trusty):
importance: Undecided → High
Changed in multipath-tools (Ubuntu Vivid):
importance: Undecided → High
description: updated
no longer affects: multipath-tools (Ubuntu Vivid)

Hello Mauricio, or anyone else affected,

Accepted multipath-tools into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/multipath-tools/0.4.9-3ubuntu7.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in multipath-tools (Ubuntu Trusty):
status: In Progress → Fix Committed
tags: added: verification-needed
Adam Conrad (adconrad) wrote :

Hello Mauricio, or anyone else affected,

Accepted multipath-tools into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/multipath-tools/0.4.9-3ubuntu7.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

This is verified OK in trusty-proposed.
None udev delays/lockups experienced when booting.

tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package multipath-tools - 0.4.9-3ubuntu7.4

---------------
multipath-tools (0.4.9-3ubuntu7.4) trusty; urgency=medium

  * Remove 0024-ignore-usb.patch: Ignore USB devices. Verification fails
    for this fix; it needs more work.

multipath-tools (0.4.9-3ubuntu7.3) trusty; urgency=medium

  * Added debian/patches/0015-shared-lock-for-udev.patch (LP: #1431650)
  * Support disks with non 512-byte sectors (LP: #1441930)
  * Correctly write FC timeout attributes to sysfs. (LP: #1435706)
  * Ignore USB devices. (LP: #1468897)

 -- Mathieu Trudel-Lapierre <email address hidden> Mon, 27 Jul 2015 13:48:39 -0400

Changed in multipath-tools (Ubuntu Trusty):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for multipath-tools has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers