[Eisfair] udev eth0 - eth1/base config vs. realitas

[Marcus Roeckrath]

Hallo Derya,

D. Oezbilen wrote:

> hier die angefordeten Ausgaben, dmesg. messages bietet nicht mehr.
> 
> Am 28.11.2019 um 21:14 schrieb Marcus Roeckrath:
>> Bitte die Ausgabe von dmesg und auch den passenden Abschnitt zum Boot
>> aus /var/log/messages (ab Start von udevd: "<30>udevd[xxxx]: starting
>> version 3.2.8"
> 
> Jepp, es gibt im dmesg Belege, dass er scheitert. => s. !!-----
> Was moeglich waere(?) ueber das Bios die FW und/oder die IRQ Reihenfolge
> zu aendern.
> Update: Geschaut nogo, kann im Bios nicht IRQ/Reihenfolge einstellen.

Ich fürchte, dass würde hier auch nicht helfen, denn wenn du die 4er-NIC vor
der Intel schiebst, blockiert sich die 4er-NIC selbst und du kannst dann
auch dann nicht die erste auf eth1 schieben; damit wird eth0 dann auch für
die Intel nicht frei. Wenn du die 1. Schnittstelle der 4er-NIC auf eth0
belässt, kommt die Intel aber auch nicht an eth1 ran.

Es gibt nur einen Weg der sauberen Verteilung mit udev!

Keine Verwendung von ethX im laufenden System. Da kann man jammern und
heulen, aber das ändert nichts an der durch udev eingeführten Problematik,
wobei udev insgesamt unbestreitbare Vorteile hat.

Un du hast nun eine ganz typische Race-Condition:

Es wird als erstes der Treiber für die Intel geladen.

> [   11.987497] e1000e: Intel(R) PRO/1000 Network Driver - 3.4.2.1-NAPI
> [   12.001637] e1000e: Copyright(c) 1999 - 2018 Intel Corporation.
> [   12.015519] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec)
> set to dynamic conservative mode
> [   12.041997] e1000e 0000:00:19.0: irq 77 for MSI/MSI-X

Bevor die aber kernelseitig ein eth-Device zugewiesen bekommt, kommt der
igb-Treiber für die 4er-NIC und bekommt vom Kernel sofort eth0 bis eth3
zugewiesen:

> [   12.155528] igb 0000:06:00.0: added PHC on eth0
> [   12.234677] igb 0000:06:00.1: added PHC on eth1
> [   12.314673] igb 0000:06:00.2: added PHC on eth2
> [   12.394811] igb 0000:06:00.3: added PHC on eth3

> ---------------------------------
> eth4 fuer onboard ist klar, erst die Quad-NIC, etho/1/2/3 -> 4 fuer
> onboard. Dann aber scheitert er umzubenennen.
> ---------------------------------

Genau, die bekommt nun die erste freie eth4 und weil eth0 noch belegt ist
(File exists) kann eth4 nicht nach eth0 umbenannt werden.

> [   12.659740] udevd[1765]: Error changing net interface name eth4 to
> eth0: File exists
> [   12.659757] udevd[1765]: could not rename interface '6' from 'eth4'
> to 'eth0': File exists

Und die Umbenennung von eth0 nach eth1 scheitert, weil eth1 noch die 2.
Schnittstelle der 4er NIC ist.

> [   12.732767] udevd[1763]: Error changing net interface name eth0 to
> eth1: File exists
> [   12.732784] udevd[1763]: could not rename interface '2' from 'eth0'
> to 'eth1': File exists

Hat alles mit udev und nichts mit eisfair zu tun; wenn die Intel schneller
ihr eth0 bekäme, würde es nach deinem Wunsch gehen, aber das wäre dann
nciht aufgrund der udev-Regeln, weil auch dann Umbenennungen sich
gegenseitig blockieren würden.

Versuche in dem Fall mal der Intel eth1 zuzuweisen.

Also weg mit ethX im laufenden System, benenne die z. B. mit lan0, lan1, ...
oder net0, net1, ... oder was immer du magst.

-- 
Gruss Marcus