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)
This is verified OK in trusty-proposed.
None udev delays/lockups experienced when booting.
** Tags removed: verification-needed
** Tags added: verification-done
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to multipath-tools in
** Branch linked: lp:~mathieu-tl/ubuntu/trusty/multipath-tools/usb+local
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to multipath-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1431650
Title:
Multipath devices take long to
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
** Description changed:
+ [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
** Also affects: multipath-tools (Ubuntu Vivid)
Importance: Undecided
Status: New
** Also affects: multipath-tools (Ubuntu Trusty)
Importance: Undecided
Status: New
** Changed in: multipath-tools (Ubuntu Trusty)
Status: New = In Progress
** Changed in: multipath-tools
@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.
--
You received this bug notification
@mauricfo
Sorry for the late response. 31 paths are expected on mine and it takes
ages to boot.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to multipath-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1431650
Title:
Multipath
@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?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to
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 ?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to multipath-tools in Ubuntu.
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
** Branch linked: lp:ubuntu/vivid-proposed/multipath-tools
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to multipath-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1431650
Title:
Multipath devices take long to initialize during
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
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
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
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
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
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
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
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
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
This looks like bug 1429327 ('multipath' runs *before* all disks show
up).
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to multipath-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1431650
Title:
Multipath devices take long to
** Tags added: architecture-ppc64le bugnameltc-122821 severity-critical
targetmilestone-inin1504
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to multipath-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1431650
Title:
Multipath
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
--
You received this bug
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'
25 matches
Mail list logo
