Linux, systemd, SSD und Netzwerkkarten

Eigentlich bin ich ja fester Linux-Fan und beherrsche das auch recht gut, benutze es seit der allerersten lauffähigen Version.

Aber manchmal könnte man echt „Scheiße!“ schreien.

Womit ich mich gerade befasse und herumschlage.

Quizfrage: Ein Server läuft tadellos. Man baut eine weitere SSD ein, und dann funktioniert das Netzwerk nicht mehr.

Woran liegt’s?

Normalerweise heißen die Ethernet-Interfaces unter Linux traditionell eth0, eth1, eth2,…

Daran haben sich manche Leute gestört, weil der Kernel die der Reihe nach in der Reihenfolge durchnummeriert, in der er sie findet. Das ist von Übel, weil sich die Reihenfolge durchaus ändern kann, etwa wenn man Netzwerktreiber in anderer Reihenfolge lädt, Netzwerk-Hardware tauscht, entfernt, hinzufügt. Beispielsweise bei Hotplug-Karten. Die sind da ganz schlimm, die bringen alles durcheinander.

Deshalb wird auf manchen Linux-Distribution wie Ubuntu nach dem Booten eine Umbenennung vorgenommen. Man bennent die Netzwerkinterfaces um, nämlich nach Namen, die von der physikalischen Adresse abhängen, etwa von der Reihenfolge auf dem PCI-Bus oder der MAC-Adresse. Weil man annimmt, dass sich die Steckkarten in einem PC auf dem Mainboard ja nicht andere Steckplätze suchen, man also unterstellte, dass diese Benamungen stabil seien. Deshalb werden die Netzwerkinterfaces nach dem Booten in einem frühen Stadium von eth0,… umbenannt, beispielsweise in enp2s0, enp3s0, enp4s0 oder auch ganz anders, je nach Hardware.

Genauer gesagt: Der systemd mit seinem Gefolge benennt sie um. Und kurioserweise (festhalten, der Lacher kommt etwas weiter unten) heißt das dann „Predictable Network Interface Names“. Hat mich früher schon in den Wahnsinn getrieben, weil der systemd beim Booten vieles gleichzeitig macht und gerade dann, wenn andere Programme irgendwas mit Netzwerkinterfaces anstellen, die Namen verändert.

Beispielweise heißen dann Ethernet Network interfaces mit etwas, was mit „en“ anfängt. Der dritte Buchstabe gibt weiter Aufschluss, o für „Onboard“, also fest auf dem Mainboard aufgelötete sollten dann (ursprünglich) „eno..“ heißen. „s“, also „ens…“ für den PCI Express hotplug slot. „x“ steht für die MAC-Adresse, also „enx…“ für Interfaces, die mangels anderer Informationen nach ihrer MAC-Adresse benannt werden, beispielsweise USB-Interfaces.

Und „p“ steht für die Position des Hardware-Ports, soll also für die Durchnummerierung, die Reihenfolge der Ports stehen, wenn mehrere über einen laufen.

Sollte doch eigentlich eindeutig und stabil sein.

Aber, ach.

Auf diesem Rechner nun hießen die Interfaces enp2s0, enp3s0, enp4s0 und enp5s0. Wohlgemerkt: Ein kleines Router-Board. 4 Ethernet-Interfaces fest aufgelötet.

Warum?

Sieht man an der Ausgabe von lspci, was am PCI hängt.

00:… sind die ganzen Mainboard-eigenen Sachen.

01:00:0 ist die NVMe-SSD, worauf das Betriebssystem und so weiter war. Im Gegensatz zu den alten SATA-SSDs nämlich haben NVMe-SSDs die Eigenschaft, dass sie eben nicht als SATA-Gerät angesprochen werden, sondern selbst direkt auf dem PCI auftauchen, weil sie mit ein, zwei, drei oder vier PCIe-Lanes angebunden sind. (Das ist übrigens auch bei CF Express Kamera-Karten so. Die kleineren Typ A, wie sie Sony verwendet, haben eine Lane, während die größeren Typ B-Karten zwei Lanes verwenden, deshalb schneller sind, während die Typ A-Karten aber den „Vorteil“ haben, dass sie physisch so groß wie SD-Karten sind und man deshalb Kombi-Slots bauen kann, die mit beiden funktionieren.) Also: Die System-SSD taucht als NVMe-Karte direkt auf dem PCI auf, eben unter 01:00:0

