because system bios is running a version of embedded linux and it dynamically populates things at boot up. the only immutable bit is the interface’s mac.
Sent from my iPhone > On Dec 24, 2020, at 8:24 AM, tito via Dng <dng@lists.dyne.org> wrote: > > On Thu, 24 Dec 2020 00:40:58 +0100 > Didier Kryn <k...@in2p3.fr> wrote: > >> Le 24/12/2020 à 00:24, Antony Stone a écrit : >>>> Or maybe the kernel is much faster than Eudev and it has the >>>> time to create the interfaces faster than Eudev processes them. >>> That sounds likely. >>> >>>> But for sure the mechanism worked in the past. >>> I completely agree. >>> >>> As I said in my opening posting on the "Ethernet names revisited" >>> thread: >>> >>> | I'm trying to work out how to give those interfaces the names I >>> want; the | motherboard as eth0, and the PCI card as eth1 / eth2. >>> | >>> | Historically, I've been used to udev >>> and /etc/udev/rules.d/70-persistent- | net.rules doing this, where >>> I can specify the name I want for each interface | according to its >>> MAC address. >>> >>> By "historically" I meant "up to Jessie, and I think also Stretch / >>> Ascii". It's not doing the same in Buster / Beowulf. >> >> Maybe the kernel used to give a chance to udev to rename the >> interfaces and, for some reason, it stopped doing it. And the reason >> might be there's no point given the new fashion of naming the >> interfaces with complicated names. >> >> It remains possible to do what you want by the mean of a temporary >> name and permutations, or by the method of Tito which uses several >> temporary names, but is generic. But I agree it is irritating to not >> be able to use Udev since it's sitting there anyway. >> >> > Hi, > still I'm not satisfied by my approach as there are a few shortcomings > that I can think of: > > 1) if2mac does rename in the first pass only the interfaces in > if2mac.conf so if there are other interfaces or if they are added > later name collisions are still possible in the second pass. > A workaround could be to rename all existing interfaces but this > could leave some interfaces not included in the config file > half-renamed in the end or you need to rename them back to > the original name in a third pass (if the name is still available, > otherwise you need to find a arbitrary new one). > Still don't know how to handle this in a simple and clean way. > 2) I suspect that if you rmmod and insmod the nic's or wlan's > module the old names will be assigned by udev/eudev so some > kind of interaction with udev is still needed. > 3) it would be optimal to make it accept a config dir that can hold > multiple config files so that you can name some nics WAN* > some others LAN* and others OPT* but this would add even more > complexity. > > in the end it would be best to fix udev/eudev and let it handle it > like it did before. > A workaround could be to use names that differ totally from the > old and the "******* predictable names" like (LAN1, OPT1, WIFI1) > but changing of all configs is needed and this was what I wanted > to avoid when I started this attempt. > As we have 4 days of lockdown there is plenty time to think about it.... > > Ciao, > Tito > > BTW: I noticed during my test that even pci bus numbers can > change wildly in the predictable names case (vs MACS, > if I recall it correctly). > I thought that being tied to soldered sockets on the motherboard > they were immutable. Are they numbered on a first come > first served basis? or where is my error? > > > _______________________________________________ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng