Why would the name of an interface change?

General Linux Question
1

In my Void Linux I bring up a static ethernet link by having the following in /etc/rc.local

ip link set dev enp10s0 up
ip addr add 192.168.32.6/24 brd + dev enp10s0

that is until recently, when I discovered the interface was not working and NetworkManager was trying to control a new interface enp12s0.

I eventually deduced that the name of the interface had changed from enp10s0 to enp12s0.
So I disabled NetworkManager for enp12s0, changed what was in /etc/rc.local to enp12s0, and everything works again.

Why would Void Linux change the name of the interface?
The only hardware I have altered recently was a graphics card. Surely that would not cause the NIC to be renamed.
I have 2 ethernet ports, the other one is called eno1, and its name did not change? Both ports are on the motherboard.

2

That’s up to udev. I did not dig deep into udev so far, so I can’t tell it more detailed.

1 Like
3

seen this sort of thing happen all the time…

e.g. update from one Ubuntu release to another - and Canonical appear to have deciced that eth0 wasn’t complicated enough so they rename it (that’s probably arse about) to enp39s0…

Why? Did it fix something that was broken? No it BROKE some that didn’t NEED FIXING!

Seems to happen more often on debian derived distros, than Red Hat derived… but they’re not free of this either…

4

So Void is not alone with this issue.
@kovacslt says udev controls naming, so I guess updating udev triggers it.

How are we supposed to keep a manual config working if they keep shifting goalposts?

5

It’s about CentOS, but I think it conatins relevant info:

If I wanted to change the enp3s0 to eth0 on my Debian, I’d investigate the way it describes.

6

And some clue from Debian:
https://wiki.debian.org/NetworkInterfaceNames

Back in the nineties, eth0, eth1, etc were simply assigned by the kernel.

Why it was abandoned

At least in theory, if module probes completed in a different order, eth0 and eth1 might switch places on successive boots. As boot processes became less linear and interfaces became more hotpluggable this became more of a concern.

7

Thank you…
It would seem changing from legacy boot to uefi boot may have changed the naming
I can investigate, because I can boot either way at the moment… have efi boot on disk 1 and legacy boot on disk0.
That will be a nuisance if the name flipflops with boot method.

1 Like
8

I learned something today… :smiley:

1 Like
9

I recall reading something similar in the past. The good old days of eth0 and eth1 are gone. The new naming is supposed to be more flexible and predictable. I don’t think it is always more predictable or maybe consistent is a better word.

We can probably blame all the new network interface types. Now there are wireless and USB and probably more.

10

@kovacslt ,
I booted Void in legacy mode.
No, the NIC naming stayed at enp12s0
so boot method is not responsible for the name change

Devuan and MX both still call my NIC’s eth0 and eth1.
Void calls the primary interface eno1 and the second one enp12s0
so I guess software is responsible for the naming.

11

I found this explanation of the new naming conventions



Answer on "What does enp0s10 means?" question:

enp0s10:
| | |
v | |
en| |   --> ethernet
  v |
  p0|   --> bus number (0)
    v
    s10 --> slot number (10)

Source: udev-builtin-net_id.c on GitHub

My source

In my case, enp12s0, the slot number is zero because the NIC is on the motherboard, and it is the bus number that was changed from 10 to 12?

2 Likes
12

Thanks for the link. That looks like a good explanation. I saw something similar about 5 years ago.

1 Like