udev: interface name in link file not applied

[daxtens]

systemd version the issue has been seen with
v237

Used distribution
Ubuntu 18.04

Expected behaviour you didn't see
I have a link file with the following contents:

[Match]
MACAddress=52:54:00:69:1d:5b

[Link]
Name=myif3
WakeOnLan=off

I expect to see that when I boot, the interface is renamed to myif3.

Unexpected behaviour you saw

The interface is not renamed, it stays as ens3.

This usually breaks networking because other parts of the system assume the interface was renamed.

Steps to reproduce the problem

• Create a virtual machine. (I use uvtool, but it doesn't really matter.)
• If using Ubuntu 18.04, the simplest way to demonstrate this is to change /etc/netplan/50-cloud-init.yaml and change the set-name: yaml key to myif3. Then reboot.
• If not using Ubuntu 18.04, create a link file that sets the Name of a Link, and reboot.
• The interface is not renamed (as a result, network connectivity is probably broken.)

Further Information

I've done further analysis on this.

The interface will be renamed if the link file is in the initrd, but not if the file is absent from the initrd.

Firstly, systemd-udevd renames the interface when running out of initrd. If the link file is in the initrd, it will be read and applied at that time. If the link file is not in the initrd, systemd-udevd will rename the device anyway according to NamePolicy. This will usually be a PCI slot id - here ens3.

Once we leave initrd and get to the normal root file system, the systemd-udevd daemon will be started. This will also consider the link file, but because the interface has been renamed, the name_assign_type will be NET_NAME_RENAMED (4), so should_rename will return false and the device won't be renamed again. This is the cause of the unexpected behaviour.

I think should_rename should allow NET_NAME_RENAMED to be overridden; at least when there's a specific name given in the link file.

[daxtens]

Just to expand on this a bit: this behaviour of link files is in contrast to the behaviour of rule files: in udev-event.c, interfaces with a rule that sets their name are renamed unconditionally with this call to rename_netif.

[arvidjaar]

Arguably this is a bug in initramfs generator that should have included corresponding link file. dracut normally adds all /usr/lib/systemd/network/*.link and additionally /etc/systemd/network/*.link in host-only mode.

[daxtens]

I considered that in my earlier debugging (https://bugs.launchpad.net/netplan/+bug/1770082)

I have one situation where a fix to the initramfs generator won't be sufficient.

Say you create a virtual machine (say an OpenStack or cloud guest). The Ubuntu initialisation process (cloud-init) for these guests creates a network configuration, but doesn't run update-initramfs (the debian dracut). So you end up with the network configuration installed on the root fs but not the initramfs. I don't know why cloud-init doesn't run update-initramfs; I suspect it's because compressing an initramfs is very slow.

Now say you shutdown the guest and change some properties - perhaps change the slot of the ethernet card, from slot 3 to slot 10. (Alternatively on some cloud platforms you can change the instance type which will change the way the ethernet device presents.)

Now you have a situation where things will be different based on whether you have a rule or a link file.

• If you have a rule file, the device will be renamed in initrd from eth0 -> ens10, and then in the root file system it will be renamed again from ens10 -> ens3. Then network configuration that expects the device to be named ens3 will work and the instance will remain accessible.

• If you have a link file, the device will be renamed in initrd from eth0 -> ens10, but then in the root file system, the interface will not be renamed again, because it has already been renamed. This will leave the device as ens10, any network configuration that relies on the name will fail, and the instance will probably not be accessible over the network.

Is there a reason link files and rule files should operate differently, and could we make the behaviour consistent?

[yuwata]

If your system does not require network stack during initrd, then how about disabling dracut network module or pass net.ifnames=0 to the kernel command line?

If it requires network stack, then there are at least two choices:

1. add net.ifnames=0 ifname=_networkname_:_mac_address_ ip=_networkname_:dhcp or something to the kernel cmdline.
2. rebuild initrd to include the link files.

The first choice is what I use, because I do not want to rebuild initrd so often.

[daxtens]

net.ifnames=0 does work as a workaround, but I'm looking for a long term solution based on the behaviour of rules vs link files.

Here's the context: In Ubuntu 16.04, the first-boot network configuration system created a .rule file. Ubuntu 18.04 introduced a new network configuration system that makes .link files instead. We then noticed that interfaces were no longer being renamed.

I verified that it's not related to any other changes between 16.04 and 18.04: I created a rules file on 18.04, and that caused the interface to be renamed as expected - even if the rules file was not in initrd.

Therefore, I'm trying to figure out if link files should operate the same way as rules files and override previously set names.

(With regards to initramfs, neither the rules nor the link file get built into the initrd until at least the next time update-initramfs is run - normally this doesn't occur until the kernel or other early-boot stuff is upgraded, which often doesn't happen for ephemeral cloud instances. So the question comes down to what the correct behaviour should be after you've pivoted to the real root.)

[raharper]

Can someone comment on why if the rename is encoded in a .rules file systemd-udevd will apply the rule (without requiring the rule to be in the initramfs no less), but if the equivalent is in a .link file it isnt? That's the core issue we're looking at here. What's the rationale for the differing behavior w.r.t interface renaming between .rules and .link files?

[poettering]

Well, .link files are newer, and declarative, while rules files are more imperative.

Generally we follow the rule to not override user choices again and again, and hence apply naming only one.

To me this appears a shortcoming of the tools in use. .link files should really be included in the initrd i guess... This is necessary in particular as network devices can't be renamed as soon as they are up, and there's a good chance they might be upped in the initrd again.

Hence, I am pretty sure this is something to work on with your distro: they should ensure that if .link files change the initrd is updated too.

[raharper]

We're generating .link files and network configuration on-the-fly during boot, but outside an initramfs. We also need this to work when booting without an initramfs. The generation time happens before networking is configured, so it's perfectly fine to apply different interface names above distro/systemd policy.

If .link files are only useful if they are in place prior to udev starting, that does present a problem for generating .link files dynamically during boot. That certainly imposes a lot on tools wishing to generating them: run before udev or reboot to apply.

Would it not be possible to preserve the "don't rename after the interface is up" while allowing .link files to apply even if already named once?

Users don't generally write directly to the initramfs so newly generate .link files with properties would end up being present on the rootfs first, needing to be copied into the initramfs and a reboot triggered to update an interface name. We could avoid the update and reboot if we could apply .link files to downed interfaces.

[poettering]

Well, you also have the option to simply not apply any renaming at all in the initrd, i.e. remove /usr/lib/systemd/network/99-default.link from the initrd. The issue after all is caused because that file is included in the initrd, but no others are, and hence it takes effect even though others will become available during later boot

[raharper]

Equally caused by ignoring additional .link files if udev has already processed renames once.

The use-case where a user would like to rename an interface while it is down but without rebooting is not addressed by leaving .link files out of the initramfs. Surely users can use the ip command to do the rename but then was was the point of having the .link files around if they cannot be used to control things they purport to control?

You mentioned the "not to override user choices again and again"; I think it's quite hard to determine whether the first .link files that udev processes are actually the users choice. It certainly feels quite hard to enact the users actual choice in these scenarios. Why is it OK to allow the user to update there .network files with different configuration and restart Networkd to have that apply, but changing the interface name when it is down is "overriding the users choice" ?

[daxtens]

Would a NamePolicy that allows link files to override previously set names be acceptable?

[mmjo]

Things seem to work when i change the NamePolicy in the initrd file /lib/systemd/network/99-default.link to
NamePolicy=kernel

Leaving out the other NamePolicy-options, prevents renaming in the initrd fase.
Which allows later renames from .link files/netplan.

[raharper]

We only need to allow interfaces which have requested a rename via .link files to be renamed. Changing the default policy means all interfaces will have kernel names rather than just affecting the interface that was requested to have a specific name.

[mmjo]

Yes, but this NamePolicy=kernel setting is only to be changed in the initrd.
Then, in the normal boot fase, interface renames with e.g. netplan's set-name seems to work fine.
The original NamePolicy is still applied.
But not twice, which seems to be a problem.

[raharper]

IIUC, Ihaving the kernel names in the initramfs means we won't get any renames; then when we mount root, the Namepolicy on disk will apply, but since we've not performed any renames in the initramfs then set-names will work. That's worth confirming on a system with multiple nics where we set-name only one of the two.

There is still the fundamental question as to why .link renaming is different than any other networkd setting here which can be applied after restarting Networkd.

[mmjo]

That is also my understanding.
Although it seems logical, this needs testing indeed.
Unfortunately, i have no systems with two network cards.

I am not sure about the fundamental part. Just that renaming an interface which is already up, is problematic.

[mmjo]

Possibly useful code snippet, image as on Ubuntu 18.04:

## unpack into current directory:
{
	cpio -id
	zcat | cpio -id
} < /boot/initrd.img-4.15.0-22-generic 

## now make mods ... 

## repack:
{
	find kernel | cpio -o -R +0:+0 -H newc
	find . -path ./kernel -prune -o -print | cpio -o -R +0:+0 -H newc | gzip -c
} > /boot/initrd.img

Then reboot and in the grub bootloader edit the initrd part to /boot/initrd.img

[raharper]

VMs are your friend for multiple nics; I can confirm the behavior.

Note that we're not looking at renaming any interface that is already up.

[mmjo]

Nice to see that confirmed!

Thus, the solution/fix seems to lie with the distribution.
Ubuntu/launchad ticket

[raharper]

I've not yet confirmed, I was indicating that I can perform the confirmation.

I don't agree that the solution/fix is in the distro itself; there still remains the unexplained behavior difference on why .link files cannot be used to apply a rename; For a downed interface, we can apply any amount of network related changes, MTU, or WakeOnLan, and general network configuration, but the name of the interface is somehow excluded from allowing runtime changes via .link files.

[mmjo]

I see your point. Excluding name changes seems unnecessary policy.
Overriding the user is not so much of a problem: these are likely to be different users.
One is distributor/author of the initrd, the other is the sysadmin writing netplan/.link files.

I am not sure, but the initrd-fase may have an interface up. Could that be problematic?

Though, i think that, even when runtime interface name changes were allowed,
the initrd should have the NamePolicy=kernel fix.

[cyphermox]

Is there really a need for a new NamePolicy= to handle this?

Seems to me like there is some disconnect between what I've been told on another issue and what we're discussing here. Elsewhere, I've been told "systemd-networkd wants to manage the network completely". To me this also reads as "if there's a .link file, doesn't matter if the user renamed their interface elsewhere, we want the name in the config applied". I think this tends to somewhat circumvent the idea of name_assign_type. I tend to agree that systemd-networkd should be authoritative on the state of the interfaces it controls, so having what's in .link files always be in effect sounds like the right thing to do in this case.

I think it should be fine to always apply the naming specified in .link, even if an interface has already been renamed: with that being the case, users renaming an interface using the 'ip' command are obviously on their own, but the change is also non-persistent for reboots. Users who really want to rename interfaces at boot elsewhere than in a .link file can still do so via udev rules in the appropriate location (ie. after 80-net_setup_link.rules, so it happens after .link files); otherwise .link files can be used and will obviously be honored.

To add to this, netplan tends to be affected by this a bit more since we don't want to write files elsewhere than in /run -- the configs are meant to be "dynamic", created by a systemd generator at boot based on the yaml config (the YAML config is static in /etc; but resulting networkd/NetworkManager config doesn't need to be). And with things written in /run and being dynamic, we obviously don't want to add /run to the initramfs-tools hooks for udev ;)

I have a tiny patch that just drops should_rename() and seems to achieve just the right behavior.

[xnox]

Imho explicit user configuration of custom interface names should be honoured.
Imho declarative specification of a custom interface name, should trump a non-declarative one.
Thus explicit names specified in the declarative .link files should be always applied.

[msekletar]

I agree with @xnox. I see absolutely no reason to disregard the explicit user configuration. The current behavior is just confusing since all options from the link file are applied except Name.

Also, I don't understand what problem was this code trying to fix, to begin with.

[ghost]

Dear colleagues,

I'm facing a different behavior with renaming interfaces: with net.ifnames=0 biosdevname=0 in GRUB command-line, changing the /etc/systemd/network's ".link" file (Match MACAddress=, Link Name=wan1) successfully renames interface upon boot (e.g. eth0 -> wan1):

2: wan1: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN group default qlen 1000
    link/ether 96:6b:a8:16:20:66 brd ff:ff:ff:ff:ff:ff

but it seems that corresponding .network file (Match Name=wan1, Network ...) is ignored since no IP configuration appears on interface. Just manual "systemctl restart systemd-networkd" (no changes to existing config files) solves the issue with IP-configuration. And interesting is that if I match interface (in .network) not by name but by MAC (as in corresponding .link), no renaming happens, so after reboot it appears with IP configuration but as eth0.

No other changes against standard Ubuntu's 18.04 configuration was applied.

This happens on Ubuntu 18.04 w/ Systemd 237-3ubuntu10.3.

[yuwata]

@doka-ua I think your issue is already fixed by #8795 which is included in v239.

[shixudong2020]

A question about #11436
my english is poor,I am newbie to udev,and I'm studying udev rules and net_setup_link.
on the surface,
before fix to #9006,if name_assign_type is NET_NAME_USER or NET_NAME_RENAMED, in #11436 lan0 cannot renamed to ens3,
after fix to #9006, in #11436 lan0 can renamed to ens3 again,
after fix to #11436 with keep policy,lan0 cannot renamed to ens3.

my question is about 80-net-setup-link.rules
In 80-net-setup-link.rules,one of RENAME's conditions is NAME= is unset, after 70-persistent-net.rules,the NAME is set to lan0,so 80-net-setup-link.rules cannot rename lan0 to ens3 again even though without keep policy. Now 80-net-setup-link.rules still can rename lan0 to ens3 again,why?

[yuwata]

Please provide .link files you use, and also provide any relevant configs e.g. kernel command line option if you specify interface name in it. Also, if you invoke some commands to rename the interface, then also provide them.

Without such information, we have no way to solve your issue.

BTW, here is an upstream bug tracker. Do you really have any issues on interface renaming? Or just asking a question about the logic of interface renaming? If you just ask something, then here is not a good place to do that. Please use mailing list or read documents.

[shixudong2020]

@yuwata thank u,i‘m just asking a question about the logic of interface renaming.if use standard 80-net-setup-link.rules:
SUBSYSTEM!="net", GOTO="net_setup_link_end"
IMPORT{builtin}="path_id"
ACTION!="add", GOTO="net_setup_link_end"
IMPORT{builtin}="net_setup_link"
NAME=="", ENV{ID_NET_NAME}!="", NAME="$env{ID_NET_NAME}"
LABEL="net_setup_link_end"

Under #11436 circumstances,after apply /etc/udev/rules.d/70-persistent-net.rules:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="", NAME="lan0"
the interface name is renamed to lan0,
but because by 80-net-setup-link.rules rename need NAME=="",and now NAME="lan0",so it's impossible through any other .link file or 99-default.link(#11436 through /usr/lib/systemd/network/99-default.link) rename interface name from lan0 to ens3.
if mask 80-net-setup-link.rules, through any .link file rename interface name also disabled.
so my question is Under #11436 circumstances,how through /usr/lib/systemd/network/99-default.link rename interface name from lan0 to ens3?

[yuwata]

Hm? ATTR{address}==""?? The interface you want to name lan0 has no MAC address?? Strange.
I guess the line in /etc/udev/rules.d/70-persistent-net.rules is not applied to the interface.

Please try to check attributes with udevadm info --attribute-walk /sys/class/net/INTERFACE_NAME.

[shixudong2020]

sorry, Under #11436 circumstances,after apply /etc/udev/rules.d/70-persistent-net.rules:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="52:54:00:69:1d:5b", NAME="lan0"
I mean that 70-persistent-net.rules can applied to the interface,so the interface name is renamed to lan0.
but because one of 80-net-setup-link.rules RENAME's conditions is NAME= is unset,and now NAME is set to lan0,
so the interface name should not be renamed from lan0 to ens3 through 99-default.link.

[yuwata]

Please try to run udevadm test /sys/class/net/INTERFACE_NAME. If the output does not include something like the following, then the your custom rule does not applied.

INTERFACENAME: /etc/udev/rules.d/70-persistent-net.rules:99 NAME 'lan0'

In my case, (of course without your custom rules)

$ udevadm test /sys/class/net/wlp59s0
(snip)
wlp59s0: /usr/lib/udev/rules.d/80-net-setup-link.rules:11 NAME 'wlp59s0'
(snip)

[shixudong2020]

what’s u udev version?my version is 241-7~deb10u8,and only include link file line,not include rules file line
That's a digression

Under #11436 circumstances,through 70-persistent-net.rules interface can and have renamed to lan0

my question is about the logic of #11436 interface renaming,
one of 80-net-setup-link.rules RENAME's conditions is NAME= is unset,and now NAME is set to lan0,
so the interface name should not be renamed from lan0 to ens3 through 99-default.link.
Under #11436 circumstances,how through /usr/lib/systemd/network/99-default.link rename interface name from lan0 to ens3?

[yuwata]

my question is about the logic of #11436 interface renaming

Logic is simple. systemd-udevd renames interfaces with the value of NAME.
If the interface is renamed to ens3, then the final value of NAME is ens3, and lan0 is not assigned to NAME.
So, I am asking if your custom rule is certainly applied.

what’s u udev version?my version is 241-7~deb10u8,and only include link file line,not include rules file line

Gah,,, that's too old for here. Please use SYSTEMD_LOG_LEVEL=debug udevadm test /sys/class/net/ens3.

[shixudong2020]

I changed the true MAC of 70-persistent-net.rules,because 80-net-setup-link.rules RENAME's conditions is NAME= is unset,and 70-persistent-net.rules rename NAME to lan0,so the final name is lan0.I use SYSTEMD_LOG_LEVEL=debug udevadm test /sys/class/net/lan0. output(I specially customize /etc/systemd/network/99-default.link just only remove keep from NamePolicy):
Rules contain 393216 bytes tokens (32768 * 12 bytes), 32129 bytes strings
25726 strings (210823 bytes), 22631 de-duplicated (181790 bytes), 3096 trie nodes used
lan0: NAME 'lan0' /etc/udev/rules.d/70-persistent-net.rules:1
lan0: IMPORT builtin 'net_id' /usr/lib/udev/rules.d/75-net-description.rules:6
Using default interface naming scheme 'v240'.
lan0: IMPORT builtin 'hwdb' /usr/lib/udev/rules.d/75-net-description.rules:12
lan0: RUN 'ifupdown-hotplug' /usr/lib/udev/rules.d/80-ifupdown.rules:5
lan0: IMPORT builtin 'path_id' /usr/lib/udev/rules.d/80-net-setup-link.rules:5
lan0: IMPORT builtin 'net_setup_link' /usr/lib/udev/rules.d/80-net-setup-link.rules:9
Config file /etc/systemd/network/99-default.link applies to device lan0
link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
link_config: could not set ethtool features for lan0
Could not set offload features of lan0: Operation not permitted
lan0: Device has name_assign_type=4
lan0: Policy path yields "enp0s3".
lan0: RUN '/lib/systemd/systemd-sysctl --prefix=/net/ipv4/conf/$name --prefix=/net/ipv4/neigh/$name --prefix=/net/ipv6/conf/$name --prefix=/net/ipv6/neigh/$name' /usr/lib/udev/rules.d/99-systemd.rules:60
lan0: Failed to update tags under /run/udev/tag/, ignoring: Operation not permitted
lan0: Failed to update database under /run/udev/data/, ignoring: Permission denied
DEVPATH=/devices/pci0000:00/0000:00:03.0/net/lan0
INTERFACE=lan0
IFINDEX=2
ACTION=add
SUBSYSTEM=net
ID_NET_NAMING_SCHEME=v240
ID_NET_NAME_MAC=enx08002703e267
ID_OUI_FROM_DATABASE=PCS Systemtechnik GmbH
ID_NET_NAME_PATH=enp0s3
ID_BUS=pci
ID_VENDOR_ID=0x8086
ID_MODEL_ID=0x100e
ID_PCI_CLASS_FROM_DATABASE=Network controller
ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
ID_VENDOR_FROM_DATABASE=Intel Corporation
ID_MODEL_FROM_DATABASE=82540EM Gigabit Ethernet Controller (PRO/1000 MT Desktop Adapter)
ID_MM_CANDIDATE=1
ID_PATH=pci-0000:00:03.0
ID_PATH_TAG=pci-0000_00_03_0
ID_NET_DRIVER=e1000
ID_NET_LINK_FILE=/etc/systemd/network/99-default.link
ID_NET_NAME=enp0s3
TAGS=:systemd:
SYSTEMD_ALIAS=/sys/subsystem/net/devices/lan0
USEC_INITIALIZED=3706978
run: 'ifupdown-hotplug'
run: '/lib/systemd/systemd-sysctl --prefix=/net/ipv4/conf/lan0 --prefix=/net/ipv4/neigh/lan0 --prefix=/net/ipv6/conf/lan0 --prefix=/net/ipv6/neigh/lan0'
Unload module index
Unloaded link configuration context.

If I remove NAME=="" from 80-net-setup-link.rules,the final name can renamed to enp0s3.

so my question is Under #11436 circumstances,how through /usr/lib/systemd/network/99-default.link rename interface name from lan0 to ens3? After all customize 80-net-setup-link.rules through remove NAME=="" is too abnormal condition.

[yuwata]

Now, I am confused about what you expect. Which name lan0 or enp0s3 do you expect??

Again, the logic is simple:

1. udevd just renames interfaces with the value specified in NAME.
2. as you already said, 80-net-setup-link.rules does not override NAME if it is already set.

If you expect the interface is renamed to enp0s3, just drop your custom rules file /etc/udev/rules.d/70-persistent-net.rules.

If you expect lan0, then it seems your custom rules file seems to work.

=====
As I already said, here is an UPSTREAM bug tracker. But you use slightly old systemd (v241). Please do not ask any questions like this here any more, but please use our mailing list (though, I do not subscribe the list), or even asking to my personal Twitter account may be also ok. And only when if you find any issues in recent releases (currently v248 and v249), then file that in a new issue page.

This is the final message here I reply to you.