Fedora 36 suddenly changed name of network adapter from enpNNs0 breaking networkd configuration

Ask Fedora
1

This happened on a machine currently running Fedora 36, though it was installed at least 3 or 5 years ago, in other words: The network configuration hasn’t changed in years and the hardware configuration hasn’t changed either.

But one day, out of the blue, there was no network connectivity anymore.

The boot process took minutes because:

Job systemd-networkd-wait-online.service/start running (2min / no limit)

ip address listed both physical interfaces as down:

2: enp10s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether f4:6d:04:ab:cd:ef brd ff:ff:ff:ff:ff:ff
3: enp7s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether a0:36:9f:ab:cd:ef brd ff:ff:ff:ff:ff:ff

When I had to find out what’s wrong, I noticed that those interface names are new. The system uses systemd-networkd instead of NetworkManager, which was configured for enp11s0. So in /etc/systemd/network, there’s a file called enp11s0.network which starts with:

[Match]
Name=enp11s0

[Network]
VLAN=...

(The VLAN part is just to make it complete but it’s irrelevant here.)
This configuration literally worked fine for years until it suddenly broke someday. No hardware change was made, the last release upgrade was made half a year ago.

Why did Fedora suddenly change the name of the network adapter enp11s0 to enp10s0?

I thought these names were designed so they can be used because they wouldn’t change randomly like “eth0”? Is this assumption wrong now and if so, where is this documented? And I have to say, it seems like “eth0” would have been more reliable a name because if the order of eth0, eth1 etc. is defined by whichever device is found first on boot, those names shouldn’t change without a hardware change. Note that “eth0” still would’ve been the right name in this particular case if it weren’t renamed during boot:

# dmesg | grep enp10s0
[    3.567800] r8169 0000:0a:00.0 enp10s0: renamed from eth0

Again, who or what decided to rename enp11s0 to enp10s0? Sounds like nobody should use those names anymore and use the MAC address to identify interfaces?

2

Naming does not seem to be as predictable as you hope for:

On your machine no hardware has changed at all?

2 Likes
3

The interface names should mach the pci configuration. lspci will display that.

1 Like
4

On my system lspci shows

04:00.0 Network controller: Qualcomm Atheros AR93xx Wireless Network Adapter (rev 01)
06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)

and ip a shows

2: enp6s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
3: wlp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000

Note that the device name matches the pci bus address.

1 Like
5

Yes, from my original post:

So thanks for the links, but they all describe problems after hardware changes. I like the second link: According to Freedesktop, network names should be stable and someone answered: “Sorry, but you’ve been lied to.”

The only thing I can think of is that a USB device is occasionally connected but I’d be surprised if that had anything to do with the nic naming.

6

That’s interesting…
Although the hardware configuration has not changed recently, and although I have not found what might have changed, I’m seeing USB controllers in the list so I wonder if this could be caused by an external USB controller, for example the USB hub in a monitor.

7

I suspect the fact that file is there may be the cause of the problem.
My system has no files in /etc/systemd/network/ and has never had a config file for network since the networking was switched over to using systemd.

8

USB is not the original USB nowadays.

The same interface can be Thunderbolt, it can provide a PCIe interface, etc.

Please try to unplug your USB device and compare the lspci outputs with plugged in.

1 Like
9

So where else do you suggest I should put the networkd configuration, if not into such a config file? Please acknowledge that the configuration itself is not the issue, it worked fine for years.

10

I get that this seems to be a guessing game but which device should I unplug (of those that were previously connected while everything worked fine)? If I had to guess, I’d say that it’s probably the opposite and a device disappeared, one with a dev/bus number lower than 8 because 8 used to be the number in one of the nics that’s now 7, just like 11 is now 10. Wouldn’t disconnecting another device that’s listed before 7 cause these numbers to be decreased to 6 and 9 instead of reverting them to 8 and 11 like before?

11

If the usb device is the issue, and unplugging it makes that kind of change then it would be good to know. The only way I know to find out would be to do trial & error testing.

Unless you have an identified need for the config file then it really is not needed. If needed then the recommendation here seems best.

$ cat /etc/systemd/networkd.conf 
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it under the
#  terms of the GNU Lesser General Public License as published by the Free
#  Software Foundation; either version 2.1 of the License, or (at your option)
#  any later version.
#
# Entries in this file show the compile time defaults. Local configuration
# should be created by either modifying this file, or by creating "drop-ins" in
# the networkd.conf.d/ subdirectory. The latter is generally recommended.
# Defaults can be restored by simply deleting this file and all drop-ins.
#
# See networkd.conf(5) for details.
1 Like
12

This is the proper place for the .network files. These config files is used by systemd-networkd to set up the network. The .link files are used by udev to configure network devices including possibly to set the name of the devices as defined by the NamePolicy= setting. See man systemd.link for details.

In a default Fedora system you will use the NetworkManager to configure the network and thus there would be no .network files needed.

1 Like
13

You are right. The interface names just reflects the PCI addresses. I don’t know if these are set up by the BIOS or UEFI firmware, or by the linux kernel.

14

No offense but this isn’t helping and I’ve already said that it’s not about the network configuration of networkd, it’s about how the nics are renamed. In fact, I deliberately put an example with a VLAN setting in my original post to show how it’s used (and obviously, there are more files for the vlans etc.). None of this has to do with the original issue.

15

Yes and like I said before, there was no hardware change prior to this incident. There’s the occasional usb drive that’s connect every now and then but those devices would show up in lsusb, not in lspci. So I don’t know what I should be looking for.

Plus there’s a lot of guessing going on, some have suggested removing a device even though what happened must have already been caused by a device that disappeared hence 8 is now 7 etc. Even if my assumption is true, I have no idea which device that should be.

16

Any idea if this occured after a kernel upgrade?

You could try falling back to an older kernel and see if the devices change.

17

Hi, thanks for your comment. I like the idea because it is true that Fedora often ships kernel updates (as regular updates). However, the last dnf logs in /var/log/dnf.log* do not contain “kernel” and the current kernel was installed about half a year ago:

# ls -lrth /boot/initramfs-$(uname -r).img
-rw-------. 1 root root 47M Sep 21 21:21 /boot/initramfs-5.19.7-200.fc36.x86_64.img

So I’m afraid the answer would be no.

1 Like
18

You could also rewrite the .network file to match on the mac address:

[Match]
MACAddress=$Mac