Ovion schriebAch so. Aber wlan0 ist eigentlich auch eine vom Kernel verwendete Bezeichnung, oder?
Unter Linux gilt das Motto "Wer zuerst kommt, mahlt zuerst" und das hat überall Gültigkeit.
Sollte beispielsweise wlan0 durch udev vergeben worden sein, sollte es mit einer zusätzlichen Karte keine Probleme geben.
Grund: Udev vergibt von Anfang an die Device-Namen. Der Kernel weiß davon nur die hälfte ;-) Wie im richtigen Leben halt 😃
Ovion schriebUnd da das eigentliche Problem mittlerweile gelöst scheint (auch wenn ich noch keine Gelegenheit hatte, es auszuprobieren, weil ich das betroffene Gerät aktuell nur ungünstig rebooten kann), mal eine kleine Verständnisfrage:
Warum funktioniert die udev-Regel sicher, wenn ich eine nicht-Kernel-Bezeichnung verwende, aber man hat potentielle Race-Conditions, wenn Kernel-Bezeichnungen für die Netzwerkschnittstellen verwendet werden?
Ich stelle mir das so vor: Sowohl udev als auch der Kernel gehen hin und benennen die Schnittstelle, der Kernel als "eth0", "eth1", udev als, je nach Regel, "lan0", "lan1". Die udev-Regel gewinnt dann immer (es sei denn, es tritt die Symptomatik von drcux auf, aber das aktuell mal beiseite). Aber wenn die udev-Regel mit "lan0" und "lan1" immer gewinnt, warum nicht auch mit fest zugeordneten "eth0" und "eth1"? Warum gibt es hier das Risiko der Race-Conditions? Erkennt der Kernel, dass die Netzwerkschnittstellen nicht seine Bezeichnungen tragen und lässt die Finger davon oder erkennt er seine Bezeichnungen und denkt sich dann "die kann ich ja auch nochmal ändern, sind ja eh meine und der Bootvorgang ist ja noch nicht vorbei"?
Zu viele Informationen auf einmal 😉 da muss ich mich erstmal schlau machen.