Netplan ignores Interfaces without IP Addresses

Indeed; but this is meant to be that way -- there is no usefulness in having a network device listed in the file without any configuration, as you can always just do "ip link set $device up" to bring it up.

If there is no configuration, the device is left alone, as it should be.

If you must have an interface brought up but with no addresses, you may wish to also set:

dhcp4: off
dhcp6: off

These should force netplan to write out extra systemd configuration to disable DHCP, the new files present for systemd may help bringing up the interface.

"there is no usefulness in having a network device listed in the file without any configuration, as you can always just do "ip link set $device up" to bring it up"

Following this argument, there is no usefulness having netplan at all as you can always configure an interface using ip command line tool.

The main point of such configuration tool is to automate network configuration at boot time. And sometime, a system need to have its interfaces up to run properly, even if they are not configured (OpenVSwitch for instance).

I tried the following config, but it had no effect. Using false instead
of off had also no effect. Using true, resulted in netplan generating a
systemd config.

---
network:
  version: 2
  renderer: networkd
  ethernets:
    eth1:
      dhcp4: off
      dhcp6: off

There are in fact many cases where you want an interface brought up without having to apply an IP address.

* A virtual machine host where VM:s are connected to an interface but the host itself should not reside on that network.

* VPN gateways bridging the external interface with an internal interface where the internal interface doesn't need to have an IP address on that network.

* Network sniffers

Not sure if just anyone is allowed to mark a bug as duplicate, but this looks to be the same as bug #1728134: https://bugs.launchpad.net/netplan/+bug/1728134

I also second klockren's comments. The virtual machine case is exactly the situation I am in.

A workaround is to set a local ipv6 address on the interface.

Currently that is the only way to get the interface up.

@cyphermox: "there is no usefulness in having a network device listed in the file without any configuration, as you can always just do "ip link set $device up" to bring it up"

What about bridges used by LXC/LXD containers ?

You need to have them in UP state to provide connectivity to the containers.

Current workaround is to set local ipv6 address like @ramilehti said.

      addresses:
      - fe80::10/128

I am very disappointed about quality of this software.

Why this is in stable?!
Old solution works fine and it has all features.

The case specific to bridging is at #1736975

This links to a workaround at http://djanotes.blogspot.com/2018/04/anonymous-bridges-in-netplan.html

For example kolla/openstack requires running interface without an configuration. It attaches it's open-switch bridges in a later startup process.
Example:
https://docs.openstack.org/neutron/rocky/install/environment-networking-controller-ubuntu.html

I don't think this is a kolla bug. Marking invalid for kolla.

Can You explain how it's related to Neutron? I don't know about anything like "Netplan" to be used in Neutron.

In a general OpenStack installation, especially rolled out via kolla-ansible or openstack-ansible we require network interfaces which are up and without any further configuration. The deployment tools then connect either open-vswitch or linux-bridge to these interfaces. open-vswitch is not making sure that the physical interface is in later process. An example can be shown, if required.
So this is affecting kolla-ansible.

@Andreas, sorry but I still don't understand how it affects neutron. Maybe You can give some more detailed example to explain that.

Regardless of the application stack, it is simply not acceptable a NIC manager that does not allow to have an interface up with not ip configured. This is basically makes the interface usable just at layer 3, how about having something working on the date lync?!?

The version of netplan.io in bionic-proposed appears to resolve this problem for me.

Hi Tim,

which version are you using?

ii netplan.io 0.40.1~18.04.2 amd64 YAML network configuration abstraction for various backends

Just ran into this when installing devstack on Ubuntu 18. I configured netplan with:

  vlans:
    eno1.818:
      id: 818
      link: eno1

When I apply'ed this, it created the link, but did not bring it up.

eno1.818 is referenced in the devstack configuration the "PUBLIC_INTERFACE". It gets plumbed into Open vSwitch to provide neutron a link to the outside world. Neutron expects that this interface already exists and is "up".

The equivalent for Ubuntu 16, which did work:

auto eno1.818
iface eno1.818 inet manual
    vlan-raw-device eno1

I'm in a similar boat as Mateusz Pawlowski (teluka).
We've got a few different VLANs that we bridge off of to give various LXDs access to different things. Specifically: LXD inter-container communication/general colo network access, LXD DB hosts, and or DMZ access.

Especially for the DMZ VLAN, we have a strong desire to prevent any communication between the host and the outside world.. So obviously an IP on the host for the DMZ bridge would be a poor choice.

Why was Netplan deployed in an LTS while missing features? Especially static networking-related features which I'd suspect are used much more often in LTS releases (because servers).

