The procedure to assign interface names for >=sys-fs/udev-197 via the 70-persistent-net.rules file as documented here: https://bugs.gentoo.org/show_bug.cgi?id=453494 and elsewhere is not robust in that scenarios exist where the interface naming scheme fails to initialize an interface. My 70-persistent-net.rules file: --- # Firewire device 00e0810000270f3e) SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:e0:81:00:00:27:0f:3e", NAME="eth0" # PCI device 0x10de:0x0373 (forcedeth) SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:e0:81:71:ef:6a", NAME="eth2" # PCI device 0x10de:0x0373 (forcedeth) SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:e0:81:71:ef:69", NAME="eth1" --- My 80-net-name-slot.rules has all lines commented out. The init script (https://bugs.gentoo.org/attachment.cgi?id=336774) as been added to the sysinit runlevel $ rc-update | grep rename_ethX rename_ethX | sysinit CONFIG_DEVTMPFS=y is in my kernel $ grep CONFIG_DEVTMPFS /usr/src/linux/.config CONFIG_DEVTMPFS=y and udev was built as sys-fs/udev-197-r8 was built with the following: USE="acl gudev hwdb introspection keymap kmod (multilib) openrc -doc (-selinux) -static-libs" ABI_X86="64" I think that's it. The eth1 is the interface to which is attached an internet cable and has always worked pre udev-197 without a problem. When the interface is brought up correctly I see (ifconfig) eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet < SNIP >.12 netmask 255.255.255.0 broadcast < SNIP >.255 inet6 fe80::2e0:81ff:fe71:ef69 prefixlen 64 scopeid 0x20<link> ether 00:e0:81:71:ef:69 txqueuelen 1000 (Ethernet) RX packets 52912285 bytes 20270722546 (18.8 GiB) RX errors 0 dropped 65 overruns 0 frame 0 TX packets 32949608 bytes 34811016525 (32.4 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 16436 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 0 (Local Loopback) RX packets 6758 bytes 12098078 (11.5 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 6758 bytes 12098078 (11.5 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 However, if I repeatedly reboot my system - this is very tedious - here I have to Ctrl-Alt-F1 and then Ctrl-Alt-Delete during booting, then eventually I'm presented with a scenario where eth1 is _not_ brought up and I see (ifconfig) eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet < SNIP >.12 netmask 255.255.255.0 broadcast < SNIP >.255 inet6 fe80::2e0:81ff:fe71:ef69 prefixlen 64 scopeid 0x20<link> ether 00:e0:81:71:ef:69 txqueuelen 1000 (Ethernet) RX packets 13917 bytes 2085511 (1.9 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 44 bytes 3670 (3.5 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth2: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether 00:e0:81:71:ef:6a txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 16436 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 0 (Local Loopback) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 where < SNIP > is the XXX.XXX.XX for my ip. This repeated reboot is not just an exercise but resulted from experimenting because a first attempt to bring up the eth1 interface failed after the conditions mentioned above for >=udev-197 were satisfied. Now with the init script installed the failure to bring up an interface is less frequent than when the init script is not installed. And I have not been able to document a failure where the eth1 interface is not brought after more than 2 successive reboots. Perhaps a quirk of my system which has numerous nfs mount points but there are failures.
Either rename to free namespace like eth1 -> net0, eth0 -> net1, or use the new predictable network naming scheme The init script in the bug is a hack at most, and renaming to same namespace is not something we are going to support since upstream doesn't either If you have a fix for it, then you can attach a new one in bug 453494 for others to use, but it's not something to file a bug about, sorry And we are proceeding with the new predictable network scheme by default in 198 released today... which is the final fix to this *** This bug has been marked as a duplicate of bug 453494 ***
