[SOLVED] Weird udev network interface renaming behaviour

satiricon · 2020-01-23 15:28:06

Hi everybody! First post here as I normally find the solutions I need without having to ask but now I have tried everything to no avail.

My problem is that udev for some reason is (randomly) unable to rename eth0 to enp1s0 at boot time.

I tried disabling everything network related. But I don't know why eth0 is still (sometimes, at random) getting up before udev is able to rename it.

Uninstalled dhcpcd.
Made sure systemd-networkd was disabled.
Disabled netctl

This is the log related to eth0:

journalctl -b | grep eth0

Jan 23 10:10:22 nova kernel: eth0: Identified chip type is 'RTL8106E'.
Jan 23 10:10:23 nova kernel: eth0: 0xffff9a94c1ae9000, 54:bf:64:3d:af:a6, IRQ 136
Jan 23 10:10:23 nova kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Jan 23 10:10:24 nova systemd-udevd[373]: eth0: Failed to rename network interface 2 from 'eth0' to 'enp1s0': Device or resource busy
Jan 23 10:10:24 nova systemd-udevd[373]: eth0: Failed to process device, ignoring: Device or resource busy
Jan 23 10:10:25 nova kernel: r8101: eth0: link up
Jan 23 10:10:25 nova kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

I'm still able to connect after logging in with.

dhclient eth0

But obviously netctl (if enabled) generally fails to connect.

This is my network card info:

01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL810xE PCI Express Fast Ethernet controller (rev 07)
	Subsystem: Dell RTL810xE PCI Express Fast Ethernet controller
	Flags: bus master, fast devsel, latency 0, IRQ 136
	I/O ports at e000 [size=256]
	Memory at d1204000 (64-bit, non-prefetchable) [size=4K]
	Memory at d1200000 (64-bit, prefetchable) [size=16K]
	Capabilities: [40] Power Management version 3
	Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [70] Express Endpoint, MSI 01
	Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
	Capabilities: [d0] Vital Product Data
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [140] Virtual Channel
	Capabilities: [160] Device Serial Number 01-00-00-00-36-4c-e0-00
	Capabilities: [170] Latency Tolerance Reporting
	Kernel driver in use: r8101
	Kernel modules: r8169, r8101

I was using the kernel module

r8169

but I installed

r8101

and blacklisted the former to see if there was any change but there wasn't.

Any help. Please?

Thank you!

Last edited by satiricon (2020-01-24 13:13:58)

seth · 2020-01-23 15:47:55

Mitigation: https://wiki.archlinux.org/index.php/Ne … face_names

Please post the complete journal, because w/o context we cannot possibly say what might have opened the device.

satiricon · 2020-01-23 15:57:42

Sure thing. Thank you!

https://gist.github.com/lorem/51ef5b08c … ddbea76c7c

I'll try disabling the Predictable Network Interface Names if I find no other solution.

Last edited by satiricon (2020-01-24 13:16:22)

Zod · 2020-01-23 16:06:56

$ systemctl list-unit-files --state=enabled

satiricon · 2020-01-23 16:08:56

acpid.service           enabled
autovt@.service         enabled
bluetooth.service       enabled
cpupower.service        enabled
dbus-org.bluez.service  enabled
getty@.service          enabled
laptop-mode.service     enabled
lock.service            enabled
plexmediaserver.service enabled
sshd.service            enabled
udisks2.service         enabled
remote-fs.target        enabled
8teras-awake.timer      enabled
youtube-pihole.timer    enabled

seth · 2020-01-23 16:10:51

Random guess: try https://wiki.archlinux.org/index.php/Haveged - I'll explain it if it works ;-)

satiricon · 2020-01-23 16:15:26

I installed haveged, enabled it and rebooted but unfortunately there is no change in the logs.

