1 |
On 2013-04-02, Neil Bothwick <neil@××××××××××.uk> wrote: |
2 |
> On Tue, 2 Apr 2013 20:31:10 +0000 (UTC), Grant Edwards wrote: |
3 |
> |
4 |
>> In Flameyes blog, he showed an example of using udev rules pretty much |
5 |
>> identical to the ones I already had, so I couldn't figure out what was |
6 |
>> different (other than the default interface names, which still aren't |
7 |
>> really predictable). |
8 |
> |
9 |
> They are totally predictable, |
10 |
|
11 |
As long as you know the PCI bus IDs of the slots, which board is |
12 |
plugged into which slot, the PCI bus IDs of the USB controllers, and |
13 |
which USB ports are connected to which controllers, and so on. For |
14 |
most of us that equates to "not predictable". :) |
15 |
|
16 |
The one thing (AFAICT) that does sort of make them what I would call |
17 |
"predictable" is the support for BIOS labels for ports. I've never |
18 |
actually seen a machine that supported that. |
19 |
|
20 |
> since the names are specified in the rules, so you can predict what |
21 |
> the interface will be called, |
22 |
|
23 |
In _theory_ you can, but you need to gather a lot of very low-level |
24 |
information first. In practice, I bet nobody does that -- they just |
25 |
boot up the kernel and see what they get. |
26 |
|
27 |
> it's what the rules file says it will be called. However, the |
28 |
> important issue is persistence, whatever name an interface has is the |
29 |
> name it will always have. |
30 |
|
31 |
Until you move it to a different USB port or PCI slot. Names still |
32 |
aren't persistent (or, in practical terms, predictable), they're just |
33 |
based on a different parameter than they used to be. For some people |
34 |
the new 'prameter' is apparently more useful -- so I guess it's an |
35 |
improvement. |
36 |
|
37 |
> The rules renaming within the kernel namespace, eth, wlan etc, could |
38 |
> not guarantee that because of race conditions, and the so-called |
39 |
> persistent names from the new udev still cannot do the same for |
40 |
> devices that can be physically moved (mainly USB). |
41 |
> |
42 |
> The simplest solution is to do what the news item suggests, rename |
43 |
> the persistent-net rules file |
44 |
|
45 |
Why does the file need to be renamed? |
46 |
|
47 |
> and rename the interfaces within it to not clash with the kernel. |
48 |
|
49 |
So the kernel is still using the names eth[0-n]? And there's a race |
50 |
condition if I use the names eth[0-n] in my rules? Same as before? |
51 |
|
52 |
> That's all you need to worry about when going from 197 to 200, |
53 |
> upgrading from earlier versions means you should act on the parts |
54 |
> about DEVTMPFS and runlevel files. |
55 |
|
56 |
-- |
57 |
Grant Edwards grant.b.edwards Yow! My life is a patio |
58 |
at of fun! |
59 |
gmail.com |