I disagree with comment #1
/etc/netlan/01-network-manager-all.yaml and /etc/netplan/50-cloud-
init.yaml should not be in conflict with each other, but will be merged
by Netplan to produce the following configuration:
```yaml
network:
version: 2
renderer: NetworkManager
ethernets:
enp0s21f6:
dhcp4: true
match:
macaddress: 6c:24:08:9e:54:e7
set-name: enp0s31f6
```
Which should render its config in /run/NetworkManager/system-connections
instead of /run/systemd/network (which would be the case if the global
renderer setting wasn't changed).
So I wonder what is the exact sequence of events for running the Netplan
generator (by systemd), installing the 50-cloud-init.yaml file (by
cloud-init), installing the 01-network-manager-all.yaml file (by the
installer?), executing `netplan apply` (by cloud-init).
Also, what are the artifacts generated by Netplan in
/run/systemd/network/ and /run/NetworkManager/system-connections/ ?
I assume some kind of race condition, where:
* cloud-init installs 50-cloud-init.yaml
* Netplan generator being run (as a systemd generator during early boot)
* systemd-network is now controlling the interface
* the installer putting the 01-network-manager-all.yaml file
* cloud-init calling `netplan apply` at runtime
* network configuration is being changed and NetworkManager is supposed to take
over control
* Interfaces still managed by networkd from the earlier stage, and therefore
getting into conflict
--
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:
New
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
