[Bug 1770082] Re: systemd-networkd not renaming devices on boot
Ryan Harper
1770082 at bugs.launchpad.net
Tue May 15 18:22:00 UTC 2018
Note, that uvt-kvm is going to use cloud-init; how are you making
sure that cloud-init isn't doing the rename itself?
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'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.
On Tue, May 15, 2018 at 12:29 PM, Daniel Axtens
<daniel.axtens at canonical.com> wrote:
> Hi Ryan,
>
> [Journal Output]
> Attached.
>
> [Reproducer]
> uvt-kvm create xenial-test release=xenial arch=amd64
> virsh edit xenial-test # change network interface pci slot: s/0x03/0x10/
> virsh destroy xenial-test
> virsh start xenial-test
> uvt-kvm ssh xenial-test
> dmesg|grep rename
> [ 2.790623] virtio_net virtio3 ens16: renamed from eth0
> [ 6.048520] virtio_net virtio3 ens3: renamed from ens16
>
> [Analysis]
> I've been working on this a lot, and I think I have the cause of the difference.
>
> In udev-events.c, udev_execute_rules will _forcibly_ rename a device
> with via a netlink message if there is a matching rule that sets a name.
> Under Xenial, there *is* a matching rule, in 70-persistent-net.rules, so
> this forces a rename. This rename will occur even if the device already
> has a name, and therefore even if the rules file isn't in the initramfs.
>
> Under Bionic, this rules file doesn't exist, there is a .link file
> instead. Unfortunately, a name in a .link file will only take effect if
> the device hasn't been renamed - because of the renaming in initrd, this
> means that a link file that is not present in the initrd will never be
> able to cause a rename.
>
> [Solutions]
> There are a couple of ways we could fix this that come to mind:
>
> - make netplan generate a file in /run/udev/rules.d for each device
> - make systemd rename devices from a link file even if they've been renamed
>
> My preference is the first, but I'm open to anything we can get
> upstream.
>
> Thanks again.
>
> Regards,
> Daniel
>
> ** Attachment added: "journalctl -b output on Xenial VM with multiple renames"
> https://bugs.launchpad.net/netplan/+bug/1770082/+attachment/5139894/+files/journalctl-b.txt
>
> --
> 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
Sponsors Team, which is subscribed to the bug report.
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
More information about the Ubuntu-sponsors
mailing list