** Description changed: parted can take a very long time when run within a chroot. The issue here is 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: + TEST CASE: 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/maverick udevadm settle -> no hang + chroot /chroot/lucid udevadm settle -> hang + chroot /chroot/maverick 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.
** Description changed: parted can take a very long time when run within a chroot. The issue here is 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. + + Development branch: Fixed in parted 2.3-4ubuntu2 by not calling 'udevadm + settle' if we're chrooted. TEST CASE: 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/maverick 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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/664115 Title: chroot loop devices stall for extremely long periods -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
