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;
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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.ne
** Branch linked: lp:~mathieu-tl/ubuntu/trusty/multipath-tools/usb+local
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1431650
Title:
Multipath devices take long to initialize during initramfs
To m
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 pa
** 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 b
@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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1431650
Title:
Multipath devices take long to initializ
@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
Bugs, which is subscribed to Ubuntu.
https
"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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.n
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 set
** Branch linked: lp:ubuntu/vivid-proposed/multipath-tools
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1431650
Title:
Multipath devices take long to initialize during initramfs
To manage notifica
> 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
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
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 "pa
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 writ
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-b
This looks like bug 1429327 ('multipath' runs *before* all disks show
up).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1431650
Title:
Multipath devices take long to initialize during initramfs
T
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
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
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
w
** Tags added: architecture-ppc64le bugnameltc-122821 severity-critical
targetmilestone-inin1504
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1431650
Title:
Multipath devices take long to initializ
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 notifica
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/multip
25 matches
Mail list logo