The issue here is as actually an interface mismatch between udevd and
udevadm.

'udevadm settle' works by sending a netlink message to the udevd
process. However, the magic key (UDEV_MONITOR_MAGIC) udevd uses to
communicate w/ udevadm changed between lucid and maverick (presumably
due to a non-backwards-compatible interface change). So, if you are
running a maverick system and try to run lucid's udevadm in a chroot,
there will be no compatible udevd to respond. The long delay is due to a
hardcoded timeout default in udevadm - it will wait up to 180s for udevd
to signal settle completion.

I verified this by debootstrapping both a lucid and a maverick chroot on
a maverick host. In a pristine host config:

   chroot /chroot/lucid udevadm settle -> hang
   chroot /chroot/lucid udevadm settle -> no hang

If I modify the host's udev to listen to lucid's UDEV_MONITOR_MAGIC
define, I get the inverse results.

So how does live-helper trigger this? parted has an ubuntu-specific
patch that calls 'udevadm settle' after manipulating partitions to avoid
races with other applications that might be triggered by partition
changes.

In my opinion, the right place to fix this is in live-helper, since it
could use the host's parted (and therefore the host's udevadm) to tweak
devices in the chroot.

-- 
chroot loop devices stall for extremely long periods
https://bugs.launchpad.net/bugs/664115
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to