[ebuild R ] sys-fs/eudev-1.10-r2::gentoo USE="hwdb keymap kmod modutils openrc rule-generator -doc -gudev -introspection (-selinux) -static-libs {-test}" ABI_X86="(64) -32 (-x32)" 0 KiB [ 11.059340] udevd[2628]: renamed network interface eth1 to eth125 [ 11.109176] udevd[2631]: renamed network interface eth0 to eth126 [ 11.149098] udevd[2631]: renamed network interface eth126 to eth2 even with net.ifnames=0 and /etc/udev/rules.d/80-net-name-slot.rules it just persistently renames to these not-really-useful names. And the eth125 device seems to generally not want to work.
Hi Patrick. There is no real practical solution around the problems of the old rule generator code and I had to eventually drop it in 3.0 and above. I'm going to be stabilizing 3.1.2 soon so can you give it a go.
Could you attach your /etc/udev/rules.d/75-persistent-net.rules (with MAC addresses redacted if you care) please? IIRC, net.ifnames=0 will stop the 70-persistent-net-generator.rules from doing anything but it won't stop /etc/udev/rules.d/75-persistent-net.rules or udev in general from trying to rename interfaces. This could be due to a failure of the write-net-rules script or a failure to update the rules file in /etc/udev/ afterwards.
(In reply to Ian Stakenvicius from comment #2) > Could you attach your /etc/udev/rules.d/75-persistent-net.rules (with MAC > addresses redacted if you care) please? > > IIRC, net.ifnames=0 will stop the 70-persistent-net-generator.rules from > doing anything No that's in 80-net-name-slot.rules which has IMPORT{cmdline}="net.ifnames" ENV{net.ifnames}=="0", GOTO="net_name_slot_end" It stops the predictable names. > but it won't stop /etc/udev/rules.d/75-persistent-net.rules > or udev in general from trying to rename interfaces. This could be due to a > failure of the write-net-rules script or a failure to update the rules file > in /etc/udev/ afterwards. The problem is in the renaming code itself in udev, not the write_net_rules script or the 70-persistent-net.rules it writes.
In this particular case I'm not so sure -- udev's iface rename code is supposed to rename all ifaces out of the way, and then either through the existing 75-persistent-net.rules or via write_net_rules + 70-persistent-net-generator.rules (if no previous rules exist) they get renamed back to a more normal iface name. Here, there are two interfaces being renamed away, and then only one renamed back (and its being renamed to eth2); this tells me that (A) the rules for eth0 and eth1 that might be in 75-persistent-net-generator.rules are old and don't match hardware, and (B) that the new rules that should rename these properly aren't being created, and/or processed by udev. If the issue was *just* the renaming inside of udevd, then the 75-persistent-net-generator.rules in /etc would include rules matching all of the hardware.
(In reply to Anthony Basile from comment #3) > > No that's in 80-net-name-slot.rules which has > > IMPORT{cmdline}="net.ifnames" > ENV{net.ifnames}=="0", GOTO="net_name_slot_end" > > It stops the predictable names. Actually that came in after 1.10-r2. I was just following on comment #0 and lost track of the releases --- just correcting my comment. (In reply to Ian Stakenvicius from comment #4) > In this particular case I'm not so sure -- udev's iface rename code is > supposed to rename all ifaces out of the way, and then either through the > existing 75-persistent-net.rules or via write_net_rules + > 70-persistent-net-generator.rules (if no previous rules exist) they get > renamed back to a more normal iface name. > > Here, there are two interfaces being renamed away, and then only one renamed > back (and its being renamed to eth2); this tells me that (A) the rules for > eth0 and eth1 that might be in 75-persistent-net-generator.rules are old and > don't match hardware, and (B) that the new rules that should rename these > properly aren't being created, and/or processed by udev. > > If the issue was *just* the renaming inside of udevd, then the > 75-persistent-net-generator.rules in /etc would include rules matching all > of the hardware. Yeah we need to see his /etc/udev/rules.d/70-persistent-net-generator.rules.
Yesterday I deleted that file as it now contained (1) 5 entries for eth1 and (2) rules for eth0 naming it eth2 I have no idea where that last wrong renaming rule came from, and why eth1 didn't stay eth1 as before. It did work for a few years without obvious breakage ... Now things work: # ls /etc/udev/rules.d/ 80-net-name-slot.rules
