[Bug 2008952] Re: DNS failure while trying to fetch user-data
Chad Smith
2008952 at bugs.launchpad.net
Wed Mar 22 20:29:40 UTC 2023
Short-term solution here will likely be for livecd-rootfs to augment
cloud-init.service which drops `Before=sysinit.target` and adds an
`After=NetworkManager-wait-online.service`. This is quite a bit like
what redhat and derivatives have done for a while. Redhat and
derivitatives have an `After=NetworkManager.service` for cloud-
init.service config and no `Before=sysinit.target`. Suse injects an
`After=dbus.service` which also puts it at the same boot timeframe as
NetworkManager-based environments.[1]
It does mean that cloud-init datasource gets detected a couple seconds later in boot, meaning that any service depending on `/run/cloud-init/instance-data.json` will also get delayed a couple of seconds, but doesn't delay overall boot process.
Long-term solution may be to see if we can improve NetworkManager dependency on dbus.service so that it could support late-bind interaction once dbus.socket comes online.
References:
[1] upstream suse/redhat cloud-init.service configuration NetworkManager/dbus ordering https://github.com/canonical/cloud-init/blob/main/systemd/cloud-init.service.tmpl#L19-L27
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2008952
Title:
DNS failure while trying to fetch user-data
Status in cloud-init:
Triaged
Status in netplan:
Invalid
Status in subiquity:
New
Status in systemd package in Ubuntu:
New
Bug description:
In testing netboot + autoinstall of the new ubuntu desktop subiquity
based installer for 23.04 I found cloud-init is failing to retrieve
user-data because it can't resolved the hostname in the URL. This
same configuration does work for 22.04 based subiquity, so seems a
regression.
From the ipxe config:
imgargs vmlinuz initrd=initrd \
ip=dhcp \
iso-url=http://cdimage.ubuntu.com/daily-live/pending/lunar-desktop-amd64.iso \
fsck.mode=skip \
layerfs-path=minimal.standard.live.squashfs \
autoinstall \
'ds=nocloud-net;s=http://boot.linuxgroove.com/ubuntu/23.04/' \
That fails, but if we replace boot.linuxgroove.com with the IP it
works.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2008952/+subscriptions
More information about the foundations-bugs
mailing list