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