UNIT FILE               STATE  
acpid.service           enabled
autovt@.service         enabled
bluetooth.service       enabled
cpupower.service        enabled
dbus-org.bluez.service  enabled
getty@.service          enabled
haveged.service         enabled
laptop-mode.service     enabled
lock.service            enabled
plexmediaserver.service enabled
sshd.service            enabled
udisks2.service         enabled
remote-fs.target        enabled
8teras-awake.timer      enabled
youtube-pihole.timer    enabled

15 unit files listed.

Should I do something else with it?

Thank you!

Last edited by satiricon (2020-01-23 16:16:02)

satiricon · 2020-01-23 19:15:23

I went ahead and disabled the Predictable Network Interface Name.

ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules

The udev errors stopped (like expected) but linux is still unable to connect at boot.

Jan 23 14:02:41 nova kernel: eth0: Identified chip type is 'RTL8106E'.
Jan 23 14:02:43 nova kernel: eth0: 0xffffaea881b2d000, 54:bf:64:3d:af:a6, IRQ 137
Jan 23 14:02:43 nova kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Jan 23 14:02:45 nova systemd[1]: Starting Networking for netctl profile eth0...
Jan 23 14:02:45 nova network[2000]: Starting network profile 'eth0'...
Jan 23 14:02:45 nova network[2000]: The interface of network profile 'eth0' is already up
Jan 23 14:02:45 nova systemd[1]: netctl@eth0.service: Main process exited, code=exited, status=1/FAILURE
Jan 23 14:02:45 nova audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=netctl@eth0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Jan 23 14:02:45 nova systemd[1]: netctl@eth0.service: Failed with result 'exit-code'.
Jan 23 14:02:45 nova systemd[1]: Failed to start Networking for netctl profile eth0.
Jan 23 14:02:46 nova kernel: r8101: eth0: link up
Jan 23 14:02:46 nova kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

After I log in the interface (eth0) has a IPv6 address but no internet connection. If i try to restart the netctl profile, it fails and again the log says "The interface of network profile 'eth0' is already up".

So, I'm pretty much in the same situation. To get an internet connection I have to down the interface

sudo ip link set eth0 down

and restart the netctl profile

sudo netctl restart eth0

I'm wondering. What ADDRCONF(NETDEV_UP) is? Can I disable it? Should I?

seth · 2020-01-23 21:21:36

it fails and again the log says "The interface of network profile 'eth0' is already up".

That's indicative of concurrent network managing services, thoug you don't seem to have any enabled (but ran dhcpcd and netctl by hand??)

Did you try reverting to r8169 ?

satiricon · 2020-01-23 21:52:16

I'm not using dhcpcd I removed it and I'm running dhclient or netctl, that is configured to use dhclient, by hand after logging in.

I also tried reverting to r8169 but the result is the same. I tried as well the main linux kernel (I normally use linux-lts) but the result is again the same.

I can easily connect after logging in, but for the love of mine I want to know what exactly is wrong with this configuration. This behaviour just doesn't make any sense.

seth · 2020-01-23 21:57:16

Please post an updated system journal. Ideally dump it before any manual network manipulation.

satiricon · 2020-01-23 22:28:56

seth wrote:

Please post an updated system journal. Ideally dump it before any manual network manipulation.

Sure thing. Now everything is disabled (even the udev renaming) and I got back to r8101. The behaviour is pretty much the same. eth0 gets up at boot time for some unknown reason.

https://gist.github.com/satiricon/93fb9 … 6b0203f863

UNIT FILE               STATE  
acpid.service           enabled
autovt@.service         enabled
bluetooth.service       enabled
cpupower.service        enabled
dbus-org.bluez.service  enabled
getty@.service          enabled
lock.service            enabled
plexmediaserver.service enabled
sshd.service            enabled
udisks2.service         enabled
remote-fs.target        enabled
8teras-awake.timer      enabled
laptop-mode.timer       enabled
youtube-pihole.timer    enabled

14 unit files listed.

Thank you for your help!

Last edited by satiricon (2020-01-23 22:31:37)

seth · 2020-01-23 22:36:56

