1 |
On 2013-03-29, Samuli Suominen <ssuominen@g.o> wrote: |
2 |
> On 29/03/13 18:21, Nuno J. Silva (aka njsg) wrote: |
3 |
>> On 2013-03-29, Diego Elio Pettenò <flameeyes@×××××××××.eu> wrote: |
4 |
>>> On 29/03/2013 12:34, Chí-Thanh Christopher Nguyễn wrote: |
5 |
>>>> Diego Elio Pettenò schrieb: |
6 |
>>>>>> If my desktop only has one Ethernet interface, no matter how many kernel |
7 |
>>>>>> changes happen, it'll always be eth0. |
8 |
>>>> That was not true with the old persistent naming. One example which we |
9 |
>>>> encountered in #gentoo IRC was the split between e1000 and e1000e drivers |
10 |
>>>> which caused interfaces to change names. |
11 |
>>> |
12 |
>>> Okay let me re-qualify the statement: |
13 |
>>> |
14 |
>>> "If my desktop only has one Ethernet interface, and I don't mess up with |
15 |
>>> it in userspace at all, no matter how many kernel changes happen, it'll |
16 |
>>> always be eth0". |
17 |
>>> |
18 |
>>> Yes, the previous persistent rules for udev would have messed that one |
19 |
>>> up when e1000e got split, or if you switched between the |
20 |
>>> Broadcom-provided driver to the kernel one or vice-versa. The deathforce |
21 |
>>> drivers come in mind as well. |
22 |
>> |
23 |
>> IMHO this is really relevant. It is annoying seeing how many people go |
24 |
>> "oh you *must not* use the old scheme, because it won't work". |
25 |
>> |
26 |
>> The new naming scheme does *not* prevent you from using eth0, users |
27 |
>> should really just be told they can *disable* udev rules (and told how |
28 |
>> to do it) if they are happy with the kernel name of their sole network |
29 |
>> card, instead of being told that they *must* upgrade to the new rules. |
30 |
>> |
31 |
>> The messages so far seem to imply that you can't have eth0. You *can*, |
32 |
>> but udev won't be able to do anything if the device appears as |
33 |
>> something else and there's already another eth0. If you don't already |
34 |
>> have eth0, the udev rules *will* work, even if your card is named in |
35 |
>> the eth namespace. |
36 |
>> |
37 |
>> The *only* thing that breaks is renaming network devices to names that |
38 |
>> are already in use inside the kernel namespaces. |
39 |
> |
40 |
> I think you may have not seen the latest version, it says for eg. |
41 |
> |
42 |
> "If you only have one interface card, you don't necessarily have much |
43 |
> use for this feature as the name almost always stays at eth0, you can |
44 |
> easily disable it using forementioned methods." |
45 |
|
46 |
Yeah, I didn't. Checking the new version, it is definitely much better! |
47 |
Just two notes/questions: |
48 |
|
49 |
> If /etc/udev/rules.d/80-net-name-slot.rules is a empty file, or if it's |
50 |
> a symlink to /dev/null, the new names will be disabled and kernel will |
51 |
> do all the interface naming, and the resulting names will vary by kernel |
52 |
> and hardware configuration, and may vary by kernel version. |
53 |
|
54 |
IIRC, it can also vary from boot to boot, with the same kernel and |
55 |
hardware, if there is some kind of race condition. |
56 |
|
57 |
> Also, the forementioned old 70-persistent-net.rules might interfere with |
58 |
> the new enabling of the new predictable interface names! |
59 |
|
60 |
"might"? I never checked, but I thought that, in order to enable the new |
61 |
naming rules, one had to remove the 70-persistent-net.rules file from |
62 |
/etc. How does this work, exactly? |
63 |
|
64 |
> After first listing 3 different ways of disabling the new names earlier. |
65 |
> |
66 |
> http://sources.gentoo.org/gitweb/?p=proj/gentoo-news.git;a=blob_plain;f=2013/2013-03-29-udev-upgrade/2013-03-29-udev-upgrade.en.txt;hb=HEAD |
67 |
> |
68 |
> But I'd prefer not to lead people to the path of renaming into namespace |
69 |
> already taken... that can lead to issues. It sounds almost as hackish as |
70 |
> the script that frees the whole namespace by using temporary names: |
71 |
> https://bugs.gentoo.org/attachment.cgi?id=336774 |
72 |
|
73 |
Can, but only if there is more than one device using that namespace for |
74 |
their final names. I'm probably biased, because of having had udev |
75 |
configuration issues and having to hear half of the time "you *can't* |
76 |
use ethX", just because of the FUD. |
77 |
|
78 |
I'd say the key is more avoiding leading people to a different system of |
79 |
rules when they may be fine with the kernel namespace. Perhaps the |
80 |
approach should be more like: |
81 |
|
82 |
If you need persistent naming for some reason (such as two network |
83 |
devices in the same kernel namespace), you will need to change your |
84 |
rules and use namespaces that are not used by your kernel. This will |
85 |
also imply changing all relevant configurations (firewalling, init |
86 |
scripts) to refer to the new device names. |
87 |
|
88 |
If you do not need to avoid clashes (only one network device or more |
89 |
devices on separate namespaces (e.g. eth0 and wlan0)), you can just |
90 |
keep the current configuration. |
91 |
|
92 |
> Still trying to decipher people if there is more to adjust in the news |
93 |
> though, it doesn't have to be frozen as is, if you have better wording, |
94 |
> please provide a patch against the current. Thanks :) |
95 |
|
96 |
-- |
97 |
Nuno Silva (aka njsg) |
98 |
http://njsg.sdf-eu.org/ |