Gentoo Archives: gentoo-dev

From: "Nuno J. Silva (aka njsg)" <nunojsilva@×××××××.pt>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
Date: Fri, 29 Mar 2013 19:00:17
Message-Id: kj4oas$8qb$
In Reply to: Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt by Samuli Suominen
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."
46 Yeah, I didn't. Checking the new version, it is definitely much better!
47 Just two notes/questions:
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.
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.
57 > Also, the forementioned old 70-persistent-net.rules might interfere with
58 > the new enabling of the new predictable interface names!
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?
64 > After first listing 3 different ways of disabling the new names earlier.
65 >
66 >;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 >
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.
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:
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.
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.
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 :)
96 --
97 Nuno Silva (aka njsg)