On Fri, May 11, 2018 at 10:18 AM, Daniel Axtens <daniel.axt...@canonical.com> wrote: > Right. Yes, I can replicate that, thanks heaps!
Great! > > So to summarise, you can make the rename take effect on boot if you: > 1) copy the files from /run/systemd/network -> /etc/systemd/network > 2) then update-initramfs -u > > This seems pretty far outside of the way that netplan is supposed to work - > indeed using /etc/systemd/ is basically bypassing netplan. So we still have > the issue that just changing 'set-name' in /etc/netplan/*.yaml doesn't work > as expected. What should we change so that set-name works as expected? > > I see a few options: > > 0) Document that set-name is fragile and stop relying on it. This is > actually really easy to do and I have a netplan patch drafted already. The > reason that we have no network connectivity when set-name fails is that the > network file netplan creates maches on *both* the new name and the mac > address. We can just drop the new name from the [Match] section of the > relevant .network file and match only on the provided mac address (or > whatever else was used in the netplan match stanza). This means that > regardless of the interface name it's brought up and networking works. IIUC, we want to stop include the Name= value in the .network config since the name is flaky; we may want to hold off on that as I think we want the naming to be solid. You've outlined at least one way below. We should make set-name reliable and we can do that, even within netplan itself. > > 1) Make the initramfs hook for udev copy the files from /run (as well as > from /lib and /etc) into the initial ramdisk. This is probably my > preference; we can run netplan generate beforehand to make sure we get a > clean copy, and then document that update-initramfs is required to get > stuff to stick. Yes, I think that's also reasonable, it's a new location where .link files may be present. > > 2) Allow udev to re-rename interfaces. I don't know if this would be > acceptable to systemd upstream? > > 3) Something else? Netplan can do what cloud-init does and check that if the current name of an interface doesn't match the set-name value, to ip link set name on it. > > Regards, > Daniel > > -- > You received this bug notification because you are subscribed to > netplan. > Matching subscriptions: netplan > https://bugs.launchpad.net/bugs/1770082 > > Title: > systemd-networkd not renaming devices on boot > > To manage notifications about this bug go to: > https://bugs.launchpad.net/netplan/+bug/1770082/+subscriptions -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1770082 Title: systemd-networkd not renaming devices on boot Status in netplan: Incomplete Status in systemd package in Ubuntu: New Bug description: === systemd issue === Renaming devices doesn't seem to work. If I disable all other network configuration and create /etc/systemd/network/10-network.link with: [Match] MACAddress=52:54:00:c1:c9:bb [Link] Name=myiface3 I expect this to cause the device with that MAC address to be renamed to myiface3. However, when I reboot, I instead see: $ ip l 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: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff The device is not renamed. This link file is pretty much identical to Example 2 in https://www.freedesktop.org/software/systemd/man/systemd.link.html. The renaming does work if I boot with net.ifnames=0, and oddly, it also works if I unbind the device and rebind it as netplan apply does. No setting of NamePolicy seems to help. === Original Bug == 'set-name:' doesn't change the name of a network interface on boot, it only works when you do netplan apply. Say I take this 50-cloud-init.yaml file: # 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: ens3: dhcp4: true match: macaddress: 52:54:00:de:bd:f6 set-name: ens3 Say I change set-name to 'myiface3' and reboot. I expect that the device will be called myiface3 and brought up fine with dhcp. However, instead I see: $ 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: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff The name has not been changed, and the device has not been brought up. If I run netplan apply however, I see the following: 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: myiface3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3 valid_lft 3575sec preferred_lft 3575sec inet6 fe80::5054:ff:fede:bdf6/64 scope link valid_lft forever preferred_lft forever So names are successfully changed with netplan apply. This seems to be some udev-related timing or priority issue that I'm still trying to hunt down. This breaks some forms of migration in certain cloud environments. To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1770082/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
