| 2010-10-20 19:26:43 |
Al Stone |
bug |
|
|
added bug |
| 2010-10-20 19:26:43 |
Al Stone |
attachment added |
|
script for reproducing the problem https://bugs.launchpad.net/bugs/664115/+attachment/1703639/+files/problem.sh |
|
| 2010-10-20 19:31:28 |
Al Stone |
summary |
choot loop devices stall for extremely long periods |
chroot loop devices stall for extremely long periods |
|
| 2010-10-22 15:54:34 |
Al Stone |
affects |
coreutils (Ubuntu) |
live-build (Ubuntu) |
|
| 2010-10-22 15:56:33 |
Al Stone |
attachment added |
|
Most of a solution to the problem https://bugs.launchpad.net/ubuntu/+source/live-build/+bug/664115/+attachment/1706771/+files/parted-speed.patch |
|
| 2010-10-22 17:10:55 |
Cody A.W. Somerville |
affects |
live-build (Ubuntu) |
udev (Ubuntu) |
|
| 2010-10-22 17:11:10 |
Cody A.W. Somerville |
bug |
|
|
added subscriber Cody A.W. Somerville |
| 2010-10-22 17:30:35 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Review Team |
| 2010-10-22 17:30:38 |
Brian Murray |
tags |
amd64 apport-bug maverick |
amd64 apport-bug maverick patch |
|
| 2010-11-04 01:45:48 |
Cody A.W. Somerville |
tags |
amd64 apport-bug maverick patch |
amd64 apport-bug maverick oem-services patch |
|
| 2010-11-04 01:54:22 |
Cody A.W. Somerville |
description |
Binary package hint: coreutils
Copied from the attached script that shows how to reproduce the problem:
# 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.
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 |
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:
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.
|
|
| 2010-11-12 21:46:31 |
Steve Magoun |
bug task added |
|
oem-priority |
|
| 2010-11-12 21:47:05 |
Steve Magoun |
oem-priority: status |
New |
Confirmed |
|
| 2010-11-12 21:47:09 |
Steve Magoun |
oem-priority: importance |
Undecided |
High |
|
| 2010-11-15 11:09:04 |
Pedro Villavicencio |
udev (Ubuntu): importance |
Undecided |
Medium |
|
| 2010-11-15 11:09:04 |
Pedro Villavicencio |
udev (Ubuntu): status |
New |
Triaged |
|
| 2010-11-15 11:09:04 |
Pedro Villavicencio |
udev (Ubuntu): assignee |
|
Canonical Foundations Team (canonical-foundations) |
|
| 2010-11-15 15:11:34 |
Cody A.W. Somerville |
attachment removed |
Most of a solution to the problem https://bugs.launchpad.net/ubuntu/+source/udev/+bug/664115/+attachment/1706771/+files/parted-speed.patch |
|
|
| 2010-11-15 15:12:30 |
Cody A.W. Somerville |
tags |
amd64 apport-bug maverick oem-services patch |
maverick natty oem-services |
|
| 2010-11-15 20:49:04 |
Robbie Williamson |
udev (Ubuntu): assignee |
Canonical Foundations Team (canonical-foundations) |
Colin Watson (cjwatson) |
|
| 2010-11-29 20:50:11 |
Colin Watson |
affects |
udev (Ubuntu) |
parted (Ubuntu) |
|
| 2010-11-29 20:50:30 |
Colin Watson |
nominated for series |
|
Ubuntu Maverick |
|
| 2010-11-29 20:50:30 |
Colin Watson |
bug task added |
|
parted (Ubuntu Maverick) |
|
| 2010-11-29 20:50:48 |
Colin Watson |
parted (Ubuntu Maverick): status |
New |
Triaged |
|
| 2010-11-29 20:50:51 |
Colin Watson |
parted (Ubuntu Maverick): importance |
Undecided |
Medium |
|
| 2010-11-29 20:50:54 |
Colin Watson |
parted (Ubuntu Maverick): assignee |
|
Colin Watson (cjwatson) |
|
| 2010-12-06 16:30:46 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/parted |
|
| 2010-12-06 16:40:18 |
Colin Watson |
description |
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:
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.
|
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.
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. |
|
| 2010-12-06 16:42:39 |
Colin Watson |
description |
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.
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. |
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.
|
|
| 2010-12-06 16:45:12 |
Launchpad Janitor |
parted (Ubuntu): status |
Triaged |
Fix Released |
|
| 2010-12-06 16:48:32 |
Launchpad Janitor |
branch linked |
|
lp:~cjwatson/ubuntu/maverick/parted/udevadm-settle-chrooted |
|
| 2010-12-10 17:28:21 |
Martin Pitt |
parted (Ubuntu Maverick): status |
Triaged |
Fix Committed |
|
| 2010-12-10 17:28:24 |
Martin Pitt |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2010-12-10 17:28:30 |
Martin Pitt |
bug |
|
|
added subscriber SRU Verification |
| 2010-12-10 17:28:35 |
Martin Pitt |
tags |
maverick natty oem-services |
maverick natty oem-services verification-needed |
|
| 2010-12-10 18:19:32 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/maverick-proposed/parted |
|
| 2011-01-13 00:13:11 |
Cody A.W. Somerville |
summary |
chroot loop devices stall for extremely long periods |
parted calls 'udevadm settle' after every change causing it to hang for 180s if no udevd with matching magic key is running. |
|
| 2011-01-15 00:27:46 |
Martin Pitt |
tags |
maverick natty oem-services verification-needed |
maverick natty oem-services verification-done |
|
| 2011-01-17 21:37:05 |
Launchpad Janitor |
parted (Ubuntu Maverick): status |
Fix Committed |
Fix Released |
|
| 2011-01-17 22:40:02 |
Cody A.W. Somerville |
nominated for series |
|
Ubuntu Lucid |
|
| 2011-01-17 22:40:02 |
Cody A.W. Somerville |
bug task added |
|
parted (Ubuntu Lucid) |
|
| 2011-01-20 17:39:41 |
Colin Watson |
parted (Ubuntu Lucid): importance |
Undecided |
Medium |
|
| 2011-01-20 17:39:41 |
Colin Watson |
parted (Ubuntu Lucid): status |
New |
Triaged |
|
| 2011-01-20 17:39:41 |
Colin Watson |
parted (Ubuntu Lucid): milestone |
|
ubuntu-10.04.3 |
|
| 2011-01-20 17:39:41 |
Colin Watson |
parted (Ubuntu Lucid): assignee |
|
Colin Watson (cjwatson) |
|
| 2011-06-20 18:43:13 |
Chris Van Hoof |
oem-priority: status |
Confirmed |
In Progress |
|
| 2011-06-30 08:12:35 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/lucid/parted |
|
| 2011-06-30 08:13:18 |
Colin Watson |
parted (Ubuntu Lucid): status |
Triaged |
In Progress |
|
| 2011-06-30 21:37:32 |
Martin Pitt |
parted (Ubuntu Lucid): status |
In Progress |
Fix Committed |
|
| 2011-06-30 21:37:36 |
Martin Pitt |
tags |
maverick natty oem-services verification-done |
maverick natty oem-services |
|
| 2011-06-30 21:37:37 |
Martin Pitt |
tags |
maverick natty oem-services |
maverick natty oem-services verification-needed |
|
| 2011-06-30 22:14:34 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/lucid-proposed/parted |
|
| 2011-07-11 20:24:35 |
Chris Van Hoof |
oem-priority: status |
In Progress |
Incomplete |
|
| 2011-07-11 20:24:46 |
Chris Van Hoof |
oem-priority: assignee |
|
Al Stone (ahs3) |
|
| 2011-07-19 10:04:06 |
Martin Pitt |
tags |
maverick natty oem-services verification-needed |
maverick natty oem-services verification-done |
|
| 2011-07-19 10:05:43 |
Launchpad Janitor |
parted (Ubuntu Lucid): status |
Fix Committed |
Fix Released |
|
| 2011-08-01 19:48:21 |
Kevin Krafthefer |
oem-priority: status |
Incomplete |
Fix Released |
|
| 2011-09-19 21:36:39 |
Ubuntu Foundations Team Bug Bot |
tags |
maverick natty oem-services verification-done |
maverick natty oem-services testcase verification-done |
|