I can easily connect after logging in

I'm not sure whether there's a misunderstanding here.

Nothing in that log even tries to configure the network, though plex tries to use it.
If that's the problem, enable some network managing service (dhcpcd, netctl, …) and ensure the plexmediaserver.service relies on it (enable netctl-wait-online.service and ensure the plex service depends on the online status)

satiricon · 2020-01-23 22:44:09

seth wrote:

I can easily connect after logging in
I'm not sure whether there's a misunderstanding here.
Nothing in that log even tries to configure the network, though plex tries to use it.
If that's the problem, enable some network managing service (dhcpcd, netctl, …) and ensure the plexmediaserver.service relies on it (enable netctl-wait-online.service and ensure the plex service depends on the online status)

What I'm trying to accomplish is connecting on boot. I disabled netctl (which was working just fine until a couple of days ago) to make sure to show that there is no service trying to configure the network. But even then eth0 gets up...

If I enable netctl the log shows something like

Jan 23 14:02:41 nova kernel: eth0: Identified chip type is 'RTL8106E'.
Jan 23 14:02:43 nova kernel: eth0: 0xffffaea881b2d000, 54:bf:64:3d:af:a6, IRQ 137
Jan 23 14:02:43 nova kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Jan 23 14:02:45 nova systemd[1]: Starting Networking for netctl profile eth0...
Jan 23 14:02:45 nova network[2000]: Starting network profile 'eth0'...
Jan 23 14:02:45 nova network[2000]: The interface of network profile 'eth0' is already up
Jan 23 14:02:45 nova systemd[1]: netctl@eth0.service: Main process exited, code=exited, status=1/FAILURE
Jan 23 14:02:45 nova audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=netctl@eth0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Jan 23 14:02:45 nova systemd[1]: netctl@eth0.service: Failed with result 'exit-code'.
Jan 23 14:02:45 nova systemd[1]: Failed to start Networking for netctl profile eth0.
Jan 23 14:02:46 nova kernel: r8101: eth0: link up
Jan 23 14:02:46 nova kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

eth0 gets up before netctl tries to connect... and because of that netctl fails (udev failed to rename the interface for the same reason).

I'll try now to disable plex and reboot to see what happens...

seth · 2020-01-23 23:01:10

So it's brought up and at some later point down, next to plex, try to disable laptop-mode-tools.

satiricon · 2020-01-23 23:22:21

seth wrote:

So it's brought up and at some later point down, next to plex, try to disable laptop-mode-tools.

I disabled it but there's no change. The weirdest of all is that it's random behaviour. Sometimes both udev is able to rename the interface and netctl is able to connect at boot time.

Koatao · 2020-01-24 09:51:45

Hello,
I have the exact same problem from a month now (it started around xmas).
I was using r8169, and tried r8168 with no luck.

The only way to have a correct interface renaming is to reload the module (r8168 or r8169, it doesn't matter).

Here my log and info:

08:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTL8411B PCI Express Card Reader (rev 01)
	Subsystem: CLEVO/KAPOK Computer RTL8411B PCI Express Card Reader
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin B routed to IRQ 139
	Region 0: Memory at a4105000 (32-bit, non-prefetchable) [size=4K]
	Expansion ROM at a4110000 [disabled] [size=64K]
	Capabilities: <access denied>
	Kernel driver in use: rtsx_pci
	Kernel modules: rtsx_pci

08:00.1 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 12)
	Subsystem: CLEVO/KAPOK Computer RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 144
	Region 0: I/O ports at 3000 [size=256]
	Region 2: Memory at a4104000 (64-bit, non-prefetchable) [size=4K]
	Region 4: Memory at a4100000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: r8168
	Kernel modules: r8169, r8168

