Ovion
Hi,
bei mir tut sich folgendes Problem auf:
ich habe einen Laptop mit LAN-Buchse und WLAN-Modul, also, abgesehen vom loopback zwei Ethernet-Schnittstellen, eth0 und eth1.
Leider entscheidet sich mein System bei jedem Boot, welches von beiden das eth0 und welches das eth1 bekommt. Das ist tierisch nervend, weil ich netcfg benutze und diesem im jeweiligen Profil den Namen des zu benutzenden Interfaces nenne - und über eine LAN-Buchse lässt sich nunmal keine WLAN-Verbindung herstellen.
Ich habe beobachtet, dass das eth0 die LAN-Verbindung ist, wenn beim Boot das WLAN hardblocked ist (mittels des WLAN-aus-Schalters am Laptop) und anderenfalls, ohne WLAN-hardblock, das WLAN-Modul eth0. Die jeweils andere Schnittstelle wird eth1.
Da der Laptop die letzte Zeit kaum in Benutzung war, habe ich Schwierigkeiten, den Beginn des Problems zeitlich einzuordnen. Da das ganze ein Hardwarebenennungsproblem ist und das ja afaik mittlerweile von systemd übernommen wird, tippe ich auf ein Problem dort. Es kann durchaus sein, dass das mit der Umstellung auf systemd gekommen ist, weil der WLAN-hardblock selten drin ist und ich so unwissend am Problem vorbeigeschifft bin, aber ich kann es nicht mit Sicherheit sagen.
Kann mir jemand weiterhelfen, den Schnittstellen feste Namen zu verpassen (und das Problem zu lokalisieren)? Besten Dank schonmal!
drcux
Am einfachsten ist es, das Modul für die LAN-Karte direkt in /etc/mkinitcpio.conf einzutragen und die Initrd neu zu erzeugen. Dadurch wird die LAN-Karte _immer_ zuerst aktiviert und bekommt eth0.
Die UDEV-Regel persistentnetwork funktioniert leider mit systemd nicht mehr...
Ovion
Besten Dank für den Tipp! Das Modul der LAN-Karte ist mir nicht bekannt, wohl aber das der WLAN-Karte, dürfte keinen Unterschied machen, die WLAN-Karte dürfte das System zuordnen können, auch wenn's hardblocked ist, oder?
Ist auch ne feste Zuordnung Hardwareadresse <-> Interfacename möglich?
drcux
Ovion schriebBesten Dank für den Tipp! Das Modul der LAN-Karte ist mir nicht bekannt
hwinfo --network
Ovion schrieb
Ist auch ne feste Zuordnung Hardwareadresse <-> Interfacename möglich?
"Die UDEV-Regel persistentnetwork funktioniert leider mit systemd nicht mehr..."
Ovion
drcux schriebhwinfo --network
Und wieder eine nützliche Software mehr kennengelernt, danke!
Wenn ich die Module in der mkinitcpio.conf in der Reihenfolge, wie ich sie benannt haben möchte, eintrage, klappt es wunderbar. Besten Dank für den Tipp!
drcux schrieb
Ovion schrieb
Ist auch ne feste Zuordnung Hardwareadresse <-> Interfacename möglich?
"Die UDEV-Regel persistentnetwork funktioniert leider mit systemd nicht mehr..."
Schon klar, aber ist das der einzig denkbare Weg (abseits mkinitcpio)? (War das eigentlich eine "vorformulierte" bzw. allgemeine Regel für udev oder funktioniert das Benennen von Schnittstellen via udev allgemein nicht mehr?
drcux
Ovion schrieb
Schon klar, aber ist das der einzig denkbare Weg (abseits mkinitcpio)?
Keine Ahnung, aber per udev war es bis jetzt immer der richtige Weg.
(War das eigentlich eine "vorformulierte" bzw. allgemeine Regel für udev oder funktioniert das Benennen von Schnittstellen via udev allgemein nicht mehr?
Du kannst die Schnittstellen immer noch per udev benennen, aber leider benennt udev die Netzwerkschnittstellen nach der Netzwerkinitialisierung um, was natürlich Schwachfug ist. 🙁
Ovion
drcux schriebDu kannst die Schnittstellen immer noch per udev benennen, aber leider benennt udev die Netzwerkschnittstellen nach der Netzwerkinitialisierung um, was natürlich Schwachfug ist. 🙁
Also ich benenne die Schnittstelle per Regel, udev wendet diese Regel an und danach geht udev hin und benennt die Schnittstellen nach eigenem Gusto, habe ich das gerade richtig verstanden?
hydro
drcux schrieb
Du kannst die Schnittstellen immer noch per udev benennen, aber leider benennt udev die Netzwerkschnittstellen nach der Netzwerkinitialisierung um
Kann ich nicht nachvollziehen,
$ journalctl -b --no-pager | grep -w -e lan -e eth0
Dez 23 18:25:05 linux systemd-udevd[161]: renamed network interface eth0 to lan
Dez 23 18:25:19 linux ntpd[382]: Listen normally on 5 lan fe80::5604:a6ff:fe37:6985 UDP 123
Dez 23 18:25:20 linux kernel: atl1c 0000:04:00.0: atl1c: lan NIC Link is Up<1000 Mbps Full Duplex>
Dez 23 18:25:20 linux netcfg-daemon[332]: :: lan up [done]
Rikkiya
mach das ganze per udev.rules
SUBSYSTEM=="net", ATTR{address}=="MAC ADDR", NAME="net0"
SUBSYSTEM=="net", ATTR{address}=="00:sd:df:hj:00:00", NAME="net1"
Achtung danach müssen alle manuellen Angepassten Netzwerk confs mit "net" angegeben werden, nicht mit "eth".
geht super
Wichtig ist mit "net" oder sonst was eintragen bei den udev.rules sonst kommt es zu Problemen mit den Kernel internen Bezeichnungen.
Ovion
Rikkiya schriebmach das ganze per udev.rules
Ok, werde das auch mal probieren, danke!
Rikkiya schriebWichtig ist mit "net" oder sonst was eintragen bei den udev.rules sonst kommt es zu Problemen mit den Kernel internen Bezeichnungen.
Meinst du damit, ich soll die Interfaces nicht per udev als "eth0" und "eth1" festbenennen, weil das mit den Kernelbezeichnungen kollidiert?
hydro
Ja, darauf wird auch im
Wiki hingewiesen...
Ovion
"lan", "wired", "wlan" sind Bezeichnungen, die zu keinem Problem führen (nur zur Sicherheit gefragt)?.
Das Problem ist, wenn ich das richtig verstehe, dass durch den hochparallelisierten Boot entweder der Kernel oder aber udev anfängt, die Schnittstellen zu benennen, und wer auch immer zweiter ist (was sich bootweise ändern kann), überschreibt den Namen des Ersten, richig?
Warum aber kann das durch "nicht-Kernel-Bezeichnungen" in den udev-rules vermieden werden? Warum funktioniert das bei Kernelbezeichnungen nicht, bei Nichtkernelbezeichnungen aber, das Problem ist doch dasselbe?
drcux
Rikkiya schriebmach das ganze per udev.rules
...
geht super
Weißt du, wann der Bug gefixt wurde? Bei meinem letzten Versuch ging es nämlich nicht und auch Tante Google bestätigte dieses Verhalten.
Rikkiya
Also bei mir geht es immer. Hatte keine Probleme bis jetzt, weder mit dem 3.5, 3.6 Kernel noch mit dem LTS Kernel.
net 0 und net1 werden immer korrekt vergeben.
drcux
Merkwürdig, ich habe eine Kiste die als Router dient noch nicht auf systemd umgestellt, da die Umbenennung der NetDev auf int0 und ext0 nicht hinhaut, die zweite wird immer zu spät angefasst...
Werde nach Weihnachten mal hinfahren und nochmal probieren.
drcux
Wollte es gerade in einer VBox testen, jetzt wird es sogar noch schlimmer:
[root@archtest ~]# journalctl -b --no-pager | grep -w -e eth0
Dez 24 12:25:53 archtest netcfg-daemon[175]: :: eth0 up Interface eth0 does not exist
Dez 24 12:25:54 archtest kernel: e1000 0000:00:03.0: eth0: (PCI:33MHz:32-bit) 08:00:27:7f:9d:53
Dez 24 12:25:54 archtest kernel: e1000 0000:00:03.0: eth0: Intel(R) PRO/1000 Network Connection
Netcfg startet vor dem laden des Kernelmoduls... 🙁
Ovion
Der Kernel verwendet ja Bezeichnungen eth0, wlan0 etc., die sollte man ja nicht verwenden. Kann ich aber statt "wlan0" "wlan" ohne Zahl dahinter per udev vergeben, ohne dass das sich mit den Kernelbezeichnungen in die Haare kommt?
[gelöscht]
Ovion schriebDer Kernel verwendet ja Bezeichnungen eth0, wlan0 etc., die sollte man ja nicht verwenden. Kann ich aber statt "wlan0" "wlan" ohne Zahl dahinter per udev vergeben, ohne dass das sich mit den Kernelbezeichnungen in die Haare kommt?
Probieren geht über studieren und ja, es sollte möglich sein.
In der Theorie ist so vieles möglich aber die Praxis zeigt immer entsprechende Gegenteile.
Ovion
Ok, danke! Nächste Frage: Woran erkenne ich in diesem Fall eine Race-Condition? Schlicht daran, dass die Netzwerkkarten am Ende doch wieder "eth0" und "eth1" statt "wlan" und "lan" heißen?
Hatte das Problem noch nie und muss es natürlich identifizieren können.
[gelöscht]
Wenn die Regeln nicht greifen, dann bleibt eth0 eben eth0 und eth1 eben eth1.
Bei meinem Thinkpad T43 habe ich das Spiel mit der W-LAN und LAN Karte auch gehabt aber ich hatte reflexartig wlan0 und lan0 in die rules geschrieben, was niemanden ein Bein abbricht.