On Thu, 24 Dec 2020 08:47:17 -0500 Curtis Maurand via Dng <[email protected]> wrote:
> 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. Thanks, suspected something like this. Ciao, Tito > Sent from my iPhone > > > On Dec 24, 2020, at 8:24 AM, tito via Dng <[email protected]> > > wrote: > > > > On Thu, 24 Dec 2020 00:40:58 +0100 > > Didier Kryn <[email protected]> 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 > > [email protected] > > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > > _______________________________________________ > Dng mailing list > [email protected] > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
