[Bug 906358] Re: udev and lvm2 hang at boot

[Herton R. Krzesinski]

*** This bug is a duplicate of bug 802626 ***
    https://bugs.launchpad.net/bugs/802626

So far this is the same as bug 802626, marking this one as duplicate of
it. Also, this is an userspace synchronization problem, not kernels's
fault.

Besides using --noudevsync, another solution is patching udev to not
ignore relevant lvm notifications from the kernel (events with DM_COOKIE
set) on exit:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/802626/comments/53

** This bug has been marked a duplicate of bug 802626
   vgchange may deadlock in initramfs when VG present that's not used for rootfs

** Changed in: linux (Ubuntu)
       Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to udev in Ubuntu.
https://bugs.launchpad.net/bugs/906358

Title:
  udev and lvm2 hang at boot

Status in “linux” package in Ubuntu:
  Invalid
Status in “udev” package in Ubuntu:
  Confirmed

Bug description:
  I'm experiencing a really long wait when booting freshly installed
  xubuntu 11.10 with only updates and mdadm + lvm2 installed. I have
  managed to narrow it down somewhat but still looking for a fix.

  After disabling splash and quiet from grub I noticed it's waiting at /scripts/init-bottom/udev in initrd and continues after 61 seconds.
  Not surprisingly i found a "udevadm control --timeout 61 --exit" line in there. Well, why does it fail so badly it waits for timeout before exiting?

  After quite a bit of googling I found this:
  http://us.generation-nt.com/answer/problem-lvm-gets-stuck-during-booting-due-recent-uevent-change-help-205241751.html
  Ari Savolainen writes:
  An init script (/scripts/init-bottom/udev in initrd) issues command
  "udevadm control --timeouta --exit".
  At the same time udevd is executing "/sbin/lvm vgchange -a y" (from
  /lib/udev/rules.d/85-lvm2.rules) that calls ioctl to resume a logical
  volume. After that lvm gets stuck forever. Booting continues after the
  61 second timeout.

  Milan Broz writes:
  If you call vgchange or even vgscan from udev rule, it is completely wrong.
  This is not lvm upstream udev rule btw.

  This makes me slightly worried, does this cause any other problems
  than a annoyingly slow boot? Is there any way to fix this? I this a
  known issue?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/906358/+subscriptions