** Description changed: - Binary package hint: coreutils + parted can take a very long time when run within a chroot. - Copied from the attached script that shows how to reproduce the problem: + The issue here is an interface mismatch between udevd and udevadm. - # If I use parted to create a partition table in a file representing - # a disk image, it should take milliseconds to do. This seems to be - # the case when executing these steps directly: - # - # use losetup (from live-build) to get a /dev/loopN - # attach an empty file to the /dev/loopN - # run a parted script on the empty file to create a partition table - # release the /dev/loopN - # - # However, when executed from within a chroot, this can take multiple - # minutes, specifically when executing the parted step. - # - # Requires: - # -- A normal maverick desktop system - # -- a lucid chroot built and available on that desktop system - # -- "apt-get install live-build parted" in both the maverick - # desktop and the chroot - # - # To show the problem, run this script. First, without a chroot: - # $ sudo ./problem.sh - # then, use a chroot: - # $ sudo ./problem.sh chroot-directory - # - # The first run takes ~100-200 millisec on my system; the second run - # with chroot takes ~6 *minutes*! And, it does not matter whether or - # not /dev is bind-mounted to /dev in the chroot -- either way takes - # about the same amount of time. + '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. - ProblemType: Bug - DistroRelease: Ubuntu 10.10 - Package: coreutils 8.5-1ubuntu3 - ProcVersionSignature: Ubuntu 2.6.35-22.34-generic 2.6.35.4 - Uname: Linux 2.6.35-22-generic x86_64 - NonfreeKernelModules: fglrx - Architecture: amd64 - Date: Wed Oct 20 13:21:59 2010 - InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429) - ProcEnviron: - PATH=(custom, user) - LANG=en_US.utf8 - SHELL=/bin/bash - SourcePackage: coreutils + 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.
-- 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
