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