Diese Maschine hat vier Netzwerkanschlüsse mit jeweils zehn Gigabit. Zwei davon sitzen fest auf dem Board, zwei kommen von einer Steckkarte. Genutzt wird einer. Die anderen drei sind absichtlich abgeschaltet, weil ich sie nicht brauche.
Im BIOS ist davon nichts zu merken: dort bekommt jede der vier Schnittstellen ihr eigenes Menü, mit Untermenüs, und in Summe sind das rund fünfzig Bildschirmseiten. Für einen Rechner unter dem Schreibtisch ist das absurd. Für ein Board, das eigentlich in einem Rack ohne Tastatur steht, ergibt es Sinn, und dieser Unterschied ist im Grunde das Thema der Folge.
Teil 13, gesammelt unter BIOS & Firmware.
Der Hauptschalter
Network Stack [Enabled] IPv4 PXE Support [Enabled] IPv4 HTTP Support [Disabled] IPv6 PXE Support [Enabled] IPv6 HTTP Support [Disabled] PXE Boot Wait Time 0 Media Detect Count 1
Network Stack ist die Grundsatzentscheidung: bringt die Firmware überhaupt einen eigenen Netzwerkstapel mit? Aus heisst, dass es kein PXE gibt, kein iSCSI, kein HTTP-Boot, und dass die entsprechenden Menüs verschwinden.
PXE ist die klassische Variante des Netzwerkstarts: Rechner fragt per DHCP nach einer Adresse und bekommt gleich noch gesagt, von welchem Server er sein Startabbild holen soll. Übertragen wird per TFTP, einem Protokoll ohne jede Absicherung, das seit den Achtzigern im Wesentlichen unverändert ist. In einem abgeschotteten Verwaltungsnetz ist das in Ordnung, im normalen LAN sollte man wissen was man tut.
HTTP Support ist die moderne Antwort darauf: dasselbe über HTTP, optional mit TLS und Zertifikatsprüfung. Deshalb gibt es auf diesem Board auch eine eigene Seite für TLS-Zertifikate. Bei mir ist HTTP-Boot aus, weil ich weder das eine noch das andere nutze.
Media Detect Count 1 legt fest, wie oft die Firmware nachsieht, ob ein Kabel steckt, bevor sie aufgibt. Bei drei nicht angeschlossenen Ports ist die Eins eine sinnvolle Sparmassnahme. PXE Boot Wait Time 0 bedeutet, dass sie nicht extra wartet.
Vier Karten, vier Menüs
Jede Schnittstelle bekommt einen eigenen Eintrag mit demselben Aufbau. Für die Onboard-Ports sieht das so aus:
> Firmware Image Properties
Option ROM version 1.3082.0
NVM Version 3.5
> NIC Configuration
Blink LEDs 0
UEFI Driver Intel(R) 10GbE Driver 8.1.00 x64
Device Name Intel(R) Ethernet Controller X550
Chip Type Intel X550
PCI Device ID 1563
Link Status [Disconnected]
Blink LEDs ist die praktischste Funktion des ganzen Menüs und die einzige, die man im Rechenzentrum wirklich vermisst, wenn sie fehlt: man gibt eine Anzahl Sekunden ein und die Leuchtdiode am betreffenden Anschluss blinkt. So findet man heraus, welches der zwölf Kabel hinten am Gerät zu dieser Schnittstelle gehört, ohne raten zu müssen.
Unter NIC Configuration stehen dann Dinge wie Link Speed, Wake on LAN und Legacy Boot Protocol. Der letzte Punkt entscheidet, ob die Karte im Vorstart PXE spricht, iSCSI, oder gar nichts.
iSCSI im BIOS, und wofür das gut ist
Bei der Steckkarte kommt noch ein Untermenü dazu, das ich beim Durchklicken zuerst für einen Irrtum gehalten habe:
> iSCSI Configuration
iSCSI Initiator Parameters
CHAP Authentication
iSCSI First Target
Eine vollständige iSCSI-Konfiguration im BIOS, inklusive Anmeldeverfahren. Die Idee dahinter ist ein Rechner ohne eigene Festplatte: die Systemplatte liegt auf einem Speichersystem im Netz, die Firmware baut die Verbindung auf, bevor irgendein Betriebssystem existiert, und von aussen sieht es aus wie eine ganz normale lokale Platte.
Für Serverfarmen ist das ein sinnvolles Modell. Hardware defekt heisst dann: Blech tauschen, Konfiguration übernehmen, weiter. Für meine Workstation ist es vollkommen sinnlos, und ich erwähne es nur, weil es einem beim Durchsehen des Menüs unweigerlich begegnet und man sich fragt, was das hier zu suchen hat.
CHAP Authentication daneben ist übrigens ein gutes Beispiel für die Alterung solcher Protokolle: das ist ein Challenge-Response-Verfahren, das für sich genommen kein böses Design ist, aber ohne Transportverschlüsselung eingesetzt wird. Wer iSCSI heute ernsthaft betreibt, setzt es in ein eigenes Netzsegment.
Und jetzt die Seite, wegen der ich diese Folge schreibe
Ganz unten im Advanced-Menü gibt es einen Punkt namens Driver Health. Der sammelt Rückmeldungen aller UEFI-Treiber, die beim Start geladen wurden. Bei mir steht dort:
Intel(R) 10GbE Driver 8.1.00 x64 Healthy Intel(R) 10GbE Driver 8.1.00 x64 Healthy Intel(R) 40GbE 1.7.19 Failed Intel(R) 40GbE 1.7.19 Failed Samsung Electronics NVMe Driver Healthy
Zweimal Failed, und zwar für meine 10-Gigabit-Steckkarte. Der Klartext dahinter:
The UEFI driver for the device detected a newer version of the NVM image than expected. Please install the most recent version of the UEFI driver.
Diese Meldung ist ein kleines Meisterwerk an Missverständlichkeit, und sie hat eine Vorgeschichte.
Vor einiger Zeit habe ich die Firmware dieser Karte aktualisiert. Sie kam mit NVM 5.05, das war ziemlich alt, und ich habe sie auf 9.56 gebracht. Das ist gut gegangen, die Karte läuft unter Linux tadellos, zehn Gigabit, Flusskontrolle, alles in Ordnung:
ethtool -i ens6f1np1 # driver: i40e # firmware-version: 9.56 0x80010103 17.5.12
Nur besteht so eine Karte aus zwei Teilen Firmware. Da ist das NVM, das den eigentlichen Kartenbetrieb steuert. Und da ist das Option ROM, also der UEFI-Treiber für den Vorstart, den das BIOS ausführt. Ich habe das eine aktualisiert und das andere nicht. Die Zahlen aus dem Menü zeigen den Abstand:
Family Firmware Version 17.5.12 EFI Version 1.7.19
Der Vorstart-Treiber hat einen fest einkompilierten Versionsbereich, in dem er sein NVM erwartet, und 9.56 liegt darüber. Also meldet er sich krank.
Warum man diese Meldung genau lesen muss
Die naheliegende Reaktion ist, die Firmware der Karte zu aktualisieren. Das wäre falsch, und zwar genau das falsche Ende. Die Meldung sagt nicht „aktualisiere das NVM“, sie sagt install the most recent version of the UEFI driver. Der Treiber beschwert sich über sich selbst, nicht über die Firmware.
Dass wirklich nur der Vorstart betroffen ist, lässt sich schön belegen. Der Linux-Treiber hat dieselbe Prüfung eingebaut, die Meldungstexte stecken im Modul:
strings i40e.ko | grep "newer version of the NVM" # The driver for the device detected a newer version of the NVM image v%u.%u than v%u.%u.
Und im Journal steht davon: nichts. Der Kerneltreiber deckt NVM 9.56 ab und ist zufrieden. Es betrifft ausschliesslich Netzwerkstart über diese Karte, und die Maschine startet von der lokalen NVMe.
Was ich damit mache
Es gibt drei Möglichkeiten. Ignorieren, dann bleibt eine rote Zeile auf einer Seite, die ich ohnehin nie öffne. Das Option ROM nachziehen, was einen weiteren erzwungenen Flash auf einer funktionierenden Netzwerkkarte bedeutet, nur um einen Dialog loszuwerden. Oder das Option ROM für diesen Steckplatz einfach abschalten:
Advanced > PCIe/PCI/PnP Configuration CPU SLOT6 PCI-E 4.0 X16 OPROM [Disabled]
Das ist die Variante, die ich wählen würde, wenn es mich stört. Kein Einfluss auf das laufende Netzwerk, denn Linux bringt seinen eigenen Treiber mit. Der einzige Verlust ist PXE-Boot über diese Karte, was ich noch nie gebraucht habe.
Gegen den Nachflash spricht etwas Grundsätzliches: das NVM wurde bereits einmal mit Gewalt überschrieben. Ein zweiter erzwungener Flash auf einer Karte, die einwandfrei arbeitet, ist ein schlechtes Geschäft. Geht er schief, ist die Karte im Vorstart tot, und dann habe ich statt einer kosmetischen Meldung ein echtes Problem.
Übrigens: die Karte taucht in der festen Startreihenfolge gar nicht auf, wohl aber in der manuellen Auswahl. Ihr Option ROM läuft also weit genug, um Startoptionen anzumelden, und meldet sich trotzdem gesundheitlich ab. Funktional fehlt nichts.
Der Message Code, und warum ich ihn in Ruhe lasse
Unter der Meldung steht noch eine Zahl:
Message Code : 9007203549708288
Das sieht nach einem Fehlercode aus, den man nachschlagen könnte. Umgerechnet ist es 0x0020000100000000, also zwei gesetzte Bits in einem 64-Bit-Wert. So glatt ist keine laufende Nummer, das ist ein Bitfeld. Eine öffentliche Tabelle dafür gibt Intel nicht heraus.
Ich schreibe das auf, weil solche Zahlen einen leicht auf eine lange und ergebnislose Suche schicken. Der Klartext darüber ist die Information. Der Zahlenwert ist keine.
Fazit
Fünfzig Bildschirmseiten Netzwerkkonfiguration für eine Maschine, die einen einzigen Anschluss nutzt, sind ein guter Anlass zu fragen, wofür so ein Board eigentlich gebaut wurde. PXE, iSCSI, HTTP-Boot mit Zertifikatsprüfung, das alles ergibt nur Sinn, wenn hunderte gleiche Kisten in einem Rack stehen und keine davon eine Tastatur hat.
Und die Driver Health-Seite ist die vielleicht praktischste Seite im ganzen Setup, weil sie etwas anzeigt, das man sonst nirgends sieht: was die Firmware auf den Steckkarten von sich selbst hält.
Nächste Folge: der Start selbst. Boot-Reihenfolge, UEFI gegen Legacy, und Secure Boot auf einem Board, das noch nie einen Schlüssel gesehen hat.
Siehe auch
- Teil 9 der Serie (Option ROMs, und wie man sie pro Steckplatz abschaltet)
- Raspberry Pi als serieller Konsolenserver (Verwaltung ohne Monitor, eine Etage tiefer)
Hat jemand von euch schon mal ein Option ROM auf einer Intel-Netzwerkkarte nachgezogen, ohne das NVM anzufassen? Ich hätte gerne einen Erfahrungsbericht bevor ich es selbst probiere, ihr dürft mich fragen.
Schreibe einen Kommentar