netplan won't apply config on renamed interface

Added syslog file after running sudo netplan apply...

set-name is used in my config, and it works just fine. This might be driver-specific, or otherwise an issue with carrier detection?

Is see no other reason for things not to work, could there be a race due to renames? There looks to be many different renames on your system, from eth0 to enp0s3 and back. How are these systems deployed? Is it a new, clean install of Ubuntu?

I'm seeing the same issue. I can reproduce it with a fresh install using http://cdimage.ubuntu.com/releases/18.04.1/release/ubuntu-18.04.1-server-amd64.iso in a virtualbox VM with all updates applied. I've tested with both the virtio, and Intel PRO/1000 network drivers with the same results.

# ls -l /etc/netplan
-rw-r--r-- 1 root root 360 Nov 9 17:12 01-netcfg.yaml
# cat /etc/netplan/01-netcfg.yaml
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
  version: 2
  renderer: networkd
  ethernets:
    lan0:
      match:
        macaddress: 08:00:27:3d:1a:a4
      set-name: lan0
      addresses: [10.10.10.99/24]
      gateway4: 10.10.10.1
      nameservers:
        addresses: [10.10.10.1]
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: lan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 08:00:27:3d:1a:a4 brd ff:ff:ff:ff:ff:ff
# networkctl
IDX LINK TYPE OPERATIONAL SETUP
  1 lo loopback carrier unmanaged
  2 lan0 ether off unmanaged

2 links listed.
# netplan apply
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
3: lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:3d:1a:a4 brd ff:ff:ff:ff:ff:ff
    inet 10.10.10.99/24 brd 10.10.10.255 scope global lan0
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe3d:1aa4/64 scope link
       valid_lft forever preferred_lft forever
# networkctl
IDX LINK TYPE OPERATIONAL SETUP
  1 lo loopback carrier unmanaged
  3 lan0 ether routable configured

2 links listed.

I've noticed another oddity - it seems to occasionally work correctly after a soft reboot of the VM. It seems to always exhibits the above behaviour after a cold boot of the VM.

@Mathieu: Have you tried on a server installed with ubuntu-18.04-server-amd64.iso??? And with netplan.io:0.40.1~18.04.2 package installed?? Because renames were not working properly before 0.40.1~18.04.2 and after that, renames were ok (both on boot and on netplan apply) but no other configs are applied on boot, just on netplan apply....

@Mathieu: Also, isn't the first rename (from eth0 to enp0s3) done by systemd? Because it happens even with a clean install of Ubuntu, without further netplan configurations...

I can definitely confirm that there is an issue with using the 'set-name' directive as just adding that to the config file gives me three different results across four systems. One of the outcomes is identical to the reported issue.

All of these are on installs of Ubuntu Server 18.04.1 using the traditional installer (not Subiquity) image ubuntu-18.04.1-server-amd64.iso. I am testing this using the exact same netplan configuration on each system with the following results:
 - One system does not get an IP after boot until 'netplan apply' is run.
 - One system does not get an IP at all, even after running 'netplan apply'.
 - Two systems are working just fine.

Two of these are physical systems and are running netplan.io 0.36.3 that are connected to the same switch, the other two are VMware VMs on the same host running netplan.io 0.40.1~18.04.2. All systems are using the same DHCP server.

Here is the config I am using on each system:

network:
    version: 2
    renderer: networkd
    ethernets:
        testnet:
            match:
                macaddress: XX:XX:XX:XX:XX:XX
            dhcp4: yes
            dhcp-identifier: mac
            set-name: testnet

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
System-01 (No IP after boot) - netplan.io 0.36.3
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is an industrial embedded system with 2 Intel i210 interfaces. One interface will be configured for DHCP internet and the other will eventually be a static IP direct connected to an industrial gateway, but right now I am only configuring the first interface.

