So the old inconsistency was a super-bad kind of inconsistency. The interfaces got named based on the order in which the devices were discovered. Which, on a lot of systems, meant that every boot was essentially rolling the dice on a race condition. If you only have one device, you're fine. If your devices consistently come up in the same order, you're fine. If there's jitter though then things can easily get messy, and do so unexpectedly.
The new naming scheme names devices based on where they show up on the bus. This has its own issues. It means that USB adapters get different names when plugged into different slots. It means that adding or removing other PCI bus devices can change the bus address and therefore the name of your network interfaces. I've seen motherboard firmware updates do the same. But, at least in theory, this inconsistency should be triggered by something you *know* about unless hardware is getting added and removed by someone else without your knowledge. If you only have one interface though and tweak your hardware regularly then you'll probably be happier to put it back to the old naming scheme because with only one device it should always be eth0. LMP -----Original Message----- From: Grant Taylor <[email protected]> Sent: Tuesday, November 30, 2021 12:34 PM To: [email protected] Subject: Re: [gentoo-user] Switching from eudev to udev, disaster. 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
