Comment 30 for bug 2008952

Revision history for this message
Chad Smith (chad.smith) wrote :

I can now confirm successful autoinstall runs with FQDN in kernel commandline in Desktop live installer ISOs dated 20230403. This allows cloud-init.service to be ordered `After=NetworkManager.service NetworkManager-wait-online.service` which ensures devices and resolved are both 'up' and active by the time cloud-init tries to download remote user-data/meta-data from a seedurl.

$ cat /var/log/installer/media-info # also found in /cdrom/.disk/info in ephemeral environment
Ubuntu 23.04 "Lunar Lobster" - Daily amd64 (20230403)

$ # installer version of the snap
2023-04-03 15:42:37,497 INFO subiquity:163 Starting Subiquity server revision 907 of snap /snap/ubuntu-desktop-installer/907

Presence of the correct systemd service ordering for cloud-init.service in Desktop live installer builds dated 20230403 placing cloud-init.service `After=NetworkManager.service NetworkManager-wait-online.service` guarantee that network is up before cloud-init datasource discovery runs which also implies systemd-resolved has started and has adequate connectivity to source FQDNs on any NetworkManager discovered NICs.

ubuntu@ubuntu:~$ systemctl show -p After,Before cloud-init.service --no-pager
Before=sshd-keygen.service cloud-config.target network-online.target sshd.service shutdown.target systemd-user-sessions.service
After=cloud-init-local.service NetworkManager.service system.slice networking.service systemd-journald.socket systemd-networkd-wait-online.service NetworkManager-wait-online.service

This allows cloud-init to download remote user-data from an FQDN provided to the live desktop installer via the kernel parameter: `ds=nocloud-net;s=http://YOUR-DOMAIN/'

So, FQDN lookup seems to be resolved by the systemd service ordering after NetworkManager is up and functional.

There may be a secondary issue to file related to environments with nameservers being specifically provided for pxe-based installs after cloud-init properly downloads remote user-data from a remote FQDN but ordering of systemd network configuration seems to alleviate the DNS resolution aspect pointed to in this bug.