What happened is I had just completed a fresh install of 18.04.1 with the traditional installer and then changed the configuration for the LAN interface to use 'set-name'; then after rebooting no IP was given to the interface. This was resolved by running 'netplan apply', but after every reboot the issue repeats. If I remove the 'set-name' line from the configuration then the interface gets an IP immediately after reboot without me having to run 'netplan apply'.

This seems to be identical to the issue reported in this ticket.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
System 02 (Works fine) - netplan.io 0.36.3
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I then tested this configuration on a different system on my desk that I installed 18.04.1 on last week using the traditional installer. This is a PC104 SBC that is the same chipset as System-01, but with only one network interface (also Intel i210) and some extra I/O.

This system has no issues after rebooting, it both renames the interface and gets an IP during boot.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
System-03 (No IP at all) - netplan.io 0.40.1~18.04.2
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

As another test I used the above configuration on a VMware VM I setup a few weeks ago with the traditional installer on our ESXI 6.0 server. After rebooting it exhibited the same issues as the System-01, no IP on the interface after booting up. But this time when I ran 'netplan apply' the interface still wouldn't get an IP. No error messages are displayed or shown in th...

Hello,

For any system that's failing collecting some additional debugging
information may help

1) enable systemd-networkd debugging

% mkdir /etc/systemd/system/systemd-networkd.service.d/
% echo -e "[Service]\nEnvironment=SYSTEMD_LOG_LEVEL=debug" >
/etc/systemd/system/systemd-networkd.service.d/10-debug.conf

After rebooting collect and attach:

