The officially official Devuan Forum!

You are not logged in.

#1 2024-06-13 18:44:40

Registered: 2022-08-27
Posts: 44  

daedalus: network interface names changing with (nearly) each boot

I have no clue, what causes this, but the network interface names are changing often.
So, for this cases, there were no software or hardware changes applied.
I am using daedalus, devuan5, with ZFS on root, using kernel:

6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux

on a ASRock X570M Pro4.
The situation is to see, if one looks into '/sys/class/net', here two examples.

##Previous boot:

##eth0 -> ../../devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:02.0/0000:04:00.0/net/eth0    <==
##eth1 -> ../../devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:04.0/0000:06:00.0/net/eth1
##eth2 -> ../../devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:04.0/0000:06:00.1/net/eth2
##eth3 -> ../../devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:06.0/0000:08:00.0/net/eth3
##eth4 -> ../../devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:02.0/0000:04:00.1/net/eth4

##Current boot:

eth0 -> ../../devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:04.0/0000:06:00.0/net/eth0/
eth1 -> ../../devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:04.0/0000:06:00.1/net/eth1/
eth2 -> ../../devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:06.0/0000:08:00.0/net/eth2/
eth3 -> ../../devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:02.0/0000:04:00.0/net/eth3/   <==
eth4 -> ../../devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:02.0/0000:04:00.1/net/eth4/

How can this be fixed?
BTW, the 0000:08:00.0 is the mainboard interface, which I use as basic interface for LAN access.
I could list the pci-device order (and have saved it), but there are never changes.
This is not a desktop, and this behavior makes ssh access impossible!



#2 2024-06-14 00:45:39

Registered: 2016-11-25
Posts: 2,456  

Re: daedalus: network interface names changing with (nearly) each boot

This is why they invented Predictable Network Interface Names. … faceNames/

In debian, with udev you get the new names (enpblahblahblah) unless you boot with 'net.ifnames=0' to preserve the old names (eth0...)

In devuan, with eudev you get the old names (eth0...) unless you boot with 'net.ifnames=1'.   Add that to the boot command in /etc/default/grub like this:


and then run update-grub

You will need to edit any scripts you've written that reference the interfaces by the old names.


#3 2024-06-14 14:32:20

From: Ortenau
Registered: 2021-04-25
Posts: 101  

Re: daedalus: network interface names changing with (nearly) each boot

In devuan, with eudev you get the old names....

Thanks for the good explanation.

How can I find out, what the interfaces will actually be called without modifying the _cmdline_?
and then modify the relevant files  (sed ... s/eth0/enpxxx/ somefile)
If I could give it a try modifying / restarting without loosing connection to my remotes without screen?

The devil, you know, is better than the angel, you don't know. by a British Citizen, I don't know too good.
One generation abandons the enterprises of another like stranded vessels. By Henry David Thoreau, WALDEN, Economy. Line 236 (Gutenberg text Version)
broken by design : … bug=958390


#4 2024-06-15 00:03:48

From: Battery Point, Tasmania, AUS
Registered: 2016-11-30
Posts: 1,190  

Re: daedalus: network interface names changing with (nearly) each boot

A good alternative would be to install and use ifrename. Possibly easier and safer. You would then pick your own name series and declare the mapping from PCI bus addresses to your names.

Install and check out its man pages (ifrename and iftab).

EDIT: with ifrename you would not have add that boot parameter.


#5 2024-06-15 00:18:36

Registered: 2022-08-27
Posts: 44  

Re: daedalus: network interface names changing with (nearly) each boot

Hello All!

Thanks, @fsmithred!
I followed this advice, event though it shows another theme!
My problem was not old/new naming convention, but changing interface names between boot - not daily though
and a quick reboot is not an answer. But I looked at this kernel commandline option and it seems not to have any effect!
But I found 70-persistent-net.rules, something, I've not regarded before.
Astroundingly, the mapping, applied in this file, does NOT fit the reality completely, there is an exception for one interface.
Then I changed the rules/names, but the problem persists. Then I enabled udev debug logging and saw, that the interface,
which hasnt followed the rule, was renamed two times: From eth0 to eth2, the from eth2 to eth3.
"Predictbale interface names" .....
Anyway, which kernel commandline applied.
Additionally, I found, that there COULD be "net.naming-scheme=v250", according to this thread:
udevd produce same ID_NET_NAME_SLOT for different NIC, so break rename #28929 :
But from this thread, I found a hint: "udevadm test-builtin" and I used it like this:

$ udevadm test-builtin net_id /sys/class/net/gif0 (where gif0 is now my 10GbE-IF)
calling: test-builtin
=== trie on-disk ===
tool version:          3
file size:         9709412 bytes
header size             80 bytes
strings            2419020 bytes
nodes              7290312 bytes
Load module index
ID_OUI_FROM_DATABASE=Fujitsu Technology Solutions GmbH
Unload module index

This <enp4s0f0> (under: ID_NET_NAME_PATH) is probably the original IF-name and could explain, why
the "70-persistent-net.rules" cannot work:
ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3" - because they trigger (not!) on interface
names, which do not exist?
After I enabled udev debug logging, I have to look deeper at systemstart in the next days.
So wether "net.naming-scheme=v250" nor "net.ifnames=1" made something!
To udev logging: The shown output ("=== trie on-disk ===") appears in LSPCI too:

08:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)
=== trie on-disk ===
tool version:          3
file size:         9709412 bytes
header size             80 bytes
strings            2419020 bytes
nodes              7290312 bytes

at the end of the list of network cards.

For the moment, I choosed a completely different set of names (eno0 for MoBo-IF, eif<N>
for the ethernet (better: 1Gbe) and gif<N> for the 10GbE interfaces. And these coming - at least
for the moment - up with exactly this names without any problem.

The drama will probably start, if I now start setting the "sriov_numvfs"
variable to get man VFs (asked a question in another part of this forum).


Board footer