Lessen learned, don't use any Ubuntu products before LTS .3 release

This breaks 802.1q subinterfaces. I use docker libnetwork macvlan subinterfaces. On every reboot the physical interface doesn't come up and containers lose external connectivity.

Subscribed field-high (netplan) as this impacts the ability of network nodes in OpenStack deployments to come up with a working data-plane.

Example impact:

1) an ovs bridge uses an interface enp4s0f1 for a data-port (Neutron + OVS datapath)
ovs-vsctl show
    Bridge br-data
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port phy-br-data
            Interface phy-br-data
                type: patch
                options: {peer=int-br-data}
        Port "enp4s0f1"
            Interface "enp4s0f1"

2) netplan contains the following configuration enp4s0f1

network:
    version: 2
    ethernets:
        enp4s0f1:
            match:
                macaddress: 78:e7:d1:24:d7:31
            mtu: 1500
            set-name: enp4s0f1
        enp4s0f0:
            addresses:
            - 10.232.1.139/21
            gateway4: 10.232.0.1
            match:
                macaddress: 78:e7:d1:24:d7:30
            mtu: 1500
            nameservers:
                addresses:
                - 10.232.0.2
                search:
                - maas
                - newmaas
            set-name: enp4s0f0

3) The systemd-networkd files generated by netplan differ for interfaces that have IP addresses configures vs the ones that do not (.network file is not generated for interfaces without an IP address)

cat /run/systemd/network/10-netplan-enp4s0f1*
[Match]
MACAddress=78:e7:d1:24:d7:31

[Link]
Name=enp4s0f1
WakeOnLan=off
MTUBytes=1500

tree /run/systemd/network/
/run/systemd/network/
├── 10-netplan-enp4s0f0.2728.netdev
├── 10-netplan-enp4s0f0.2728.network
├── 10-netplan-enp4s0f0.2730.netdev
├── 10-netplan-enp4s0f0.2730.network
├── 10-netplan-enp4s0f0.2731.netdev
├── 10-netplan-enp4s0f0.2731.network
├── 10-netplan-enp4s0f0.2732.netdev
├── 10-netplan-enp4s0f0.2732.network
├── 10-netplan-enp4s0f0.link
├── 10-netplan-enp4s0f0.network
├── 10-netplan-enp4s0f1.link
├── 10-netplan-enp5s0d1.link
└── 10-netplan-enp5s0.link

Before reboot the interface was up (as a result of a charm doing ip link up enp4s0f1):

$ ip a s enp4s0f1
3: enp4s0f1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq master ovs-system state UP group default qlen 1000
    link/ether 78:e7:d1:24:d7:31 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::7ae7:d1ff:fe24:d731/64 scope link
       valid_lft forever preferred_lft forever

After reboot the interface is down:

ip a s enp4s0f1
3: enp4s0f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop master ovs-system state DOWN group default qlen 1000
    link/ether 78:e7:d1:24:d7:31 brd ff:ff:ff:ff:ff:ff

And systemd-networkd reports enp4s0f1 as "off" and unmanaged:

sudo networkctl list | grep enp4s0
IDX LINK TYPE OPERATIONAL SETUP
  2 enp4s0f0 ether routable configured
  3 enp4s0f1 ether off unmanaged

Adding a network file for enp4s0f1 and restarting systemd-networkd fixes the problem:

cat > /run/systemd/network/10-netplan-enp4s0f1.network
[Match]
MACAddress=78:e7:d1:24:d7:31
Name=enp4s0f1

sudo systemctl restart systemd-networkd

ip a s enp4s0f1
3: enp4s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qd...

I do not think Neutron is related in any way here by the way because it is not responsible for bringing OVS bridge interface links up => moving to invalid for Neutron.

@Dmitrii I agree.

Is this not fixed in 18.04.2 yet?

I also have the same problem, running openstack on Ubuntu 18.04.2.
The physical interface of br-ex does not come up because there is not IP address set in netplan yaml file.

below is default ubuntu openstack config, the enp3s0 interface comes up as it is connected to a linux bridge defined in netplan file. But the enp5s0 which is handled by ovs will not come up.

network:
  version: 2
  ethernets:
    enp3s0:
      match:
        macaddress: 00:1a:4b:4c:a6:60
      set-name: enp3s0
      mtu: 1500
    enp5s0:
      match:
        macaddress: 00:1a:4b:4c:a6:5e
      set-name: enp5s0
      mtu: 1500
  bridges:
    br-enp3s0:
      interfaces: [enp3s0]
      addresses:
      - 192.168.251.209/24
      gateway4: 192.168.251.1
      nameservers:
        search: [maas]
        addresses: [192.168.251.2]
      mtu: 1500

