I've noticed a problem regarding eth0 on my laptop. I've got the following setup: Two interfaces (wlp2s0 and eth0), using networkmanager for configuration (Plasma in this case). Because it's a laptop I'm using networkmanager (instead of networkd). Today I noticed that eth0 hasn't been up - for almost 5 days, since I updated systemd to 243-something. I haven't noticed before because the secondary interface (wlan) worked just fine - only ethernet doesn't. After downgrading to systemd-242-r6, ethernet is working again.
The presence of eth0 would suggest that udev isn't renaming the device properly. Have you customized the udev rules, or done something to deliberately cause udev to skip it?
(In reply to Mike Gilbert from comment #1) > The presence of eth0 would suggest that udev isn't renaming the device > properly. Have you customized the udev rules, or done something to > deliberately cause udev to skip it? Nope - the only thing I did was switch from net-misc/r8168 (where the interface was renamed) to the kernel module (r8169) after it became ready/usable (it caused network outages before). After the switch eth0 hasn't been renamed. Haven't set any specific udev rule.
I found something in the journal: Aug 17 09:20:09 carrie systemd-udevd[874]: /lib/udev/rules.d/84-nm-drivers.rules :10 Invalid value "/bin/sh -c 'ethtool -i $1 | sed -n s/^driver:\ //p' -- $env{I NTERFACE}" for PROGRAM (char 24: invalid substitution type), ignoring, but pleas e fix it. Aug 17 09:20:09 carrie systemd[1]: Started udev Kernel Device Manager. Aug 17 09:20:09 carrie systemd-udevd[902]: Using default interface naming scheme 'v243'. Aug 17 09:20:09 carrie systemd-udevd[902]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable. Aug 17 09:20:09 carrie systemd-udevd[902]: eth0: Failed to rename network interface 2 from 'eth0' to 'enp1s0f1': Device or resource busy Aug 17 09:20:09 carrie systemd-udevd[902]: eth0: Failed to process device, ignoring: Device or resource busy Well, that explains (sort of) it why eth0 hasn't been renamed - but I haven't any custom udev rules, so all rules are coming from packages. However, the problem stil remains - eth0 is being ignored when using systemd >242
Can you remove /lib/udev/rules.d/84-nm-drivers.rules and see if that changes any thing?
(In reply to Mike Gilbert from comment #4) > Can you remove /lib/udev/rules.d/84-nm-drivers.rules and see if that changes > any thing? Done, rebooted, nothing has changed: Aug 17 20:05:50 carrie systemd[1]: Started Load/Save Screen Backlight Brightness of backlight:intel_backlight. Aug 17 20:05:50 carrie systemd-udevd[902]: Using default interface naming scheme 'v240'. Aug 17 20:05:50 carrie systemd-udevd[902]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. Aug 17 20:05:50 carrie systemd-udevd[902]: eth0: Failed to rename network interface 2 from 'eth0' to 'enp1s0f1': Device or resource busy
Ok, so I suspect some other program is enabling eth0 before udev has a chance to rename it. I would need to know more about what is running on your system.
(In reply to Mike Gilbert from comment #6) > Ok, so I suspect some other program is enabling eth0 before udev has a > chance to rename it. I would need to know more about what is running on your > system. Finally found the culprit which prevented the renaming: I'm using dracut for full-disk encryption. Unknown to me dracut installed - by default - two modules, network and network-manager which enabled eth0. After disabling both modules the renaming worked fine - oh, and systemd/networkmanager was able to use the now renamed interface enp1s0f1 again. This also explains why the renaming problem didn't occur when using net-misc/r8168 - the modules was activated later in the boot process, so dracut couldn't interfere.
(In reply to Mark Nowiasz from comment #7) > (In reply to Mike Gilbert from comment #6) > > Ok, so I suspect some other program is enabling eth0 before udev has a > > chance to rename it. I would need to know more about what is running on your > > system. > > Finally found the culprit which prevented the renaming: I'm using dracut for > full-disk encryption. Unknown to me dracut installed - by default - two > modules, network and network-manager which enabled eth0. That sounds odd; the presence of those modules shouldn't cause any problems. They should be dormant unless you have taken some action to enable them at boot. I think people generally do this via a kernel command line setting (netroot=...) or something similar. Anyway, closing this bug since this seems to be some configuration issue.