UNIT FILE                             STATE  
autovt@.service                       enabled
dbus-org.freedesktop.network1.service enabled
dbus-org.freedesktop.resolve1.service enabled
display-manager.service               enabled
dnscrypt-proxy.service                enabled
gdm.service                           enabled
getty@.service                        enabled
nftables.service                      enabled
systemd-networkd-wait-online.service  enabled
systemd-networkd.service              enabled
systemd-resolved.service              enabled
systemd-networkd.socket               enabled
remote-fs.target                      enabled
fstrim.timer                          enabled

14 unit files listed.

Journal (with module reload at the end): https://pastebin.com/863GitNN

EDIT: I may I found the culprit: laptop-mode-tools.
Even with a disabled state, I found out it still launch during boot time (because we have to explicitly disable it in the conf file, doing systemctl disable isnt enough). I have uninstalled it, and everything is back to normal.

I have reinstalled laptop-mode-tools, and modified /etc/laptop-mode/conf.d/ethernet.conf according to the right interface name, and it is fixed. So I guess you should try that.

Last edited by Koatao (2020-01-24 12:02:07)

satiricon · 2020-01-24 13:09:59

Koatao wrote:

EDIT: I may I found the culprit: laptop-mode-tools.
Even with a disabled state, I found out it still launch during boot time (because we have to explicitly disable it in the conf file, doing systemctl disable isnt enough). I have uninstalled it, and everything is back to normal.
I have reinstalled laptop-mode-tools, and modified /etc/laptop-mode/conf.d/ethernet.conf according to the right interface name, and it is fixed. So I guess you should try that.

Looks like you found it!

I went and added the right interface in ethernet.conf

ETHERNET_DEVICES="enp1s0"

The renaming started to work! However the interface was still getting up before netctl was able to connect and use dhclient to get an IP.

So I just disabled laptop-mode's control of ethernet:

# Control Ethernet settings?
CONTROL_ETHERNET=0

That worked! Now the interface is renamed by udev and netctl is the one getting the interface up. I rebooted a couple times to rule out the randomness of past tries and looks like it's working perfectly!

I'll go ahead and mark this thread as solved.

Thank you everyone!

Last edited by satiricon (2020-01-24 13:12:06)

Arch Linux

#1 2020-01-23 15:28:06

[SOLVED] Weird udev network interface renaming behaviour

#2 2020-01-23 15:47:55

Re: [SOLVED] Weird udev network interface renaming behaviour

#3 2020-01-23 15:57:42

Re: [SOLVED] Weird udev network interface renaming behaviour

#4 2020-01-23 16:06:56

Re: [SOLVED] Weird udev network interface renaming behaviour

#5 2020-01-23 16:08:56

Re: [SOLVED] Weird udev network interface renaming behaviour

#6 2020-01-23 16:10:51

Re: [SOLVED] Weird udev network interface renaming behaviour

#7 2020-01-23 16:15:26

Re: [SOLVED] Weird udev network interface renaming behaviour

#8 2020-01-23 19:15:23

Re: [SOLVED] Weird udev network interface renaming behaviour

#9 2020-01-23 21:21:36

Re: [SOLVED] Weird udev network interface renaming behaviour

#10 2020-01-23 21:52:16

Re: [SOLVED] Weird udev network interface renaming behaviour

#11 2020-01-23 21:57:16

Re: [SOLVED] Weird udev network interface renaming behaviour

#12 2020-01-23 22:28:56

Re: [SOLVED] Weird udev network interface renaming behaviour

#13 2020-01-23 22:36:56

Re: [SOLVED] Weird udev network interface renaming behaviour

#14 2020-01-23 22:44:09

Re: [SOLVED] Weird udev network interface renaming behaviour

#15 2020-01-23 23:01:10

Re: [SOLVED] Weird udev network interface renaming behaviour

#16 2020-01-23 23:22:21

Re: [SOLVED] Weird udev network interface renaming behaviour

#17 2020-01-24 09:51:45

Re: [SOLVED] Weird udev network interface renaming behaviour

#18 2020-01-24 13:09:59

Re: [SOLVED] Weird udev network interface renaming behaviour

Board footer