Ubuntu
parted package

  1. Bug #664115
  2. Comment #2

Comment 2 for bug 664115

Revision history for this message
dann frazier (dannf) wrote : Re: chroot loop devices stall for extremely long periods

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.