Adding a bridge with no member interfaces causes networkd to stall at boot time

[Mike Pontillo]

I'm not sure if this is an issue with how the netplan is rendered, or if this is a more general issue with networkd.

Steps to reproduce:

 - Install a basic 18.04 server (seen with nplan-0.36.3)
 - Observe the current state of the Netplan configuration:

"""
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: yes
"""

 - Change the Netplan configuration to the following:

"""
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: yes
  bridges:
    maas-br0:
      interfaces: []
      addresses:
       - 172.16.99.22/24
"""

 - Reboot the system (sudo reboot)
 - Observe that the system takes longer than expected to shut down
 - After the system reboots, observe that the system does not boot as quickly as expected. By switching virtual consoles (Alt-F2, for example) observe that "A start job is running for Wait for Network to be Configured". (see screenshot)

I have observed similar behavior when using bridges inside Bionic LXC containers as well.

[Mike Pontillo (mpontillo)]

I tried adding 'accept-ra: no' to the YAML, and tried the workaround in bug #1736975 (manually creating a .network file in /etc/systemd/network) and neither prevented the stall. However, after two minutes, networkd gives up and allows the system to continue booting - and the bridge exists.

[Ryan Harper (raharper)]

The bridge does not yet have any interfaces attached to it, so it has 'no-carrier'; it's not marked as optional so networkd-wait-online will block.

networkd does not appear to have a way to force an interface up if it has no-carrier. The best we can do at this point is to use:

ConfigureWithoutCarrier=yes in the [Network] section of bridge. This will assign the ip address to the bridge but I've not yet seen how we can force the interface up.

[Mike Pontillo (mpontillo)]

For the record, I'm now working around this issue by having LXD manage the bridge. Since I didn't want DHCP, I configured it in LXD with `ipv4.dhcp=false`.