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