1 |
On 11/30/21 12:58 PM, Dale wrote: |
2 |
> What I noticed in dmesg is that it takes the old name, eth0 for |
3 |
> example, and then renames it to the new name. |
4 |
|
5 |
I don't know if it's the /kernel/ that does the renaming, or not based |
6 |
on the kernel parameter, or if it's something else very early in the |
7 |
boot that does the renaming. |
8 |
|
9 |
> Well, if one moves things around and eth0 becomes eth3 then doesn't |
10 |
> that mess up the new name as well? |
11 |
|
12 |
My understanding is that the new name is -- supposed to be -- based off |
13 |
of some property of the device. I assume that said property is from |
14 |
something akin to where lspci gets it's data. Probably something |
15 |
exposed in /proc and / or /sys via the actual driver that ultimately |
16 |
gets feed into the renaming routine. |
17 |
|
18 |
> That could be why you see the results you have.> It's hard to base |
19 |
> a name on something that is changing itself. |
20 |
|
21 |
My understanding is that the new name is supposed to be completely |
22 |
independent from and not derived using the old name. So the old naming |
23 |
should have no influence on the new name. |
24 |
|
25 |
> It would seem to me that if they were going to change things for real, |
26 |
> they would change what the kernel names it in the beginning and it uses |
27 |
> the name it was first given based on slot or something else unique. |
28 |
|
29 |
Agreed. As in have the driver instantiate the device with the new name |
30 |
from the outset. |
31 |
|
32 |
> In other words, have the kernel assign it enp2s3 or whatever when |
33 |
> booting and that is the only name it gets. |
34 |
|
35 |
Yep. |
36 |
|
37 |
I don't know /why/ or /where/ the failure is with the new names. I just |
38 |
know that I have seen instability in them. Seeing as how stability ~> |
39 |
predictability is the motivation for the rename, well, that's a failure |
40 |
in my opinion. |
41 |
|
42 |
Besides, it's a LOT easier to /just/ `tcpdump -nni eth0` when logging |
43 |
into a machine than it is to have to figure out the interface name first. |
44 |
|
45 |
That being said, I was okay with what CentOS 6.x did, where the new name |
46 |
was matched against the MAC address. I had eth0 based on MAC for |
47 |
outside and eth1 based on MAC for inside on a number of systems. |
48 |
|
49 |
|
50 |
|
51 |
-- |
52 |
Grant. . . . |
53 |
unix || die |