On Thu, 24 Dec 2020 08:47:17 -0500
Curtis Maurand via Dng <dng@???> 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 <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
>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
::
Re: [DNG] if2mac init.d service for…
