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@???> wrote:
>
> On Thu, 24 Dec 2020 00:40:58 +0100
> Didier Kryn <kryn@???> 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@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
::
Re: [DNG] if2mac init.d service for…
