On Fri, May 11, 2018 at 3:25 AM, Daniel Axtens <daniel.axt...@canonical.com> wrote: > Ryan, I can't get that to work on my systems. What is it that update- > initramfs is supposed to change? I don't see any files in my initramfs > that are generated or read by netplan. Neither do I see netplan itself > in the initramfs!
The .link files end up getting pulled into the initramfs, where systemd-udev will run and apply the names there. When systemd-udev does a rename, the kernel marks an interface 'name_assign_type' to a value of 4 and systemd-udev will refuse to further rename a device, despite having a rule (.link file) to do so. Netplan works around this in 'apply' by unplugging the driver, which resets the state of the 'name_assign_type' value in the kernel. > > Mathieu, I thought netplan was supposed to be initramfs friendly by > virtue of being in C. Is it supposed to be in the initramfs? The generator is, the cli is not. > > For both of you, how are you getting through initrd without your device > being given a generic udev name (like ens3 or enp1s0)? On both my > physical and virtual machines, my various network cards all get renamed > in initrd, well before netplan is run. We're not; udev runs in the initramfs and triggers renames there. > > [PS. I know the scenario as described sounds far-fetched - the original > way this came up was a cloud setup where you can change the type of a > network interface but keep the same MAC. The different type leads to a > different udev name, which is what revealed that set-name: wasn't taking > effect.] Cloud scenarios are slightly different when cloud-init is involved; Cloud-init itself will handle device renames if they are needed. Typically cloud-init just re-uses the name the interface got from udev when it renders it's netplan config during boot. For non-cloud scenarios (or if you attempt to use set-name in a cloud instances without launching a new instance) we're seeing this situation where we are creating new .link files but they need to be present in the initramfs otherwise when udevd runs, it will set the name to the predictable name and then ignore any of the .link files on the rootfs. This really needs fixing in udev; I don't think there's a good reason to have udev refuse to rename an interface. > > -- > 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
