This bug was fixed in the package cloud-init -
cloud-init (0.7.8-1-g3705bb5-0ubuntu1~16.04.1) xenial-proposed; urgency=medium
* New upstream release 0.7.8.
* New upstream snapshot.
- systemd: put cloud-init.target After multi-user.target (LP: #1623868)
cloud-init (0.7.7-31-g65ace7b-0ubuntu1~16.04.2) xenial-proposed;
* debian/control: add Breaks of older versions of walinuxagent (LP:
cloud-init (0.7.7-31-g65ace7b-0ubuntu1~16.04.1) xenial-proposed;
* debian/control: fix missing dependency on python3-serial,
and make SmartOS datasource work.
* debian/cloud-init.templates fix capitalisation in template so
dpkg-reconfigure works to select OpenStack. (LP: #1575727)
* d/README.source, d/control, d/new-upstream-snapshot, d/rules: sync
with yakkety for changes due to move to git.
* d/rules: change PYVER=python3 to PYVER=3 to adjust to upstream change.
* debian/rules, debian/cloud-init.install: remove install file
to ensure expected files are collected into cloud-init deb.
* debian/dirs: remove obsolete / unused file.
* upstream move from bzr to git.
* New upstream snapshot.
- Allow link type of null in network_data.json [Jon Grimm] (LP: #1621968)
- DataSourceOVF: fix user-data as base64 with python3 (LP: #1619394)
- remove obsolete .bzrignore
- systemd: Better support package and upgrade. (LP: #1576692, #1621336)
- tests: cleanup tempdirs in apt_source tests
- apt config conversion: treat empty string as not provided. (LP: #1621180)
- Fix typo in default keys for phone_home [Roland Sommer] (LP: #1607810)
- salt minion: update default pki directory for newer salt minion.
- bddeb: add --release flag to specify the release in changelog.
- apt-config: allow both old and new format to be present.
[Christian Ehrhardt] (LP: #1616831)
- python2.6: fix dict comprehension usage in _lsb_release. [Joshua Harlow]
- Add a module that can configure spacewalk. [Joshua Harlow]
- add install option for openrc [Matthew Thode]
- Generate a dummy bond name for OpenStack (LP: #1605749)
- network: fix get_interface_mac for bond slave, read_sys_net for ENOTDIR
- azure dhclient-hook cleanups
- Minor cleanups to atomic_helper and add unit tests.
- Fix Gentoo net config generation [Matthew Thode]
- distros: fix get_primary_arch method use of os.uname [Andrew Jorgensen]
- Apt: add new apt configuration format [Christian Ehrhardt]
- Get Azure endpoint server from DHCP client [Brent Baude]
- DigitalOcean: use the v1.json endpoint [Ben Howard]
- MAAS: add vendor-data support (LP: #1612313)
- Upgrade to a configobj package new enough to work [Joshua Harlow]
- ConfigDrive: recognize 'tap' as a link type. (LP: #1610784)
- NoCloud: fix bug providing network-interfaces via meta-data.
- Add distro tags on config modules that should have it [Joshua Harlow]
- ChangeLog: update changelog for previous commit.
- add ntp config module [Ryan Harper]
- SmartOS: more improvements for network configuration
- tools/read-version: update to address change in version
- make-tarball: older versions of git with --format=tar.
- read-version: do not attempt git-describe if no git.
- Newer requests have strong type validation [Joshua Harlow]
- For upstream snapshot versions do not modify git-describe output.
- adjust signal_handler for version changes.
- revert unintended change to ubuntu sources list
- drop modification of version during make-tarball, tools changes.
- adjust tools and version information.
- Update build tools to work with git [Lars Kellogg-Stedman]
- fix pep8 errors in mcollective unit tests
- mcollective: add tests, cleanups and bug fix when no config in /etc.
-- Scott Moser <smo...@ubuntu.com> Thu, 15 Sep 2016 09:57:27 -0400
** Changed in: cloud-init (Ubuntu Xenial)
Status: Fix Committed => Fix Released
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
snapd.boot-ok.service hangs eternally on cloud image upgrades
Status in cloud-init package in Ubuntu:
Status in snapd package in Ubuntu:
Status in cloud-init source package in Xenial:
Status in snapd source package in Xenial:
==== Begin SRU Template [cloud-init] ====
One of cloud-init's features is to upgrade the system during first boot so
that it is fully up to date when the user code starts running.
launch an old instance of 16.04 that will need an update to snapd with
user-data that indicates a package upgrade should be done.
$ lxc image show ubuntu:74a491804877
description: ubuntu 16.04 LTS amd64 (release) (20160830)
$ printf "#%s\n%s\n" cloud-config "packages: [snapd]" > user-data
$ lxc launch ubuntu:74a491804877 xrecreate "--config=user.user-data=$(cat
$ lxc exec xrecreate -- tail -f /var/log/cloud-init-output.log
# you will see the output log hang at:
# Setting up snapd (2.14.2~16.04) ...
## Now get new container and patch in cloud-init
$ lxc launch ubuntu:74a491804877 xpatched
# let it boot, with no user-data saying to update.
$ sleep 10
# update the container to new cloud-init, then clean it to make
# it look like first boot again.
$ lxc file push - xpatched/etc/cloud/cloud.cfg.d/update.cfg < user-data
$ lxc exec xpatched -- sh -c '
echo deb http://archive.ubuntu.com/ubuntu xenial-proposed main > "$p" &&
apt-get update -q && apt-get -qy install cloud-init'
$ lxc exec xpatched -- sh -c '
cd /var/lib/cloud && for d in *; do [ "$d" = "seed" ] || rm -Rf "$d"; done
rm -Rf /var/log/cloud-init*'
$ lxc exec xpatched reboot
$ lxc exec xpatched -- tail -f /var/log/cloud-init-output.log
# snapd installed and a 'Cloud-init finished' message.
The change to running package installation later in boot will likely affect
some things. However, previously a larger set of things were unreliable. This
will make things over all more reliable.
==== End SRU Template [cloud-init] ====
I reproducibly run into an eternal hang when deploying services with
Juju, when it prepares a new xenial testbed. The current xenial cloud
image does not have the latest snapd, so snapd gets dist-upgraded:
Preparing to unpack .../snapd_2.14.2~16.04_amd64.deb ...
Warning: Stopping snapd.service, but it can still be activated by:
Unpacking snapd (2.14.2~16.04) over (2.13) ...
Setting up snapd (2.14.2~16.04) ...
The postinst tries to start snapd.boot-ok.service on upgrade:
root 922 0.0 0.0 25316 1412 pts/0 S+ 06:09 0:00
/bin/systemctl start snapd.boot-ok.service
This hangs eternally because:
- cloud-init's dist-upgrade runs *during* the boot process, so that
the system is not fully booted yet when this happens (see bug
1576692); thus multi-user.target is *not* yet active
- snapd.boot-ok.service is After=multi-user.target
- "systemctl start" is synchronous by default, i. e. it waits until
the service is started unless you use --no-block.
Thus snapd.postinst waits on snapd.boot-ok.service waits on multi-
user.target waits on cloud-init to finish waits on snapd.postinst to
I think conceptually you shouldn't start snapd.boot-ok.service in the
postinst; if the system is already booted (manual dist-upgrade) it
should already be running, and if it does get upgraded during boot
(with cloud-init) then you shouldn't pretend that booting is already
finished. So I suggest to use dh_installinit with --no-scripts for
To manage notifications about this bug go to:
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : firstname.lastname@example.org
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp