Udev-197 and newer has implemented a default method of renaming network interfaces to predictable names [1]. udev-197 will disable this function for live systems, but enable it for new installs (thanks to vapier for the suggestion). This will not go into affect for new installs of course until this version of udev stabilizes. This bug is here to track any fixes we have to make before we can advise people that they can enable this by default. [1] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
A bit late question - as I've already managed to bring the system to workable state - but I'm still curious: if one of the later services depends on net and net is hotpluggable, how would I prod openrc into accepting a success on one of those hotpluggable services while ignoring the failure of the others ? Other than that, the predictable names seem to work, but it might be noteworthy to remind those who use netplugd to correct netplugd.conf. AFAICT, ifplugd seems to work without corrections, though I'm a reboot or two short from being significantly convinced.
Predictable network interface names worked for me with little trouble: Moved /etc/udev/rules.d/70-persistent-net.rules and /etc/udev/rules.d/80-net-name-slot.rules to root's homedir. reboot Used ifconfig -a to get the new interface names, matched the MACs with those in 70-persistent-net.rules. (e.g. eth0 became enp7s0) Moved /etc/init/net.ethN to net.<new if name> Modified /etc/conf.d/net, replacing ethN with <new if name> Stopped iptables, modified /var/lib/iptables/rules-save, replacing ethN with <new if name> Modified /etc/dhcp/dhcpd.conf, replacing ethN with <new if name> rc-update add net.<new if name> default reboot done Of course I had to be at the machine to do this as the machine had no network between the 2 reboots. The command in 80-net-name-slot.rules (udevadm test-builtin net_id /sys/class/net/ifname 2> /dev/null) returned nothing before me, before and after the changes :( This: # This functionality has not been tested with gentoo. In fact, we are aware that # things will break if you activate it. is a little concerning. A list of things known to break (while not exhaustive) might be useful ...
Well, I managed to do everything in a single reboot. Removed 80-*.rules, changed names in 70-*.rules (so they don't collide with eth*). Created new net.* scripts, removed old ones from runlevels, added new ones; changed all configs: conf.d/net, daemons, firewall (I use shorewall). Then rebooted and removed old init scripts. Done. On my laptop that was even easier (as networking is managed solely by NetworkManager; and I use systemd instead of OpenRC, BTW). I just removed 70-*.rules, 80-*.rules and that's it. I don't care about iface names—that's NetworkManager's job. This command in 80-*.rules is probably a bit misleading. Should have been written as “udevadm test-builtin net_id /sys/class/net/$(ifname) 2> /dev/null” or something like this. @BobbyK, I bet this is the problem you had.
@Kirill Elagin - doh! I read it as a literal command (i wondered why I didn't have a /sys/class/net/ifname file or directory). Maybe: for ifn in `ls -d /sys/class/net/*` ; do echo $ifn ; udevadm test-builtin net_id $ifn 2>/dev/null ; done might be more useful ... Armed with that I might have been able to get away with a single reboot (though chances are I'd have missed something). For the sake of completeness, in addition to the rc-updates, edits of conf for net, dhcpd and iptables, I also had to change the network configuration of my VirtualBox VMs, I'd imagine the same would be true for folks using VMware, KVM, etc.
Alright, I removed 70-*.rules and 80-*.rules. On my 3.1.0 failsafe kernel, the interfaces come up enp8s0 and enp9s0. However, on my 3.7.2 production kernel, I am reaching a login prompt with eth0 and enp9s0. Both kernels have the drivers built-in due to netconsole. Both interfaces are on the motherboard. # lspci | fgrep Realtek 08:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 03) 09:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 03) # ifconfig enp9s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 70.xx.xx.xx netmask 255.255.255.248 broadcast 70.xx.xx.xx inet6 fe80::21f:bcff:fe0d:6e31 prefixlen 64 scopeid 0x20<link> ether 00:1f:bc:0d:6e:31 txqueuelen 1000 (Ethernet) eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet6 fe80::21f:bcff:fe0d:6e30 prefixlen 64 scopeid 0x20<link> inet6 2xxxxxxxxx0 prefixlen 64 scopeid 0x0<global> ether 00:1f:bc:0d:6e:30 txqueuelen 1000 (Ethernet) I don't know what the difference is, and I'm uninterested in bisecting it. At this point, I will move to custom interface names to avoid the ambiguity. Just want to provide another datapoint.
I mentioned it so casually before that it almost got away from me. This behavior seems incompatible with netconsole. Since netconsole brings the interface up, it's already in use by the time udev gets to it, and it can't be renamed. That was the difference between my failsafe kernel and my production kernel. Should probably add a kernel config check for CONFIG_NETCONSOLE=y and warn on it with >=udev-197.
(In reply to comment #3) > Well, I managed to do everything in a single reboot. Removed 80-*.rules, > changed names in 70-*.rules (so they don't collide with eth*). Created new > net.* scripts, removed old ones from runlevels, added new ones; changed all > configs: conf.d/net, daemons, firewall (I use shorewall). Then rebooted and > removed old init scripts. Done. > On my laptop that was even easier (as networking is managed solely by > NetworkManager; and I use systemd instead of OpenRC, BTW). I just removed > 70-*.rules, 80-*.rules and that's it. I don't care about iface names—that's > NetworkManager's job. > > This command in 80-*.rules is probably a bit misleading. Should have been > written as “udevadm test-builtin net_id /sys/class/net/$(ifname) 2> > /dev/null” or something like this. > @BobbyK, I bet this is the problem you had. The workaround is meant for the case there the 80- file is still place. If it isn't in place, I'm not sure how the script from this bug behaves And I'm not sure if the file in place if you can rename then to eth* without this script. Test results would be nice. Only got 1 NIC here for testing...
(In reply to comment #7) > The workaround is meant for the case there the 80- file is still place. If > it isn't in place, I'm not sure how the script from this bug behaves > And I'm not sure if the file in place if you can rename then to eth* without > this script. > > Test results would be nice. Only got 1 NIC here for testing... I'm not sure what workaround and what script you're talking about. But anyway, if the 80-*.rules file is in place, this means that the whole udev new renaming logic is disabled, and you have two options: either you use 70-*.rules to get predictable names, or you end up with random eth* names. If you are using 70-*, then you shouldn't assign eth* names there as it is, basically, not supported by the kernel. In my case all interfaces are listed in the 70-*.rules file, so it doesn't really matter if I remove 80-*.rules or keep it, unless I add new NICs in which case removing this file gives me new-style names.
*** This bug has been marked as a duplicate of bug 411627 ***
*** This bug has been marked as a duplicate of bug 453494 ***
(In reply to comment #9) > > *** This bug has been marked as a duplicate of bug 411627 *** Sorry. Wrong marking here. See Comment #10 for real one.
WilliamH, this bug went a big off topic and was missing the Tracker KEYWORDS as well as note in the first comment about "no talking here -- file a new bug and make it block this one" was missing. Please file a new proper Tracker if you need we want one.
(In reply to comment #8) > (In reply to comment #7) > > The workaround is meant for the case there the 80- file is still place. If > > it isn't in place, I'm not sure how the script from this bug behaves > > And I'm not sure if the file in place if you can rename then to eth* without > > this script. > > > > Test results would be nice. Only got 1 NIC here for testing... > > I'm not sure what workaround and what script you're talking about. Bug 411627 is for keeping old 70- rules working if not going to http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames which we know isn't ready for production yet -> Hence the file is installed by default in /etc/udev/rules.d/80-net...
(In reply to comment #12) > WilliamH, this bug went a big off topic and was missing the Tracker KEYWORDS > as well as note in the first comment about "no talking here -- file a new > bug and make it block this one" was missing. Please file a new proper > Tracker if you need we want one. Apoligies if comments were not meant for this bug. The newly installed 80-net-name-slot.rules states: # If you do want to activate and help us come up with a migration plan, feel # free to do so and report bugs. # Your bugs should block the following tracker: # https://bugs.gentoo.org/show_bug.cgi?id=450938 and I wasn't sure where to report my positive findings other than here. Should I have opened bugs, and, perhaps more importantly, should I now open bugs, against dhcpd, iptables, etc and detail what I did to resolve the issues migrating to predictable network names?
Use bug. No talking there. If you have package failing, make it block the Tracker bug 450938 instead.
(In reply to comment #15) > Use bug. No talking there. If you have package failing, make it block the > Tracker bug 450938 instead. And this should say, "use the Tracker bug 454224" not 450938. Sorry, my clipboard is messing with me.
Would be nice if you pass 'note' about rc_depend_strict="YES" in rc.conf to news item because IMHO this default value may confuse during upgrade
