On 05/08/2013 16:41, Bruce Hill wrote: > On Mon, Aug 05, 2013 at 04:31:44PM +0200, Marc Joliet wrote: >> Am Mon, 5 Aug 2013 07:59:09 -0500 >> schrieb Bruce Hill <da...@happypenguincomputers.com>: >> >>> If this is "the new kernel naming scheme of NICs", why this in dmesg: >>> >>> [ 4.725902] systemd-udevd[1176]: renamed network interface wlan0 to >>> enp0s18f2u2 >>> >>> It looks as if systemd-udev renamed the NIC to me. Can you explain? >> >> It already has been explained in the previous NIC renaming discussion: what's >> broken is renaming a device within the kernels internal namespace, which >> contains eth*, wlan* (and maybe others). The problem is that there is a race >> condition with the kernel when renaming ethX to ethY. What you *can* do is >> rename ethX to somethingelseX or somethingelseY, because then you are not >> racing >> against the kernel to hand out device names. >> >> This is explained on the website that also explains the new default renaming >> scheme used by udev. I (and IIRC others, too) already linked to it in in the >> old >> thread, and the relevant news item also referenced it, but here it is again: >> >> >> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ > > The fact is that udev renamed the NIC. For the average Joe with one NIC (very > large percentage of users) this is a non sequitur. For those of us with 2 or > more NICs, myself included, we have already setup our systems to use multiple > NICs for a purpose and configured the system so that nothing can/will/needs to > rename subsequent NICs. > > My point is don't say "the new kernel naming scheme of NICs", say "the new > systemd naming scheme of NICs". >
Let me see if I can clarify somewhat. eth0 can be considered the "kernel name" - the kernel named the NIC according to it's own rules using the info it had available. Kernel names depend on discovery order and to a lesser degree on the kernel code (a dev could change how things are done for example) enp0s18f2u2 can be considered the "userspace name" - it's derived from the slot the card is plugged into, and is set by udev. The kernel doesn't really care about this stuff, but you might. Most people think of their NICS on multi-NIC machines in terms of positions i.e. "third one on the left" and can't work with "whatever eth2 happens to be today" So why change this? Because you can't rely on ethX always being the same physical hardware. On a firewall or router, you absolutely need to rely on this. The udev scheme works around this by letting you specify exact rules that will always do what you want. Why was this changed rammed down your throat? Well, that is political. The udev maintainers (along with systemd) work for Red Hat. RH's market is almost totally servers, and big multi-nic ones at that. They really need consistent names, doubly so if the host is a virtualization host. The catch: RH (or more exactly the udev maintainer employed by RH) probably couldn't give a toss what you think or want, and went ahead and fixed their problem expecting you to "deal with it or shove off" Does all that fit better with what you see before you? [All of this is what I've inferred over months, it's my opinion in my words. You won't find this description with anyone else's name attached :-) ] -- Alan McKinnon alan.mckin...@gmail.com
