| 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 |
Archives