Package: cloud.debian.org Severity: important This has so far only been observed on Azure. It's not clear whether it's impacted other cloud environments or not.
Cloud-init is not consistently being enabled during VM provisioning on Microsoft Azure. The external symptom is that the launch times out. We can see from the logs that the various systemd services associated with cloud-init are never invoked at all: Failed launch: root@boot-failure:~# journalctl -b -1 | grep cloud-init | wc -l 0 Versus a successful launch: root@boot-failure:~# journalctl -b 0 | grep cloud-init | wc -l 102 root@boot-failure:~# journalctl -b 0 | grep cloud-init | head -n1 Mar 12 18:12:01 localhost systemd[1]: Starting cloud-init-main.service - Cloud-init: Single Process... root@boot-failure:~# journalctl -b 0 | grep cloud-init.target Mar 12 18:12:12 boot-failure systemd[1]: Reached target cloud-init.target - Cloud-init target. It may have something to do with cloud-init's systemd generator, which is responsible for conditionally enabling cloud-init.target early in the boot process. On a failed launch it generates the following in /run/cloud-init/cloud-init-generator.log: /usr/lib/systemd/system-generators/cloud-init-generator normal=/run/systemd/generator early=/run/systemd/generator.early late=/run/systemd/generator.late checking for datasource While a successful launch specifically indicates that it's enabling cloud-init.target: /usr/lib/systemd/system-generators/cloud-init-generator normal=/run/systemd/generator early=/run/systemd/generator.early late=/run/systemd/generator.late checking for datasource ds-identify rc=0 enabled via /run/systemd/generator.early/multi-user.target.wants/cloud-init.target -> /lib/systemd/system/cloud-init.target
