PPA for testing can be found in: https://launchpad.net/~slyon/+archive/ubuntu/lp2060311/+packages

This seem to work well. The new 10-netplan.conf file can get overcrowded if one has lots of interfaces on Netplan but I guess it shouldn't be a problem (unless you have enough interfaces to reach the maximum number of command line arguments o.O).

I did find a case though where the behavior changes: when you have the loopback interface in your yaml. Apparently -wait-online -i lo will always get stuck. So, people with ethernets.lo in their configuration will notice that wait-online will start to block after this chance. Maybe lo should be a special case and never included in the list?

This seem to work well. The new 10-netplan.conf file can get overcrowded if one has lots of interfaces on Netplan but I guess it shouldn't be a problem (unless you have enough interfaces to reach the maximum number of command line arguments o.O).

I did find a case though where the behavior changes: when you have the loopback interface in your yaml. Apparently -wait-online -i lo will always get stuck. So, people with ethernets.lo in their configuration will notice that wait-online will start to block after this chance. Maybe lo should be a special case and never included in the list?

Yeah either ignore it or would have to set a different operational state range, e.g. -o carrier. But the default behavior of systemd-networkd-wait-online (i.e. when no -i are specified on the command line) is to ignore loopback.

While I'm not seeing issues specifically related to cloud-init, this doesn't seem to be working correctly, or I'm not understanding how it is supposed to work. After install the PPA, if I reboot, regardless what I have under /etc/netplan, /run/systemd/system/systemd-networkd-wait-online.service.d/10-netplan.conf contains:

[Unit]
ConditionPathIsSymbolicLink=/run/systemd/generator/network-online.target.wants/systemd-networkd-wait-online.service

and nothing else.

regardless what I have under /etc/netplan, /run/systemd/system/systemd-networkd-wait-online.service.d/10-netplan.conf contains:

[Unit]
ConditionPathIsSymbolicLink=/run/systemd/generator/network-online.target.wants/systemd-networkd-wait-online.service

and nothing else.

@TheRealFalcon As long as you have any network definition in /etc/netplan/ that uses networkd as a renderer and does NOT use "optional: true" you should see the corresponding interface listed in that file after calling "netplan apply" (or reboot).

Does it matter that I'm in an LXD container?

root@asdf:~# cat /etc/netplan/50-cloud-init.yaml 
# This file is generated from information provided by the datasource.  Changes
# to it will not persist across an instance reboot.  To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    renderer: networkd
    ethernets:
        eth0:
            dhcp4: true
            match:
                macaddress: 12:34:56:78:90:ab
            # optional: true
        eth1:
            dhcp4: true
            match:
                macaddress: 00:16:3e:38:c3:9e
            # optional: false
    version: 2
root@asdf:~# netplan apply
root@asdf:~# cat /run/systemd/system/systemd-networkd-wait-online.service.d/10-netplan.conf 
[Unit]
ConditionPathIsSymbolicLink=/run/systemd/generator/network-online.target.wants/systemd-networkd-wait-online.service
root@asdf:~# reboot
root@asdf:~# 
Session terminated, killing shell...
 ...killed.
(cloud-init37) cow:net $ lxc shell asdf
root@asdf:~# cat /run/systemd/system/systemd-networkd-wait-online.service.d/10-netplan.conf 
[Unit]
ConditionPathIsSymbolicLink=/run/systemd/generator/network-online.target.wants/systemd-networkd-wait-online.service
root@asdf:~# 

Does it matter that I'm in an LXD container?

It worked in an LXD container for me earlier today. But it could have some impact on the macaddress matching.. can you try with a different matching condition, like name or driver? Looks like it doesn't find the interface here. I need to double-check that.

@slyon , doh, sorry. This was after I tore down a previous container and forgot to update my network configuration. Once I corrected the MAC address, it worked for me.

Looks like cloud-init is still having issues first boot. During our init-local timeframe, we write out netplan config, then call netplan generate. After boot is finished, checking the systemd-networkd-wait-online.service, systemd says we need to call daemon-reload.

This can be simulated in a container by running cloud-init clean --logs; rm /etc/netplan/50-cloud-init.yaml, then reboot.

After boot:

root@asdf:~# ls /run/systemd/generator/
getty.target.wants  local-fs.target.wants  netplan.stamp

root@asdf:~# systemctl status systemd-networkd-wait-online.service 
Warning: The unit file, source configuration file or drop-ins of systemd-networkd-wait-online.service changed on disk. Run 'systemctl daemon-reload' to reload units.
○ systemd-networkd-wait-online.service - Wait for Network to be Configured
     Loaded: loaded (/usr/lib/systemd/system/systemd-networkd-wait-online.service; enabled; preset: enabled)
    Drop-In: /run/systemd/system/systemd-networkd-wait-online.service.d
             └─10-netplan.conf
     Active: inactive (dead)
  Condition: start condition unmet at Tue 2024-04-16 21:40:25 UTC; 54s ago
             └─ ConditionPathIsSymbolicLink=/run/systemd/generator/network-online.target.wants/systemd-networkd-wait-online.service was not met
       Docs: man:systemd-networkd-wait-online.service(8)

Apr 16 21:40:25 asdf systemd[1]: systemd-networkd-wait-online.service - Wait for Network to be Configured was skipped because of an unmet condition check (ConditionPathIsSymbolicLink=/run/systemd/generator/network-online.target.wants/systemd-networkd-wait>

root@asdf:~# systemctl daemon-reload

root@asdf:~# ls /run/systemd/generator/
getty.target.wants  local-fs.target.wants  multi-user.target.wants  netplan.stamp  network-online.target.wants
root@asdf:~# 

Another thing I've found is that -wait-online blocks if the interface doesn't exist. So if you have interfaces in your YAMLs that are not present in the system it will block now. The previous behavior is to not block.

Added a tiny fix to recognize that we do not configure link-local IPs on bridge/bond members. (and of course, a codestyle typo as a follow-up ;-))