> Note, that uvt-kvm is going to use cloud-init; how are you making > sure that cloud-init isn't doing the rename itself?
I instrumented the kernel. I added a call to dump_stack() in the function that does interface renaming: dev_change_name() in net/core/dev.c. That showed that the process that sent the netlink message was systemd-udevd: [ 1.007200] virtio_net virtio3 ens16: renamed from eth0 [ 1.008453] CPU: 0 PID: 124 Comm: systemd-udevd Not tainted 4.4.59+ #1 [ 1.009887] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 [ 1.011938] 0000000000000286 00000000d38795d9 ffff88001ed3b970 ffffffff813f3f63 [ 1.012435] ffff88001f2d0000 0000000000000000 ffff88001ed3b9d8 ffffffff8170669b [ 1.012435] ffff88001ed3b9c8 ffff88001ed3b9a0 ffffffff812255af 0000000030687465 [ 1.012435] Call Trace: [ 1.012435] [<ffffffff813f3f63>] dump_stack+0x63/0x90 [ 1.012435] [<ffffffff8170669b>] dev_change_name+0x25b/0x2e0 <call chain back to syscall snipped> ... [ 2.336114] virtio_net virtio3 ens3: renamed from ens16 [ 2.336121] CPU: 0 PID: 454 Comm: systemd-udevd Not tainted 4.4.59+ #1 [ 2.336122] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 [ 2.336124] 0000000000000286 0000000027d63c85 ffff88001c59b970 ffffffff813f3f63 [ 2.336126] ffff88001f2d0000 0000000000000000 ffff88001c59b9d8 ffffffff8170669b [ 2.336128] 0000000000000001 ffff88001c59b9b0 ffffffff810b3f1c 0000003631736e65 [ 2.336130] Call Trace: [ 2.336135] [<ffffffff813f3f63>] dump_stack+0x63/0x90 [ 2.336138] [<ffffffff8170669b>] dev_change_name+0x25b/0x2e0 <call chain back to syscall snipped> Notice in both cases: "Comm: systemd-udevd". Also notice the change in PID, suggesting that the first one is in initrd and the second one is not. I then grepped the source code for netlink stuff and quickly narrowed in on rename_if in udev-events.c. > Xenial by default doesn't use netplan; it still uses eni; the network > configuration generation in cloud-init using eni > does create a 70-persistent-net.rules file that handles renames on > subsequent reboots; in a netplan world (bionic) > the .link file is meant to be the equivalent of a .rules file. I am aware of this. (I've hacked on netplan quite a bit.) The issue is that a .link file does not seem to be functionally equivalent to a .rules file. I don't know if this difference is deliberate or an oversight. I will open an issue upstream and ask. > I've not attempted to determine if systemd-udev in bionic would > respect renames from .rules file; it certainly seems > odd to have .rules files allow renames independent of name_assign_type > value where .link files do. The end-user tested with a .rules file on Bionic and reported that it worked. I have also just verified that it does respect renames from a rules file regardless of name_assign_type. (The codepaths are unchanged between systemd-229 and systemd-237.) -- 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
