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.

-- 
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:
  In Progress
Status in netplan:
  Invalid
Status in subiquity:
  New
Status in livecd-rootfs package in Ubuntu:
  Fix Released
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

Reply via email to