** Branch linked: lp:ubuntu/maverick-proposed/parted
--
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
ub
Accepted parted into maverick-proposed, the package will build now and
be available in a few hours. Please test and give feedback here. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed. Thank you in advance!
** Changed in: parted (Ubuntu Maverick
This bug was fixed in the package parted - 2.3-4ubuntu2
---
parted (2.3-4ubuntu2) natty; urgency=low
* Don't call 'udevadm settle' when chrooted (LP: #664115).
-- Colin WatsonMon, 06 Dec 2010 16:29:47 +
** Changed in: parted (Ubuntu)
Status: Triaged => Fix Released
** 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
** Branch linked: lp:ubuntu/parted
--
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
ubuntu-bugs@lists.ub
Incidentally, I did look at live-helper and it seems to me that it isn't
going to run across the races that the 'udevadm settle' call was
originally introduced to prevent, so I believe that my fix is safe from
that point of view.
--
chroot loop devices stall for extremely long periods
https://bug
Sorry about the delay on this. My preference, I think, is simply to
change parted to avoid calling 'udevadm settle' when in a chroot. The
fact that it calls 'udevadm settle' is an Ubuntu patch for the benefit
of our installer in the first place, and we never rely on calling it in
a chroot. I'd b
** Changed in: udev (Ubuntu)
Assignee: Canonical Foundations Team (canonical-foundations) => Colin
Watson (cjwatson)
--
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, whi
Deleting patch from bug since its already been rejected.
** Patch removed: "Most of a solution to the problem"
https://bugs.launchpad.net/ubuntu/+source/udev/+bug/664115/+attachment/1706771/+files/parted-speed.patch
** Tags added: natty
** Tags removed: amd64 apport-bug patch
--
chroot loop
Thanks for the report and the patch, Could someone on the foundations
team have a look into it? Thanks a lot.
** Changed in: udev (Ubuntu)
Importance: Undecided => Medium
** Changed in: udev (Ubuntu)
Status: New => Triaged
** Changed in: udev (Ubuntu)
Assignee: (unassigned) => Can
Marking oem-priority; this dramatically increases (order of magnitude)
the time needed to build a Maverick or Natty OS image in our
infrastructure.
** Also affects: oem-priority
Importance: Undecided
Status: New
** Changed in: oem-priority
Status: New => Confirmed
** Changed in:
** 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 cre
** Tags added: oem-services
--
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://
** Tags added: patch
--
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.u
The bug isn't in live-build, even if we can work around this issue with
a hack, and there is no way upstream will accept this patch. Reassigning
to udev.
** Package changed: live-build (Ubuntu) => udev (Ubuntu)
--
chroot loop devices stall for extremely long periods
https://bugs.launchpad.net/bu
Attaching a patch that changes which parted is used by lh, thus avoiding
the udev problems previously mentioned in this bug.
** Patch added: "Most of a solution to the problem"
https://bugs.launchpad.net/ubuntu/+source/live-build/+bug/664115/+attachment/1706771/+files/parted-speed.patch
--
c
Re-assigning to live-build
** Package changed: coreutils (Ubuntu) => live-build (Ubuntu)
--
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.
--
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-back
18 matches
Mail list logo
