Comment 28 for bug 1770082

There are a couple of pieces in play here.

One aspect is that we don't really want to write the .link files for systemd-networkd to /lib or get anything from /run into the initrd -- that defeats the purpose of netplan's config being dynamic.

The second aspect is that depending on how the systems are deployed (MAAS? cloud images? openstack? VM? hardware?) changes the behavior a bit. Some USB-based network interfaces are simply "unaffected" and rename just fine at boot. Other systems may be renaming the interfaces, but seeing cloud-init re-change the name *back* to the previous value (this has been observed for MAAS-deployed systems). This is why I added cloud-init to affected packages -- cloud-init should not be second-guessing the network layer and attempting to do renames / to run udevadm, except *maybe* at first boot/when the instance data is created. I believe it should just leave it alone completely, and let netplan/systemd/NM deal with the interfaces themselves (if anything needs to be poked, it's arguably a bug in the backend).

Another issue is that systemd is also second-guessing configuration. If we set things to be renamed, we do want them to be renamed. Now, this is a bit more up to discussion upstream, but I do think systemd should always rename if configuration tells it to (via .link files or udev rules -- .link files are "cleaner", easier to write). Users renaming their interfaces manually via 'ip link dev X name Y' are doing so on their own, and the change would not be persistent across a reboot -- renaming in configuration is expected to work normally.