Comment 75 for bug 2036358

> If you have a bunch of unmanaged interfaces, then you should use a
> drop-in configuration to pass the --any flag to
> systemd-networkd-wait-online:
>
> cat > /etc/systemd/system/systemd-networkd-wait-online.service.d/any.conf << EOF
> [Service]
> ExecStart=
> ExecStart=/lib/systemd/systemd-networkd-wait-online --any
> EOF
>
> This makes it so that systemd-networkd-wait-online will return success once at least one interface becomes configured.

Unfortunately this doesn't appear to work. I've tried this on the
current noble dailies (which also suffer the 2 minute boot delay on
the server images due to this issue). The default netplan config is
simply:

  network:
    version: 2
    ethernets:
      eth0:
        dhcp4: true
        optional: true

This displays the issue, even with --any presumably because wlan0 is
unmanaged so networkctl reports the online state is "unknown" (even
when eth0 is happily configured and routable).

I attempting making wlan0 "managed" but optional. This requires a
mandatory access point to be defined to conform to the YAML schema, so
I added a fake one (I should open a separate issue for this because I
shouldn't have to make up access points just to mark an interface
optional):

  network:
    version: 2
    ethernets:
      eth0:
        dhcp4: true
        optional: true
    wifis:
      wlan0:
        dhcp4: true
        optional: true
        access-points:
          foo:
            password: foobarbaz

Unfortunately this also displays the issue. This time wlan0 is
managed, but "configuring" and the online state is still "unknown". So
far as I can tell, the --any option doesn't match the behaviour
claimed in the man-page (i.e. "exits with success when at least one
interface becomes online").

> There is no workaround for this with the stock netplan config on
> raspberry pi, which trips this bug. But you can customize
> /etc/netplan/ on your system to mark your expected/required network
> interfaces as "optional: false" (which is the default if
> unspecified); AIUI that would avoid this issue with
> systemd-networkd.

This *does* work ... assuming the Pi actually has a network interface.
If the Pi is networkless, it's unfortunately doomed to the 2 minute
delay still. And obviously I don't want to make eth0 mandatory by
default in the images (which would break the 3A+ and Zero 2W, which
lack eth0 entirely).