Comment 18 for bug 1768827

I'm seeing exactly the same behaviour as above, on a fresh VM as well as a physical server. No special configuration is needed to see this bug, just attempt to use set-name and reboot. The rename happens but the device is left unconfigured til "netplan apply" or "service systemd-networkd restart" is run.

* It doesn't matter whether you match on MAC address or driver.

* Booting with net.ifnames=0 (as mentioned as a workaround to a previous similar bug) has no effect.

* I can confirm that networkd "sees" the rename (but then takes no action to configure the device):

Feb 27 10:10:14 bidev systemd-networkd[252]: enp0s3: Interface name change detected, enp0s3 has been renamed to meaningfulname.

* This still happens with the latest netplan (master 8b779f9) from github.

The following hack works, which may tell you something about the order in which things are happening:

********************************************************
toms@bidev:~$ cat /etc/systemd/system/fixnetplan.service
[Unit]
Description=Fix netplan (re-apply)
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/netplan apply
********************************************************

Lastly, my very simple config:
********************************************************
toms@bidev:~$ 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:
    enp0s3:
      match:
        driver: e1000
      set-name: meaningfulname
      dhcp4: yes
*******************************************************