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?
::
Re: [DNG] if2mac init.d service for…