a) /run/systemd/network/*
b) journalctl -b
c) networkctl status --all

On Wed, Nov 21, 2018 at 8:10 PM William Foster
<email address hidden> wrote:
>
> I can definitely confirm that there is an issue with using the 'set-
> name' directive as just adding that to the config file gives me three
> different results across four systems. One of the outcomes is identical
> to the reported issue.
>
> All of these are on installs of Ubuntu Server 18.04.1 using the traditional installer (not Subiquity) image ubuntu-18.04.1-server-amd64.iso. I am testing this using the exact same netplan configuration on each system with the following results:
> - One system does not get an IP after boot until 'netplan apply' is run.
> - One system does not get an IP at all, even after running 'netplan apply'.
> - Two systems are working just fine.
>
> Two of these are physical systems and are running netplan.io 0.36.3 that are connected to the same switch, the other two are VMware VMs on the same host running netplan.io 0.40.1~18.04.2. All systems are using the same DHCP server.
>
> Here is the config I am using on each system:
>
> network:
> version: 2
> renderer: networkd
> ethernets:
> testnet:
> match:
> macaddress: XX:XX:XX:XX:XX:XX
> dhcp4: yes
> dhcp-identifier: mac
> set-name: testnet
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> System-01 (No IP after boot) - netplan.io 0.36.3
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> This is an industrial embedded system with 2 Intel i210 interfaces. One
> interface will be configured for DHCP internet and the other will
> eventually be a static IP direct connected to an industrial gateway, but
> right now I am only configuring the first interface.
>
> What happened is I had just completed a fresh install of 18.04.1 with
> the traditional installer and then changed the configuration for the LAN
> interface to use 'set-name'; then after rebooting no IP was given to the
> interface. This was resolved by running 'netplan apply', but after
> every reboot the issue repeats. If I remove the 'set-name' line from
> the configuration then the interface gets an IP immediately after reboot
> without me having to run 'netplan apply'.
>
> This seems to be identical to the issue reported in this ticket.
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> System 02 (Works fine) - netplan.io 0.36.3
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> I then tested this configuration on a different system on my desk that I
> installed 18.04.1 on last week using the traditional installer. This is
> a PC104 SBC that is the same chipset as System-01, but with only one
> network interface (also Intel i210) and some extra I/O.
>
> This system has no issues after rebooting, it both re...

@Ryan: Attached the additional info.

@Mathieu: I confirmed that the first rename comes from systemd... So not so weird. Maybe netplan could overcome that to do just one rename, but if not, every interface that uses set-name must have at least two renames.

On Mon, Nov 26, 2018 at 12:06 PM Marcos <email address hidden> wrote:
>
> @Ryan: Attached the additional info.
>
> @Mathieu: I confirmed that the first rename comes from systemd... So not
> so weird. Maybe netplan could overcome that to do just one rename, but
> if not, every interface that uses set-name must have at least two
> renames.
>
> ** Attachment added: "Additional logs"
> https://bugs.launchpad.net/netplan/+bug/1802004/+attachment/5216555/+files/debug.zip

Thanks. It appears that the kernel does the initial rename (as
expected) to persistent names.
And then when networkd comes online, the existing
/run/network/10-netplan-eth0.network files
are not considered for "eth0" which is currently named enp0s3; this is
due to the Name=eth0
in the [Match] section of the .network file.

What's unclear is why udev did not enforce the .link files. We've had
a bug open for this...

https://bugs.launchpad.net/netplan/+bug/1770082
https://github.com/systemd/systemd/issues/9006

This is supposedly fixed in systemd-239, and this system is running
systemd-237 which means
that the rename in the .link file is going to be ignored due to
systemd already renaming the
interface once (eth0 -> enp0s3).

As to why things behave differently on different systems, it may have
to do the the devices.
For example if the target nic device does not get a "persistent name"
that differs from the kernel
name, then the existing .network [Match] section will apply and the
configuration
is applied.

@Ryan I've also attached additional logs etc from a failing system. This is running in a Virtualbox VM installed from the server iso.

Is there a workaround on 18.04? How can I rename an interface? Use udev rules like before?

I'm currently working around this using a systemd .link file. I created /etc/systemd/network/50-lan0.link as follows:

[Match]
MACAddress=08:00:27:3d:1a:a4

[Link]
Name=lan0

Then ran update-initramfs -u

I then use netplan to configure the lan0 interface without doing any renaming.

I believe this is the same issue as https://bugs.launchpad.net/netplan/+bug/1768827.

This bug has the better title though.

Any updates there, 1 year for very important feature/bug?

need to provide a fix to Bionic customers still running < 297.

I had a similar issue but for me it's because netplan doesn't apply settings on "apply" but because it doesn't apply settings when renaming the interface during boot. It renames the interface after loading configs from /etc/syslog.d. It's annoying with some of the ipv6 tcp config. I want a temp ipv6 address and sysctl net.ipv6.conf.INTNAME.use_tempaddr = 2 to use IPV6 temp address but the settings gets reset to the kernel default of "0" every time.

I tracked it down to the interface being renamed after the kernel loads configuration files from /etc/sysctl.d.

I'm running "Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-47-generic x86_64)"

I cannot seem to reproduce this in a Ubuntu Jammy 22.04 LXD VM. I wonder if this is still an issue on more recent versions of Ubuntu (systemd/netplan)?

$ cat /etc/netplan/50-cloud-init.yaml
network:
    version: 2
    ethernets:
        lan0:
            match:
                macaddress: "00:16:3e:dd:53:87"
            set-name: lan0
            dhcp4: no
            addresses: [10.238.94.250/24]
            gateway4: 10.238.94.1

Rename seems to work as expected and the interface is up, with IP address assigned.
$ journalctl | grep rename
Oct 27 13:15:16 test kernel: virtio_net virtio10 lan0: renamed from enp5s0
Oct 27 13:15:16 test systemd-networkd[336]: enp5s0: Interface name change detected, renamed to lan0.
Oct 27 13:15:36 test kernel: virtio_net virtio10 lan0: renamed from eth0

$ networkctl
IDX LINK TYPE OPERATIONAL SETUP
  1 lo loopback carrier unmanaged
  2 lan0 ether routable configured

$ ip addr show lan0
2: lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:16:3e:dd:53:87 brd ff:ff:ff:ff:ff:ff
    inet 10.238.94.250/24 brd 10.238.94.255 scope global lan0
       valid_lft forever preferred_lft forever
    inet6 fd42:7213:f20e:bd74:216:3eff:fedd:5387/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 3309sec preferred_lft 3309sec
    inet6 fe80::216:3eff:fedd:5387/64 scope link
       valid_lft forever preferred_lft forever

I am also running into this problem on Ubuntu Core 20 using the following configuration:

network:
  version: 2
  renderer: networkd
  ethernets:
    en1:
      match:
        driver: "imx-dwmac"
      addresses:
      - "192.168.0.200/24"
      set-name: "en1"
    en2:
      match:
        driver: "fec"
      dhcp4: true
      dhcp6: true
      set-name: "en2"

This only affects networkd; with "renderer: NetworkManager" everything works correctly.

It seems like systemd-networkd doesn't recognise one of the interfaces:

iotuc@ubuntu:~$ sudo networkctl
IDX LINK TYPE OPERATIONAL SETUP
  1 lo loopback carrier unmanaged
  2 en2 ether routable configured
  3 en1 ether off unmanaged
  4 wlan0 wlan routable configured

4 links listed.

The "en2" interface works, so it seems like it's not reproducible for every configuration.

The files generated for systemd-networkd:

iotuc@ubuntu:~$ grep '' /run/systemd/network/10-netplan-en*
/run/systemd/network/10-netplan-en1.link:[Match]
/run/systemd/network/10-netplan-en1.link:Driver=imx-dwmac
/run/systemd/network/10-netplan-en1.link:
/run/systemd/network/10-netplan-en1.link:[Link]
/run/systemd/network/10-netplan-en1.link:Name=en1
/run/systemd/network/10-netplan-en1.link:WakeOnLan=off
/run/systemd/network/10-netplan-en1.network:[Match]
/run/systemd/network/10-netplan-en1.network:Driver=imx-dwmac
/run/systemd/network/10-netplan-en1.network:Name=en1
/run/systemd/network/10-netplan-en1.network:
/run/systemd/network/10-netplan-en1.network:[Network]
/run/systemd/network/10-netplan-en1.network:LinkLocalAddressing=ipv6
/run/systemd/network/10-netplan-en1.network:Address=192.168.0.200/24
/run/systemd/network/10-netplan-en2.link:[Match]
/run/systemd/network/10-netplan-en2.link:Driver=fec
/run/systemd/network/10-netplan-en2.link:
/run/systemd/network/10-netplan-en2.link:[Link]
/run/systemd/network/10-netplan-en2.link:Name=en2
/run/systemd/network/10-netplan-en2.link:WakeOnLan=off
/run/systemd/network/10-netplan-en2.network:[Match]
/run/systemd/network/10-netplan-en2.network:Driver=fec
/run/systemd/network/10-netplan-en2.network:Name=en2
/run/systemd/network/10-netplan-en2.network:
/run/systemd/network/10-netplan-en2.network:[Network]
/run/systemd/network/10-netplan-en2.network:DHCP=yes
/run/systemd/network/10-netplan-en2.network:LinkLocalAddressing=ipv6
/run/systemd/network/10-netplan-en2.network:
/run/systemd/network/10-netplan-en2.network:[DHCP]
/run/systemd/network/10-netplan-en2.network:RouteMetric=100
/run/systemd/network/10-netplan-en2.network:UseMTU=true

Separating the rename and address management into two YAML blocks seems to be a workaround for whatever is causing this problem:

network:
  version: 2
  renderer: networkd
  ethernets:
    en1-rename:
      match:
        driver: "imx-dwmac"
      set-name: "en1"
    en1:
      match:
        name: "en1"
      addresses:
      - "192.168.0.200/24"

The problem seems to be related to having both Driver and Name in the [Match] section of the .network file.

Isaac, could you please also provide the contents of /run/udev/rules.d/99-netplan-*.rules ? And a journalctl log from that Ubuntu Core 20 system?