Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3065
** Bug watch added: github.com/canonical/cloud-init/issues #3065 https://github.com/canonical/cloud-init/issues/3065 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1734167 Title: DNS doesn't work in no-cloud as launched by ubuntu Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in cloud-init source package in Zesty: Fix Released Status in systemd source package in Zesty: Fix Released Status in cloud-init source package in Artful: Won't Fix Status in systemd source package in Artful: Fix Released Status in systemd source package in Bionic: Fix Released Bug description: [Impact] * resolved does not start early enough in the boot-process preventing DNS resolution to be operational during early boot, for example as required by special early stages of cloud-init, resulting in failure to boot / provision the instance fully. [Test Case] * Boot container or a VM with a nocloud-net data source, and a URL pointing to the datasource as explained below * Observe that boot completes and provisioning is successful * Check that there are no dns-resolution errors in the cloud-init log / boot log [Regression Potential] * starting resolved earlier may prevent it from connecting to dbus, and may require a restart later on when re-triggered over dbus. This is on artful only, as in bionic resolved has gained ability to reconnected to dbus post-start. Backporting that, however, is too large for an SRU as it requires sd-bus changes. [Other Info] * Original bug report. I use no-cloud to test the kernel in CI (I am maintainer of the bcache subsystem), and have been running it successfully under 16.04 cloud images from qemu, using a qemu command that includes: -smbios "type=1,serial=ds=nocloud- net;s=https://raw.githubusercontent.com/mlyle/mlyle/master/cloud- metadata/linuxtst/" As documented here: http://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html Under the new 17.10 cloud images, this doesn't work: the network comes up, but name resolution doesn't work-- /etc/resolv.conf is a symlink to a nonexistent file at this point of the boot and systemd-resolved is not running. When I manually hack /etc/resolv.conf in the cloud image to point to 4.2.2.1 it works fine. I don't know if nameservice not working is by design, but it seems like it should work. The documentation states: "With ds=nocloud-net, the seedfrom value must start with http://, https:// or ftp://"; And https is not going to work for a raw IP address. Related bugs: * bug 1734939: #include fails silently. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1734167/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
