DNS doesn't work in no-cloud as launched by ubuntu
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-init |
Fix Released
|
High
|
Unassigned | ||
cloud-init (Ubuntu) |
Fix Released
|
Critical
|
Unassigned | ||
Zesty |
Fix Released
|
Undecided
|
Unassigned | ||
Artful |
Won't Fix
|
Critical
|
Unassigned | ||
systemd (Ubuntu) |
Fix Released
|
Critical
|
Canonical Foundations Team | ||
Zesty |
Fix Released
|
Undecided
|
Unassigned | ||
Artful |
Fix Released
|
High
|
Unassigned | ||
Bionic |
Fix Released
|
Critical
|
Canonical Foundations Team |
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,
As documented here:
http://
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.
CVE References
description: | updated |
Changed in systemd (Ubuntu Bionic): | |
status: | Confirmed → Fix Committed |
Changed in systemd (Ubuntu Artful): | |
status: | Confirmed → In Progress |
tags: | added: id-5a1c7e7be1c6883c5a843d1f |
description: | updated |
Changed in cloud-init: | |
status: | Confirmed → Fix Released |
Changed in cloud-init (Ubuntu Artful): | |
status: | Confirmed → Won't Fix |
Entire command lines of how I'm doing this:
build@nestvirt:~$ qemu-img create -f qcow2 -b artful- server- cloudimg- amd64.img cloudy.img 20G zesty,accel= kvm,usb= off,dump- guest-core= off -m 4096 -smp 3 -cpu Opteron_G3 -device virtio- net-pci, netdev= hostnet0, id=net0, mac=52: 54:00:31: 33:70,bus= pci.0,addr= 0x3 -netdev bridge,id=hostnet0 -drive file=cloudy. img,if= virtio -smbios "type=1, serial= ds=nocloud- net;s=https:/ /raw.githubuser content. com/mlyle/ mlyle/master/ cloud-metadata/ linuxtst/" -kernel bzImage -append "root=/dev/vda1 ro console=ttyS0"
build@nestvirt:~$ kvm -nographic -machine pc-i440fx-