This major bug is one year old and the only answer "there is no usefulness ..."

Is this serious ?

We're actively working on this. Fixing this bug had to wait for another round of stable updates to complete while we correctly addressed the problem and made sure it was fixed correctly.

The fix is already in the git tree for netplan.io:
https://github.com/CanonicalLtd/netplan/commit/d96a6a0f50c98301a36042f5065e7e834737122f

The previous SRU round is finished, so now we'll do another that will include this fix in priority, to land in 18.04, 18.10, 19.04 and eoan.

This *does* take some time, SRUs need proper testing and a waiting period in the -proposed component. Please help test the fix when it will be available (another comment will follow saying so), this will greatly help making it available at large as quickly as possible.

This bug was fixed in the package netplan.io - 0.97-0ubuntu1

---------------
netplan.io (0.97-0ubuntu1) eoan; urgency=medium

  * New upstream release: 0.97
    - networkd: force bringing up devices with no IP addresses (LP: #1763608)
    - Reworked renderer choosing to avoid regression in default renderer when
      multiple files specify it globally (LP: #1825206)
    - Fixed networkd activation. (LP: #1821867)
  * Drop all patches; they are included in the upstream release.

 -- Mathieu Trudel-Lapierre <email address hidden> Wed, 08 May 2019 16:50:13 -0400

Hello Johannes, or anyone else affected,

Accepted netplan.io into disco-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/netplan.io/0.97-0ubuntu1~19.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-disco to verification-done-disco. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-disco. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hello Johannes, or anyone else affected,

Accepted netplan.io into cosmic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/netplan.io/0.97-0ubuntu1~18.10.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-cosmic to verification-done-cosmic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-cosmic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hello Johannes, or anyone else affected,

Accepted netplan.io into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/netplan.io/0.97-0ubuntu1~18.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Thanks for the update. I appreciate these things take time.

Regards,
/Arno

On Wed, 8 May 2019 at 16:21, Mathieu Trudel-Lapierre <email address hidden>
wrote:

> We're actively working on this. Fixing this bug had to wait for another
> round of stable updates to complete while we correctly addressed the
> problem and made sure it was fixed correctly.
>
> The fix is already in the git tree for netplan.io:
>
> https://github.com/CanonicalLtd/netplan/commit/d96a6a0f50c98301a36042f5065e7e834737122f
>
> The previous SRU round is finished, so now we'll do another that will
> include this fix in priority, to land in 18.04, 18.10, 19.04 and eoan.
>
> This *does* take some time, SRUs need proper testing and a waiting
> period in the -proposed component. Please help test the fix when it will
> be available (another comment will follow saying so), this will greatly
> help making it available at large as quickly as possible.
>
> ** Changed in: netplan
> Status: New => Fix Committed
>
> ** Also affects: netplan.io (Ubuntu)
> Importance: Undecided
> Status: New
>
> ** Changed in: netplan.io (Ubuntu)
> Status: New => In Progress
>
> ** Changed in: netplan.io (Ubuntu)
> Importance: Undecided => Critical
>
> ** Changed in: netplan.io (Ubuntu)
> Assignee: (unassigned) => Mathieu Trudel-Lapierre (cyphermox)
>
> ** Description changed:
>
> + [Impact]
> + Netplan users who need to bring up an interface (set its flag to IFF_UP)
> but not define an address, using the networkd renderer, as the interface
> may be further managed via another tool.
> +
> + [Test case]
> + 1) Install Ubuntu
> + 2) Set up netplan; with the following different use cases:
> +
> + == New VLAN ==
> +
> + network:
> + version: 2
> + renderer: networkd
> + ethernets:
> + [... whatever is already configured for the system...]
> + vlans:
> + vlan100:
> + link: <the existing ethernet>
> + id: 100
> +
> + == Bring up an existing secondary interface ==
> +
> + network:
> + version: 2
> + renderer: networkd
> + ethernets:
> + eth0: {}
> +
> +
> + 3) Verify that in both cases, the interface (ethernet or VLAN) is
> brought up and shows UP, LOWER_UP flags in the output of 'ip link'.
> +
> +
> + [Regression potential]
> + As this brings a behavior change in netplan where as soon as an
> interface is listed in the netplan YAML, it will be brought up, care should
> be taken with existing configurations that do work, if specific devices are
> listed but are not assigned an IP address, as they will be brought up by
> networkd. This is expected to be a limited number of cases already, and
> impact to network installations is minimal.
> +
> +
> + ----
> +
> The "manual" method in /etc/network/interfaces resulted in an interface
> being brought up, but not having an IP address assigned.
>
> When configuring an Interface without an IP Address, netplan ignores the
> interface instead of bringing it up.
>
> ---
> network:
> - version: 2
> - renderer: networkd
> - ethernets:
> - eth1: {}
> + version: 2
> + renderer: networkd
> + ethernets:
> + eth1: {}
>
> Expected result from `netplan apply`: eth1 is brought u...

