| 2012-07-30 20:18:01 |
Scott Moser |
bug |
|
|
added bug |
| 2012-07-30 22:17:54 |
Stéphane Graber |
affects |
resolvconf (Ubuntu) |
cloud-init (Ubuntu) |
|
| 2012-07-31 14:08:34 |
Scott Moser |
summary |
/sbin/resolvconf -a depends on /run/resolvconf/interface but it may not exist |
cloud-init-nonet runs 'start networking' explicitly |
|
| 2012-07-31 14:15:19 |
Scott Moser |
description |
In development of 'overlayroot' package, I was mounting / as rw in the initramfs.
This was causing a different order of execution of mounts, and as a result a different order of networking resolvconf and networking bringup.
It exposed a bug in resolvconf, which was being called on boot in this order:
==== Mon Jul 30 19:08:58 UTC 2012 /sbin/resolvconf -a lo.inet ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/dhclient-script ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/resolvconf -a eth0.dhclient ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/resolvconf -a eth0.inet ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/resolvconf --enable-updates ====
==== Mon Jul 30 19:08:59 UTC 2012 /etc/resolvconf/update.d/libc -u ====
The normal order is for resolvconf --enable-updates to be called (from /etc/init/resolvconf.conf) before anything else. As a result, I was seeing errors like:
resolvconf: Error: /run/resolvconf/interface either does not exist or is not a directory
This may be exposing a more grave issue, in that I believe the reason for dhclient coming up before resolvconf.conf started was that it was being run as a result of /etc/init/network-interface.conf. I don't immediately see how that is guarnateed to have /run ounted at all.
ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: resolvconf 1.67ubuntu1
ProcVersionSignature: User Name 3.5.0-6.6-generic 3.5.0
Uname: Linux 3.5.0-6-generic x86_64
Architecture: amd64
Date: Mon Jul 30 20:07:04 2012
PackageArchitecture: all
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: resolvconf
UpgradeStatus: No upgrade log present (probably fresh install) |
In development of 'overlayroot' package, I was mounting / as rw in the initramfs.
This was causing a different order of execution of mounts, and as a result a different order of networking resolvconf and networking bringup.
It exposed a bug in resolvconf, which was being called on boot in this order:
==== Mon Jul 30 19:08:58 UTC 2012 /sbin/resolvconf -a lo.inet ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/dhclient-script ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/resolvconf -a eth0.dhclient ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/resolvconf -a eth0.inet ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/resolvconf --enable-updates ====
==== Mon Jul 30 19:08:59 UTC 2012 /etc/resolvconf/update.d/libc -u ====
The normal order is for resolvconf --enable-updates to be called (from /etc/init/resolvconf.conf) before anything else. As a result, I was seeing errors like:
resolvconf: Error: /run/resolvconf/interface either does not exist or is not a directory
This may be exposing a more grave issue, in that I believe the reason for dhclient coming up before resolvconf.conf started was that it was being run as a result of /etc/init/network-interface.conf. I don't immediately see how that is guarnateed to have /run ounted at all.
ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: resolvconf 1.67ubuntu1
ProcVersionSignature: User Name 3.5.0-6.6-generic 3.5.0
Uname: Linux 3.5.0-6-generic x86_64
Architecture: amd64
Date: Mon Jul 30 20:07:04 2012
PackageArchitecture: all
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: resolvconf
UpgradeStatus: No upgrade log present (probably fresh install)
Related Bugs:
* bug 800824: cloud-init-nonet times out in lxc Edit
* bug 925122: container's udevadm trigger --add affects the host |
|
| 2012-07-31 14:16:12 |
Scott Moser |
description |
In development of 'overlayroot' package, I was mounting / as rw in the initramfs.
This was causing a different order of execution of mounts, and as a result a different order of networking resolvconf and networking bringup.
It exposed a bug in resolvconf, which was being called on boot in this order:
==== Mon Jul 30 19:08:58 UTC 2012 /sbin/resolvconf -a lo.inet ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/dhclient-script ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/resolvconf -a eth0.dhclient ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/resolvconf -a eth0.inet ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/resolvconf --enable-updates ====
==== Mon Jul 30 19:08:59 UTC 2012 /etc/resolvconf/update.d/libc -u ====
The normal order is for resolvconf --enable-updates to be called (from /etc/init/resolvconf.conf) before anything else. As a result, I was seeing errors like:
resolvconf: Error: /run/resolvconf/interface either does not exist or is not a directory
This may be exposing a more grave issue, in that I believe the reason for dhclient coming up before resolvconf.conf started was that it was being run as a result of /etc/init/network-interface.conf. I don't immediately see how that is guarnateed to have /run ounted at all.
ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: resolvconf 1.67ubuntu1
ProcVersionSignature: User Name 3.5.0-6.6-generic 3.5.0
Uname: Linux 3.5.0-6-generic x86_64
Architecture: amd64
Date: Mon Jul 30 20:07:04 2012
PackageArchitecture: all
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: resolvconf
UpgradeStatus: No upgrade log present (probably fresh install)
Related Bugs:
* bug 800824: cloud-init-nonet times out in lxc Edit
* bug 925122: container's udevadm trigger --add affects the host |
In development of 'overlayroot' package, I was mounting / as rw in the initramfs.
This was causing a different order of execution of mounts, and as a result a different order of networking resolvconf and networking bringup.
It exposed a bug in resolvconf, which was being called on boot in this order:
==== Mon Jul 30 19:08:58 UTC 2012 /sbin/resolvconf -a lo.inet ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/dhclient-script ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/resolvconf -a eth0.dhclient ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/resolvconf -a eth0.inet ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/resolvconf --enable-updates ====
==== Mon Jul 30 19:08:59 UTC 2012 /etc/resolvconf/update.d/libc -u ====
The normal order is for resolvconf --enable-updates to be called (from /etc/init/resolvconf.conf) before anything else. As a result, I was seeing errors like:
resolvconf: Error: /run/resolvconf/interface either does not exist or is not a directory
This may be exposing a more grave issue, in that I believe the reason for dhclient coming up before resolvconf.conf started was that it was being run as a result of /etc/init/network-interface.conf. I don't immediately see how that is guarnateed to have /run ounted at all.
ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: resolvconf 1.67ubuntu1
ProcVersionSignature: User Name 3.5.0-6.6-generic 3.5.0
Uname: Linux 3.5.0-6-generic x86_64
Architecture: amd64
Date: Mon Jul 30 20:07:04 2012
PackageArchitecture: all
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: resolvconf
UpgradeStatus: No upgrade log present (probably fresh install)
Related Bugs:
* bug 800824: cloud-init-nonet times out in lxc
* bug 925122: container's udevadm trigger --add affects the host |
|
| 2012-08-06 13:08:22 |
Scott Moser |
cloud-init (Ubuntu): importance |
Undecided |
Medium |
|
| 2012-08-06 13:08:22 |
Scott Moser |
cloud-init (Ubuntu): status |
New |
Triaged |
|
| 2012-08-06 13:08:22 |
Scott Moser |
cloud-init (Ubuntu): assignee |
|
Scott Moser (smoser) |
|
| 2012-08-22 20:12:26 |
Scott Moser |
cloud-init (Ubuntu): status |
Triaged |
Confirmed |
|
| 2012-09-05 20:55:19 |
Scott Moser |
description |
In development of 'overlayroot' package, I was mounting / as rw in the initramfs.
This was causing a different order of execution of mounts, and as a result a different order of networking resolvconf and networking bringup.
It exposed a bug in resolvconf, which was being called on boot in this order:
==== Mon Jul 30 19:08:58 UTC 2012 /sbin/resolvconf -a lo.inet ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/dhclient-script ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/resolvconf -a eth0.dhclient ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/resolvconf -a eth0.inet ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/resolvconf --enable-updates ====
==== Mon Jul 30 19:08:59 UTC 2012 /etc/resolvconf/update.d/libc -u ====
The normal order is for resolvconf --enable-updates to be called (from /etc/init/resolvconf.conf) before anything else. As a result, I was seeing errors like:
resolvconf: Error: /run/resolvconf/interface either does not exist or is not a directory
This may be exposing a more grave issue, in that I believe the reason for dhclient coming up before resolvconf.conf started was that it was being run as a result of /etc/init/network-interface.conf. I don't immediately see how that is guarnateed to have /run ounted at all.
ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: resolvconf 1.67ubuntu1
ProcVersionSignature: User Name 3.5.0-6.6-generic 3.5.0
Uname: Linux 3.5.0-6-generic x86_64
Architecture: amd64
Date: Mon Jul 30 20:07:04 2012
PackageArchitecture: all
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: resolvconf
UpgradeStatus: No upgrade log present (probably fresh install)
Related Bugs:
* bug 800824: cloud-init-nonet times out in lxc
* bug 925122: container's udevadm trigger --add affects the host |
In development of 'overlayroot' package, I was mounting / as rw in the initramfs.
This was causing a different order of execution of mounts, and as a result a different order of networking resolvconf and networking bringup.
It exposed a bug in resolvconf, which was being called on boot in this order:
==== Mon Jul 30 19:08:58 UTC 2012 /sbin/resolvconf -a lo.inet ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/dhclient-script ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/resolvconf -a eth0.dhclient ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/resolvconf -a eth0.inet ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/resolvconf --enable-updates ====
==== Mon Jul 30 19:08:59 UTC 2012 /etc/resolvconf/update.d/libc -u ====
The normal order is for resolvconf --enable-updates to be called (from /etc/init/resolvconf.conf) before anything else. As a result, I was seeing errors like:
resolvconf: Error: /run/resolvconf/interface either does not exist or is not a directory
This may be exposing a more grave issue, in that I believe the reason for dhclient coming up before resolvconf.conf started was that it was being run as a result of /etc/init/network-interface.conf. I don't immediately see how that is guarnateed to have /run ounted at all.
ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: resolvconf 1.67ubuntu1
ProcVersionSignature: User Name 3.5.0-6.6-generic 3.5.0
Uname: Linux 3.5.0-6-generic x86_64
Architecture: amd64
Date: Mon Jul 30 20:07:04 2012
PackageArchitecture: all
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: resolvconf
UpgradeStatus: No upgrade log present (probably fresh install)
Related Bugs:
* bug 800824: cloud-init-nonet times out in lxc
* bug 925122: container's udevadm trigger --add affects the host
* bug 643289: idmapd does not starts to work after system reboot |
|
| 2012-09-06 00:12:39 |
Steve Langasek |
cloud-init (Ubuntu): status |
Confirmed |
Triaged |
|
| 2012-09-08 02:24:16 |
Scott Moser |
attachment added |
|
virtual-filesystems-emitter https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1031065/+attachment/3300070/+files/virtual-filesystems-emitter |
|
| 2012-09-12 00:37:41 |
Steve Langasek |
attachment added |
|
console.log https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1031065/+attachment/3308428/+files/console.log |
|
| 2012-09-12 00:49:04 |
Steve Langasek |
bug |
|
|
added subscriber Steve Langasek |
| 2012-09-14 00:15:05 |
Launchpad Janitor |
branch linked |
|
lp:~smoser/cloud-init/trunk.lp1031065 |
|
| 2012-09-14 19:42:08 |
Launchpad Janitor |
branch linked |
|
lp:cloud-init |
|
| 2012-09-20 02:10:10 |
Launchpad Janitor |
cloud-init (Ubuntu): status |
Triaged |
Fix Released |
|
| 2012-09-24 17:30:02 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/cloud-init |
|
| 2012-10-05 15:02:36 |
Scott Moser |
nominated for series |
|
Ubuntu Precise |
|
| 2012-10-05 15:02:36 |
Scott Moser |
bug task added |
|
cloud-init (Ubuntu Precise) |
|
| 2012-10-05 15:04:09 |
Scott Moser |
cloud-init (Ubuntu Precise): status |
New |
Triaged |
|
| 2012-10-05 15:04:12 |
Scott Moser |
cloud-init (Ubuntu Precise): importance |
Undecided |
Medium |
|
| 2013-01-09 17:49:31 |
Launchpad Janitor |
branch linked |
|
lp:~smoser/ubuntu/precise/cloud-init/sru |
|
| 2013-01-31 19:26:41 |
Scott Moser |
description |
In development of 'overlayroot' package, I was mounting / as rw in the initramfs.
This was causing a different order of execution of mounts, and as a result a different order of networking resolvconf and networking bringup.
It exposed a bug in resolvconf, which was being called on boot in this order:
==== Mon Jul 30 19:08:58 UTC 2012 /sbin/resolvconf -a lo.inet ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/dhclient-script ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/resolvconf -a eth0.dhclient ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/resolvconf -a eth0.inet ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/resolvconf --enable-updates ====
==== Mon Jul 30 19:08:59 UTC 2012 /etc/resolvconf/update.d/libc -u ====
The normal order is for resolvconf --enable-updates to be called (from /etc/init/resolvconf.conf) before anything else. As a result, I was seeing errors like:
resolvconf: Error: /run/resolvconf/interface either does not exist or is not a directory
This may be exposing a more grave issue, in that I believe the reason for dhclient coming up before resolvconf.conf started was that it was being run as a result of /etc/init/network-interface.conf. I don't immediately see how that is guarnateed to have /run ounted at all.
ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: resolvconf 1.67ubuntu1
ProcVersionSignature: User Name 3.5.0-6.6-generic 3.5.0
Uname: Linux 3.5.0-6-generic x86_64
Architecture: amd64
Date: Mon Jul 30 20:07:04 2012
PackageArchitecture: all
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: resolvconf
UpgradeStatus: No upgrade log present (probably fresh install)
Related Bugs:
* bug 800824: cloud-init-nonet times out in lxc
* bug 925122: container's udevadm trigger --add affects the host
* bug 643289: idmapd does not starts to work after system reboot |
== Begin SRU Information ==
[Impact]
Cloud-init in 12.04 has an upstart job named 'cloud-init-nonet' that
calls 'start networking' explicitly. This was done to fix a boot
deadlock (bug 800824), but it was not the proper fix.
A much more correct fix is now possible because of improvements
that have been made in mountall (bug 643289) and have been brought
back to 12.04.
calling 'start networking' from cloud-init-nonet could cause issues
because other upstart 'start on' conditions might not be met at this
point in boot.
The fix here is the same as is now applied in quantal and raring.
It more correctly addresses the root issue, that network-device-added
events were not being emitted in a container. There is now a job named
cloud-init-container that will emit 'network-device-added' events if
it is inside a container *and* its sanity checks show that the given
device has not already been brought up.
[Test Case]
You can demonstrate why this change was necessary, and that the
provided change fixes the issue by doing the following:
## create a 'source' (pristine) root ##
sudo lxc-create -t ubuntu-cloud --name source-precise-amd64 -- \
--release precise --arch amd64 --stream daily
# set up 2 copies of the pristine root
# * 'nostart' just has cloud-init's call to 'start-networking' disabled
# * 'patched' contains the full upgraded cloud-init
sudo lxc-clone -o source-precise-amd64 -n nostart
f="/var/lib/lxc/nostart/etc/init/cloud-init-nonet.conf"
if [ ! -e "$f.dist" ]; then
# disable 'start networking' in the cloud-init-nonet job
sudo cp "$f" "$f.dist"
sudo sed -i 's,^\([ ]\+start networking.*\),#\1,' "$f"
fi
sudo lxc-clone -o source-precise-amd64 -n patched
deb="cloud-init_0.6.3-0ubuntu1.5~ppa1_all.deb"
rpath=/var/lib/lxc/patched/rootfs
sudo cp $deb "/var/lib/lxc/patched/rootfs/tmp"
sudo LANG=C chroot "/var/lib/lxc/patched/rootfs" dpkg -i "/tmp/$deb"
## Now, start both. the 'nostart' root will hang on
## cloud-init waiting for networking to come up.
## the 'patched' will come all the way up quickly.
## You can stop them with 'sudo lxc-stop -n <name>'
sudo lxc-start -n patched -- /sbin/init --verbose
sudo lxc-start -n nostart -- /sbin/init --verbose
[Regression Potential]
Regressions would be likely to occur in one of 2 places:
a.) inside a container, where cloud-init-container caused a
problem by emitting its network-device-added events
Here, the problem would be very limited to lxc containers
that have cloud-init inside them. This is likely very small.
b.) outside a container, where 'start networking' was previously
"fixing" a boot deadlock that could have occurred.
Here, the changes are basically making precise work like 12.10
and 13.04, so hopefully issues would have been shaken out there.
== End SRU Information ==
In development of 'overlayroot' package, I was mounting / as rw in the initramfs.
This was causing a different order of execution of mounts, and as a result a different order of networking resolvconf and networking bringup.
It exposed a bug in resolvconf, which was being called on boot in this order:
==== Mon Jul 30 19:08:58 UTC 2012 /sbin/resolvconf -a lo.inet ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/dhclient-script ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/resolvconf -a eth0.dhclient ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/resolvconf -a eth0.inet ====
==== Mon Jul 30 19:08:59 UTC 2012 /sbin/resolvconf --enable-updates ====
==== Mon Jul 30 19:08:59 UTC 2012 /etc/resolvconf/update.d/libc -u ====
The normal order is for resolvconf --enable-updates to be called (from /etc/init/resolvconf.conf) before anything else. As a result, I was seeing errors like:
resolvconf: Error: /run/resolvconf/interface either does not exist or is not a directory
This may be exposing a more grave issue, in that I believe the reason for dhclient coming up before resolvconf.conf started was that it was being run as a result of /etc/init/network-interface.conf. I don't immediately see how that is guarnateed to have /run ounted at all.
ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: resolvconf 1.67ubuntu1
ProcVersionSignature: User Name 3.5.0-6.6-generic 3.5.0
Uname: Linux 3.5.0-6-generic x86_64
Architecture: amd64
Date: Mon Jul 30 20:07:04 2012
PackageArchitecture: all
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: resolvconf
UpgradeStatus: No upgrade log present (probably fresh install)
Related Bugs:
* bug 800824: cloud-init-nonet times out in lxc
* bug 925122: container's udevadm trigger --add affects the host
* bug 643289: idmapd does not starts to work after system reboot |
|
| 2013-02-19 18:26:52 |
Clint Byrum |
cloud-init (Ubuntu Precise): status |
Triaged |
Fix Committed |
|
| 2013-02-19 18:26:54 |
Clint Byrum |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2013-02-19 18:27:00 |
Clint Byrum |
bug |
|
|
added subscriber SRU Verification |
| 2013-02-19 18:27:11 |
Clint Byrum |
tags |
amd64 apport-bug quantal |
amd64 apport-bug quantal verification-needed |
|
| 2013-02-19 21:19:10 |
Scott Moser |
tags |
amd64 apport-bug quantal verification-needed |
amd64 apport-bug quantal verification-done |
|
| 2013-02-27 02:42:29 |
Colin Watson |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2013-02-27 02:43:11 |
Launchpad Janitor |
cloud-init (Ubuntu Precise): status |
Fix Committed |
Fix Released |
|
| 2013-08-28 11:32:39 |
Launchpad Janitor |
branch linked |
|
lp:~ubuntu-branches/ubuntu/precise/cloud-init/precise-proposed |
|
| 2013-08-28 11:32:56 |
Launchpad Janitor |
branch linked |
|
lp:~ubuntu-branches/ubuntu/precise/cloud-init/precise-updates |
|
