I can confirm Dan's validation that After=systemd-resolved.service doesn't buy us anything here because, although systemd-resolved.service is up, NetworkManager.service && NetworkManager-wait-online.service don't finish bringing link up for related network devices until After=dbus.service timeframe. So blocking on systemd-resolved.service tells us only that the service is running, not that it provides useful DNS lookups.
Since dbus.service is After=sysinit.target and sysinit.target is After=cloud-init.service we have an ordering cycle for NetworkManager that doesn't exist for systemd-networkd controlled environments. Any attempts to include After=NetworkManager-wait-online.service in cloud-init.service definition result in ordering cycles. Even if we try to add DefaultDependecies=no to both NetworkManager.service and NetworkManager-wait-online.service to prevent them from pulling in `After=sysinit.target` for ordering. NetworkManager images (desktop) differ from cloud-init's systemd-networkd managed images (server) because systemd-networkd-wait-online.service doesn't have a strict After=dbus.service config systemd-networkd can poll for dbus availability and use it once it's available. But, it doesn't seem NetworkManager has that facility though I haven't dug deeply into NM yet. -- 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/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 -- 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
