:: Re: [DNG] My Qemu LAN-peer document…
トップ ページ
このメッセージを削除
このメッセージに返信
著者: g4sra
日付:  
To: dng@lists.dyne.org
題目: Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, March 3, 2021 3:21 PM, tito via Dng <dng@???> wrote:

> On Wed, 03 Mar 2021 14:52:57 +0000
> g4sra via Dng dng@??? wrote:
>


> > <-- huge snip -->
> > Just for completeness should someone dig this thread up trying to
> > solve an issue...such as a 12 port router....
> > The kernel's FDT determines the order of detection for built-in
> > interfaces. Learn how to make them, then don't change it and the
> > interfaces will always come up the same way.
>


> Hi,
> Cannot confirm that as I have a board with 8 onboard ports
>


> 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) I219-LM (rev 31)
> 09:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)
> 0a:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)
> 0b:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)
> 0c:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)
> 0d:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)
> 0e:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)
> 0f:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)
>


> and they used to come up in all possible permutations.
> When I added a 4 port addon card
>


> 07:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
> 07:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
> 08:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
> 08:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
>


> things got even more funny.
>


> > Mask (delete, override with empty) e/udev rules and scripts and use
> > the purpose created 'ifrename' utility. And don't use SystemD OS..
>


> eudev could do nothing because the names I would have liked where in use
> same for ifrename.

Correct, you can clearly not have more than one interface per name.



> It works eventually if you use so called predictable new names
> and rename to old style names but even then you cannot be sure the predictable
> names will stay the same at next reboot.


Your 'predictable' names name are being assigned by what ?

> The only working solution is to:
>


> 1.  at boot rename all detected interfaces to some temporary name (e.g. eth*renamed)
> 2.  rename eth*renamed to eth{0-99} by a hardcoded list of mac addresses in the
>     wanted order.

>


> 3.  don't use udev it will not work (e.g delete 70-net-persistent-names.rules)
> 4.  eventually recreate 70-net-persistent-names.rules on the fly at boot
>     after having renamed the interfaces with the desired names linked
>     to mac addresses.

>


> 5.  make sure 70-net-persistent-names.rules is DELETED at reboot (or is on volatile storage)
>     or chances will be good that you will be locked out of your box at the next reboot.

>



I believe that is exactly what I just previously posted, 'ifrename' does all the heavy lifting for you.
No need to write scripts, parse the /sys filesystem, simply create '/etc/iftab', mapping each MACAddr to the name you wish to assign.
That is the only downside, you need to know some prior piece of hardware information to create the mapping table.

https://www.unix.com/man-page/debian/8/ifrename/

https://www.unix.com/man-page/debian/5/IFTAB/

>     Ciao,
>     Tito