I encoured same issue on Ubuntu 18.04 kernel 5.1.0-rc.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/802626
Title:
vgchange may deadlock in initramfs when VG present that's not used for
rootfs
I believe I may have this issue after upgrade to 16.04.
- root=/dev/mapper/MyLV-Linux locks up and halts after "Begin: Running
/scripts/local-top". Debugging described below makes me think this is actually
inside /scripts/local-top/lvm2.
- Removing root= drops me into (initramfs) and lets me do
Can anyone give me an idea of when I can expect this fix to be available
for Oneiric without using proposed?
Thanks.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/802626
Title:
vgchange may
This bug was fixed in the package udev - 173-0ubuntu4.2
---
udev (173-0ubuntu4.2) oneiric-proposed; urgency=low
* Add debian/patches/avoid-exit-deadlock-for-dm_cookie.patch,
debian/libudev0.symbols: do not exit across a pending DM_COOKIE
event to avoid vgchange deadlocks,
** Branch linked: lp:ubuntu/oneiric-proposed/udev
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/802626
Title:
vgchange may deadlock in initramfs when VG present that's not used for
rootfs
To
Tested (from oneiric-proposed) in four machines suffering from the
problem (one which wouldn't boot at all and where I'd used the
--noudevsync hack before, three which hang for an extra minute until
watershed timeout): problem gone, all boot perfectly (and quickly) now.
No adverse effects
** Changed in: udev (Ubuntu Oneiric)
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/802626
Title:
vgchange may deadlock in initramfs when VG present
** Changed in: udev (Ubuntu Oneiric)
Status: Fix Released = Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/802626
Title:
vgchange may deadlock in initramfs when VG present
Hello Sébastien, or anyone else affected,
Accepted into oneiric-proposed. The package will build now and be
available in a few hours. Please test and give feedback here. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed. Thank you in advance!
**
I have no more this tedious 60 seconds waiting at
udevadm control --timeout=121 --exit
in
/scripts/init-bottom/udev
after the today oneiric-proposed update of a Dell Latitude E6520 using lvm2.
Kind thanks.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
** 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.net/bugs/802626
Title:
vgchange may deadlock in initramfs when VG present that's not used for
rootfs
To manage notifications
hello,
Can we expect to have a package showing up in oneirci-proposed ?
Thanks
Marc
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/802626
Title:
vgchange may deadlock in initramfs when VG present
On Wed, Mar 07, 2012 at 05:54:09PM -, Marc Gariépy wrote:
Can we expect to have a package showing up in oneirci-proposed ?
Sorry, thought I'd uploaded this already. It's in the queue now, waiting
for SRU team approval.
--
You received this bug notification because you are a member of
This bug was fixed in the package udev - 175-0ubuntu6
---
udev (175-0ubuntu6) precise; urgency=low
* Add debian/patches/avoid-exit-deadlock-for-dm_cookie.patch,
debian/libudev0.symbols: do not exit across a pending DM_COOKIE
event to avoid vgchange deadlocks, thanks to
my understanding is that the udev upload comprises a complete fix, and
no further changes are needed to lvm2.
** Changed in: lvm2 (Ubuntu Precise)
Status: Triaged = Invalid
** Changed in: lvm2 (Ubuntu Oneiric)
Status: Triaged = Invalid
** Changed in: udev (Ubuntu Oneiric)
** Branch linked: lp:~ubuntu-core-dev/ubuntu/precise/udev/ubuntu
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/802626
Title:
vgchange may deadlock in initramfs when VG present that's not used for
** Branch linked: lp:ubuntu/udev
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/802626
Title:
vgchange may deadlock in initramfs when VG present that's not used for
rootfs
To manage notifications
** Branch linked: lp:~ubuntu-core-dev/ubuntu/oneiric/udev/ubuntu
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/802626
Title:
vgchange may deadlock in initramfs when VG present that's not used for
** Also affects: lvm2 (Ubuntu Precise)
Importance: High
Assignee: Steve Langasek (vorlon)
Status: Triaged
** Also affects: udev (Ubuntu Precise)
Importance: High
Status: Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
So, I spent some time looking at herton's fix, and I think it's correct.
While using --noudevsync looks tempting, is does trigger some new races
since now both udev and lvm are trying to do things like renaming device
nodes. Watershed isn't a problem -- DM_COOKIE is passed separately via
dmsetup
udev test package for precise here:
https://launchpad.net/~kees/+archive/ppa/+packages
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/802626
Title:
vgchange may deadlock in initramfs when VG present
** Tags added: precise
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/802626
Title:
vgchange may deadlock in initramfs when VG present that's not used for
rootfs
To manage notifications about
I recently started experiencing the stale lvm vgchange process issue.
After applying the patch from #53, it's no longer the case: no more
timeouts during boot, no more stale process.
Note that I have a single VG composed of a single PV, and several LVs in
the VG, one of which being my rootfs.
My system is also affected. I applied the patch in comment #53 and all
is well again. Thanks!
** Attachment added: dmesg output from my system
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/802626/+attachment/2762208/+files/bootlog.gz
--
You received this bug notification because you
@Herton: Great job. Patch from comment 53 fixes the problem for me.
@Steve: Please ship ASAP. I can help with testing, if need be.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/802626
Title:
I also reproduced the issue here, after being pointed out that some
people started seeing frequently this with the 3.0.0-14 kernel stable
update in Oneiric.
After debugging, I reached same conclusions as posted here. It's a
deadlock between vgchange and udev exiting: vgchange after the resume
dm
The patch applies on top of udev 173-0ubuntu4.1 (and introduces a new
symbol, which must be taken care when building the udev package).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/802626
Title:
I'm seeing the same issue on Precise, with a non-root LVM disk: a
60-second delay in the boot process, while scripts/init-bottom/udev is
waiting for the `udevadm control --exit` process to finish, which is in
turn waiting for the `watershed vgscan; vgchange` RUN command.
When run under watershed,
As yet another person affected with this bug, I would like to add that
the '--noudevsync workaround' does not really remove the timeout, it
drastically decreases it. On my system (Acer 4820TG) the timeout of
16..25 seconds still exists (although not the original 80 seconds I've
seen with
Patch suggested by Wessel in comment #21 completely solved this problem
for me (without patch issue was reproducible almost in 100% of system
boots).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Tags added: kernel-key
** Tags added: kernel-da-key
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/802626
Title:
vgchange may deadlock in initramfs when VG present that's not used for
rootfs
It sounds like there are two separate bugs then:
1) lvm waits for udev, which waits for lvm - circular dependency
deadlock
2) watershed eats the DM_COOKIE causing the semaphore to not be
released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Hi,
#596554 could be a possible duplicate of this bug.
yours,
Steffen
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/802626
Title:
vgchange may deadlock in initramfs when VG present that's not
As mentioned, the long delay at boot is definitely experienced by users
including me that have their root fs on LVM. The --no-udevsync
workaround fixes the issue that apparently started with the update to
3.00-14. Personally, I suspect that some problem was present even
before 3.00-14 but
Possible dups: bug 906358 and bug 631795
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/802626
Title:
vgchange may deadlock in initramfs when VG present that's not used for
rootfs
To manage
James,
I don't believe that's true. If the rootfs is in the same VG, there
should be no possibility of udev being stopped in the initramfs prior to
the dependent event making its way through the system, because without
those events the rootfs can't be mounted at all. And certainly, root-
on-LVM
Steve,
Several corresponding root-in-lvm lvm-udev timeout/deadlock bugs have been
placed (including bug #902491, bug #912876, bug #909805), but all - at least
superficially - appear to be as a result of the same udev/lvm deadlock as this
bug, and all are fixed (or at least ameliorated) by the
I have a VM running fully-updated precise (as of today precise-generic
3.2.0-9 - presumably including the fix for #818177?), with the entire
file-system in lvm, which requires the --noudevsync fix to prevent a
60 second boot-delay.
I also have...
- Beige-box running oneiric-server with entire fs
I also am experiencing the 60 second delay on startup with -14 and not
with -13. According to the Ubuntu to Mainline map, 3.0.0-13.22 maps to
3.0.6 and 3.0.0-14.23 maps to 3.0.9. I bisected the commits over that
range and determined that reverting the following commit corrects this
issue:
Had some time over x-mas. Adding --noudevsync fixes it for me. 5
consecutive reboots all worked.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/802626
Title:
vgchange may deadlock in initramfs when
Serge, I've got the stock lvm2 package. So if that --noudevsync is in the stock
package, then yes, it usually fails.
The lvm2 is 2.02.66-4ubuntu3.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/802626
janevert - are you saying that with the --noudevsync you get one
vgchange not executed at all (until you force it by hand)?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/802626
Title:
vgchange may
A me too.
I have /var and /home on two lvm partitions. /home only needs one of the two
partitions, /var was recently extended and now needs both. It fails in most
boots, more than 9 out of 10.
The comment from #34 also applies for me, no problem with the 3.0.0-13
kernel.
The thing I can add is
Just a short note to mention that the slow boot also affects 3.2RC4 from
the mainline ppa
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/802626
Title:
vgchange may deadlock in initramfs when VG
Experiencing this hang on a DELL E6500 where I am using LVM, after
ubuntu pushed the 3.0.0-14 kernel, the -13 kernel did not have the
issue.
But I do have the root filesystem on LVM. So the problem seems to be
there even if rootfs is on a logical LVM volume.
The --noudevsync in udev lvm2 rules
BTW, is it OK and safe to keep the --noudevsync in the udev lvm2 rule?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/802626
Title:
vgchange may deadlock in initramfs when VG present that's not used
I ran across this bug this morning after installing 11.10. I can say the
patch above worked for me as well.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/802626
Title:
vgchange may deadlock in
Im having this problem too.
My laptop has / in sda2 and /home and other partition in LVM
Using last update, boot very slow, hang after init-bottom printed for 1 minute,
then boot normally
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
I've not had the problem since starting to use the linked bzr tree.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/802626
Title:
vgchange may deadlock in initramfs when VG present that's not used
Is this bug fixed or still an issue ?! I'm having serious problems with
this and using a linux-image 2.6.32.x works totally fine..
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/802626
Title:
seems, this patch cure the issue, in my case
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/802626
Title:
vgchange may deadlock in initramfs when VG present that's not used for
rootfs
To manage
** Branch linked: lp:~serge-hallyn/ubuntu/precise/lvm2/fix-udev-wait
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/802626
Title:
vgchange may deadlock in initramfs when VG present that's not used
I'm trying out this debdiff on my laptop. Mr statistics-averse says:
so far so good.
** Patch added: debdiff making lvm in udev rules not wait on udev
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/802626/+attachment/2598337/+files/lvm.debdiff
--
You received this bug notification
The attachment debdiff making lvm in udev rules not wait on udev of
this bug report has been identified as being a patch in the form of a
debdiff. The ubuntu-sponsors team has been subscribed to the bug report
so that they can review and hopefully sponsor the debdiff. In the event
that this is
(Note, the debdiff above is just Wessel's suggestion from comment #21.
It'll need to be targeted at precise and give due credit if it is deemed
correct)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Has there been any progress with this?
I am seeing this problem 100% with an ESXi install using 3.0.0-12-server with
all the latest updates applied.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I was a little overzealous with the application of --noudevsync btw,
only vgchange accepts that option. Proper version:
SUBSYSTEM==block, ACTION==add|change, ENV{ID_FS_TYPE}==lvm*|LVM*, \
RUN+=watershed sh -c '/sbin/lvm vgscan; /sbin/lvm vgchange --noudevsync -a y'
--
You received this bug
Well, in some sense udev _is_ the user, because it has to wait for the
events which create the /dev/mapper/vg-lv and /dev/lg/lv nodes. This
resembles the same problem wich causes udevcomplete_all in my comment
#11 not to work reliably. The hang is gone, but there is still the
problem of some
vgchange will create the device mapper table entries before exiting, so
that part should be taken care of. After it's finished, udev will create
the device nodes and symlinks as it gets the information about the new
dm nodes from the kernel.
From the vgchange manpage:
--noudevsync
@Wessel, could you describe the deadlock you are talking about?
The hang I see is not a really a deadlock - it can't happen at random,
but only if udev is killed before it can acknowledge the DM_COOKIE.
Preventing udev's exit from blocking on the vgchange completing also
addressed that one. But
What I'm seeing is a vgchange process that hangs until udev kills it.
When it is killed it has only initialized a few LV's and most symlinks
in /dev/vgname are missing. Perhaps this is a different bug, but the
symptoms are exactly those from the original bug report.
Also, I'm not preventing
Quoting Wessel Dankers (wsl-launch...@fruit.je):
What I'm seeing is a vgchange process that hangs until udev kills it.
When it is killed it has only initialized a few LV's and most symlinks
in /dev/vgname are missing. Perhaps this is a different bug, but the
symptoms are exactly those from the
I think this happens because the lvm2 commands are called from inside
udev, while lvm itself also waits for udev to complete. This creates an
obvious deadlock.
/lib/udev/rules.d/85-lvm2.rules should be changed to read:
SUBSYSTEM==block, ACTION==add|change, ENV{ID_FS_TYPE}==lvm*|LVM*, \
It seems pretty clear what is happening here: udev's 85-lvm rule fires
off vgchange (through watershed); which activates lv, then sends udev a
DM_COOKIE with the address of a semaphore, then waits for that semaphore
to drop to zero; udev fires off 55-dm, which calls dmsetup udevcomplete
So for /dev/dm-* nodes already existing, the symlinks are not created.
Even with having 'udevadm trigger --action=add' invoked by
/etc/init/udevtrigger.conf when the rootfs-udevd is running.
We could try to make initramfs-udevd process the queued events by means of
removing the
This would not eliminate the potential of hanging, but in theory it
should at least avoid events being lost.
Well, I don't think there's any point in doing this (and slowing down
the boot) if it won't even reliably eliminate the risk of a hang.
--
You received this bug notification because
The fix to the udev --exit bug did not fix this bug. After uninstalling
my daemonizing watershed package, here is some debug info of the hung
vgchange -a y task. It is hung in dm_udev_wait() in semop on a
semaphore which is stuck at 1.
I'm not sure what other task could have set that value (and
The udevadm control --exit fix was not supposed to fix this bug. I
still have the (occasional) 60 seconds hang at boot. It is just that
'/dev' is now moved to rootfs, enabling the filesystems to be mounted
rw.
The very same lvm process which waits for the semaphore is the process
which set it to
Some logs of good and bad boots. Interestingly, vgchange actually
complains during the good boot that udev did not create the
/dev/schroots/kvm-1 link.
** Attachment added: bootlogs.tgz
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/802626/+attachment/2533585/+files/bootlogs.tgz
--
AIUI udevcomplete_all will clean up any hanging vgchange -a y processes,
but it won't solve the problem. udev is supposed to, in response to the
lvs created by vgchange, call 55-dm again, and thereby create the
/dev/{vg}/{lv} links (before calling dmsetup udevcomplete ${DM_COOKIE}
to un-hang
70 matches
Mail list logo