Damit sind 00: und 01: als PCI-Adressen belegt.

Und die Netzwerkkarten folgen dann mit 02:00.0, 03:00.0, 04:00.0 und 05:00.0 und werden nach der ersten Zahl benannt, also enp2s0, enp3s0, enp4s0, enp5s0.

Nun hat aber dieser Rechner, obwohl er ganz klein ist, noch einen freien Slot für NVMe-Karten. Schick, dachte ich, lässt sich leicht aufrüsten, ohne alles neu installieren zu müssen, kannste dicke Karte reinstecken. Hat auch den Vorteil, dass Daten und Betriebssystem getrennt sind, denn ich installiere Betriebssysteme nicht gerne auf großen, teuren SSDs, weil Betriebssysteme mit ihren Bootvorgängen und Logfiles SSDs stärker abnutzen. Kleinere SSDs, die für das Betriebssystem reichen, sind da billiger im Tausch.

Was passiert nun?

Das BIOS hat die PCIe-Adressen neu vergeben – das ist nämlich alles nicht mehr physikalisch fest verdrahtet wie früher auf PC-Mainboards – und die neue SSD auf PCI-Adresse 01:00.0 gelegt, wo vorher die alte SSD war. Die alte SSD ist nun auf 02:00.00 verschoben worden, und folgerichtig fangen die Netzwerkinterfaces nun nicht mehr bei 02:00.0, sondern bei 03:00.0 an.

Und dementsprechend heißen sie jetzt nicht mehr enp2s0, enp3s0, enp4s0, enp5s0 sondern enp3s0, enp4s0, enp5s0, enp6s0.

Und weil sich die Netzwerkkonfigurationen samt VLANs, virtuellen Maschinen und so weiter und so fort auf den ursprünglichen Namen des ersten Interfaces enp2s0 beziehen, es enp2s0 aber nun nicht mehr gibt, geht die ganze Netzwerkkonfiguration von unten bis oben schief.

SSD reingesteckt, noch nicht benutzt, und die gesamte Netzwerkkonfiguration ist im Eimer. Nichts geht mehr.

Jo.

Kann man jetzt alles umbenennen. Aber dann hat man den gleichen Mist, nur andersrum, wenn man man die SSD irgendwann mal entfernt, oder wenn sie schlicht und einfach mal kaputt geht (das können die nämlich auch).

Und das soll dann „verlässlich“ und „predictive“ sein.

Mal schauen, ob man das mit match-Klauseln besser hinbekommt.

Aber: Systemd ist ein nie versiegender Quell der Freude und Zeitverschwendung.

Lösungsansatz

Man muss in netplan eine Match-Regel eintragen und wenn die Eindeutig ist, kann man sogar mit set-name einen Namen zuweisen. also enp3s0 in enp2s0 rückbenennen, indem man auf die MAC-Adresse matcht (was dann aber schief geht, wenn man mal den Rechner tauschen muss und der andere MAC-Adressen bekommt).

Und nicht einmal das funktioniert zuverlässig, denn wenn man abgeleitete Interfaces hat (z. B. VLANs), gibt es eine Fehlermeldung, dass der match nicht eindeutig ist und deshalb die Zuordnung nicht möglich ist, weil das ethernet-Interface und die abgeleiteten (z. B. VLANs) dieselbe MAC-Adresse haben, der match also mehrere Interfaces erfasst. Deshalb muss man auch noch den driver angeben, damit der Match wirklich nur dieses eine Interface erfasst.

Gruselig.