So; this has landed in Eoan now, and also in -proposed repositories for 18.04, 18.10, 19.04. I'll start doing testing on these releases, but since I don't have an openvswitch setup, any and all further independent confirmation that the issue is fixed (or indeed, if it's not), is welcome.

Verified that the fix works with netplan.io=0.97-0ubuntu1~18.04.1 in bionic.

network:
  version: 2
  renderer: networkd
  ethernets:
    ens10: {}

this brings ens10 up without an address.

@Lars, thanks!

Marking verification-done-bionic.

Verification-done on cosmic:

ubuntu@brave-elf:~$ lsb_release -cs
cosmic
ubuntu@brave-elf:~$ 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.
# 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:
    version: 2
    ethernets:
        ens4:
            set-name: ens4
            match:
                macaddress: 52:54:00:6c:a4:13
            mtu: 9000
            dhcp4: yes
        ens7: {}
ubuntu@brave-elf:~$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:6c:a4:13 brd ff:ff:ff:ff:ff:ff
3: ens7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:5f:79 brd ff:ff:ff:ff:ff:ff
ubuntu@brave-elf:~$ dpkg -l netplan.io | grep ii
ii netplan.io 0.97-0ubuntu1~18.10.1 amd64 YAML network configuration abstraction for various backends

Verification-done for disco:

ubuntu@right-elf:~$ lsb_release -cs
disco
ubuntu@right-elf:~$ dpkg -l netplan.io | grep ii
ii netplan.io 0.97-0ubuntu1~19.04.1 amd64 YAML network configuration abstraction for various backends
ubuntu@right-elf:~$ 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.
# 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:
    ethernets:
        ens4:
            match:
                macaddress: 52:54:00:8d:47:9e
            mtu: 1500
            set-name: ens4
            dhcp4: yes
        ens7: {}
    version: 2
ubuntu@right-elf:~$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:8d:47:9e brd ff:ff:ff:ff:ff:ff
3: ens7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:73:09:2e brd ff:ff:ff:ff:ff:ff

The verification of the Stable Release Update for netplan.io has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package netplan.io - 0.97-0ubuntu1~19.04.1

---------------
netplan.io (0.97-0ubuntu1~19.04.1) disco; urgency=medium

  * Backport netplan.io 0.97 to 19.04. (LP: #1828299)

netplan.io (0.97-0ubuntu1) eoan; urgency=medium

  * New upstream release: 0.97
    - networkd: force bringing up devices with no IP addresses (LP: #1763608)
    - Reworked renderer choosing to avoid regression in default renderer when
      multiple files specify it globally (LP: #1825206)
    - Fixed networkd activation. (LP: #1821867)
  * Drop all patches; they are included in the upstream release.

 -- Mathieu Trudel-Lapierre <email address hidden> Thu, 09 May 2019 10:19:13 -0400

This bug was fixed in the package netplan.io - 0.97-0ubuntu1~18.10.1

---------------
netplan.io (0.97-0ubuntu1~18.10.1) cosmic; urgency=medium

  * Backport netplan.io 0.97 to 18.10. (LP: #1828299)
  * Keep debian/patches/glib_changes.patch: Make sure tests work on older GLib.

netplan.io (0.97-0ubuntu1) eoan; urgency=medium

  * New upstream release: 0.97
    - networkd: force bringing up devices with no IP addresses (LP: #1763608)
    - Reworked renderer choosing to avoid regression in default renderer when
      multiple files specify it globally (LP: #1825206)
    - Fixed networkd activation. (LP: #1821867)
  * Drop all patches; they are included in the upstream release.

 -- Mathieu Trudel-Lapierre <email address hidden> Thu, 09 May 2019 11:29:56 -0400

This bug was fixed in the package netplan.io - 0.97-0ubuntu1~18.04.1

---------------
netplan.io (0.97-0ubuntu1~18.04.1) bionic; urgency=medium

  * Backport netplan.io 0.97 to 18.04. (LP: #1828299)
  * Keep patches specific to 18.04 support:
    - glib_changes.patch: fixes for older GLib version
    - disable-networkd-tunnels-ipip-gre.patch: disable tests for unsupported
      tunnel types (ipip and gre) in the 18.04 version of systemd-networkd.

netplan.io (0.97-0ubuntu1) eoan; urgency=medium

  * New upstream release: 0.97
    - networkd: force bringing up devices with no IP addresses (LP: #1763608)
    - Reworked renderer choosing to avoid regression in default renderer when
      multiple files specify it globally (LP: #1825206)
    - Fixed networkd activation. (LP: #1821867)
  * Drop all patches; they are included in the upstream release.

 -- Mathieu Trudel-Lapierre <email address hidden> Thu, 09 May 2019 13:11:53 -0400

LTSP booting in 18.04 has broken with the recent netplan update; I think due to this patch.

Involved steps:
1) Clients netboot from the LTSP server with something like nfsroot=xxx.

2) Initramfs-tools sets an IP (usually ipv4).

3) LTSP initramfs hooks create an overlay for the file system to make it writable, and create /etc/network/interfaces with the following contents, to prevent the IP from being removed/changed:
auto enp0s3
iface enp0se inet manual

4) Here is the regression, this version of netplan now creates /run/systemd/network/10-netplan-enp0s3.network with these contents:
[Match]
MACAddress=08:00:27:e9:33:39
Name=enp0s3

[Network]
LinkLocalAddressing=ipv6

5) systemd-networkd then sees this configuration and unassigns the interface IP, hanging the clients. I don't know if it was supposed to re-initialize the IP, but it just hangs then.

The workaround we currently use is to remove netplan from the initramfs:
rm /lib/systemd/system-generators/netplan

Could you please tell us of a better way to tell netplan not to assign an IP to the boot interface, or see if it's actually a bug in netplan?

In the initramfs; if an ip= command exists in the kernel command-line, a netplan configuration will be written. I would expect this is a requirement anyway if you want to use nfsroot=.

I certainly don't expect this to have changed at all in the recent updates; we've been writing a netplan configuration in /run for a while. One change, however, might be a dropped patch in NetworkManager to take into account further files written in /run/NetworkManager by netplan.

In short; the expected behavior is:
- boot off the network, initramfs configures network (via dhcp or an assigned IP via command-line)
- network config (dhcp or manual) is captured in /run/netplan/<interface>.yaml, so it's propagated to the running system after initramfs is done and we switch to the real root.
- networkd configures the network (well, keeps it up with the same config as in the initramfs). This part isn't selectable, but NetworkManager should explicitly ignore the interface as externally managed.

I think there is some further complication in that you're also writing /etc/network/interfaces, but the config provided does not look at fault.

Please file a separate bug; include /run/netplan and /run/NetworkManager after the system has booted, along with the contents of /var/log/syslog. If possible, stop NetworkManager and restart it with "/usr/sbin/NetworkManager --log-level=DEBUG -n" and include this debug output.

To be clear, I don't think this would be a regression caused by the netplan update. The only change is essentially to configure interfaces as soon as they appear in yaml (even if no IP is configured), which wouldn't cause a difference from the current initramfs behavior (where the file is statically written and includes IP config).

Sorry for the regression, and thanks for the detailed bug report. I'm
sure a fix will be relatively quick and straightforward, but as an aside
I would suggest that you run some machines on -proposed because that's
where we cook changes to the deep plumbing, and this one was there for a
reasonable period before moving to -updates. I think this would be
especially valuable for LTSP given your audience and some of the tricky
ways in which you exercise the low level bits.

Mark

After further discussion about this bug on IRC; I understand the situation better. These are thin clients that run everything off the network.

This is indeed a bug in the netplan generation code. You're seeing a networkd config there, where there shouldn't be any (since your renderer is set to NetworkManager).

I think we should fix that anyway, but I also think this situation is one where it might just be best to remove the generator from the initramfs completely (as you've been doing). Any network change is likely to bring down the connection (along with the system), so even running NetworkManager available on the system means people could accidentally bring it down.

Thanks to cyphermox, we pinpointed the issue in IRC to:
* when the kernel cmdline contains ip=client-ip:server-ip:gateway:netmask (e.g. due to syslinux IPAPPEND 3),
* ipconfig in the initramfs generates a /run/net-enp0s3.conf file with PROTO='none',
* while the netplan integration in the initramfs-tools was expecting that to be PROTO='static'.

It doesn't happen when ip=dhcp or ip is not defined.

sabdfl, thank you for the advice; I'll enable -proposed on some VMs in my office as it's not suitable for schools; although several issues are only seen in e.g. 10 out of 1000 schools, so it's hard to catch them before they're globally released.

That's where it helps to have awesome support such as this. Thanks again!