Im letzten Beitrag ging es darum, die BIOS-Einstellungen meines Supermicro X12SPi-TF überhaupt erst als Datei in die Hand zu bekommen. Das Ergebnis war eine XML mit 372 Einstellungen, und der Weg dorthin führte über eine Lizenz für 28,17 Euro.
Damit war die halbe Arbeit getan. Eine Konfiguration auslesen zu können ist schön, aber der eigentliche Gewinn liegt darin, sie auch zurückschreiben zu können. Genau das habe ich jetzt gemacht, und zwar zum ersten Mal überhaupt an dieser Maschine: sieben Einstellungen geändert, ohne den Rechner ins Setup zu booten, ohne Tastatur, ohne die Fernkonsole des Management-Controllers.
Vorweg die gute Nachricht für alle, die schon rechnen: die kleine Lizenz deckt das Schreiben mit ab. Ich hatte damit gerechnet, dass Supermicro genau an dieser Stelle noch einmal die Hand aufhält, und das tut es auch, aber nur an einer sehr kleinen Ecke. Von den 372 Einstellungen tragen 21 den Vermerk, dass sie die große Lizenz verlangen. Es sind ausschliesslich Zertifikatseinträge für KMIP-Server und HTTPS-Boot. Nichts davon betrifft normale Setup-Optionen.
Was ich ändern wollte, und warum
Der langweiligste Teil eines solchen Artikels ist die Liste der geänderten Werte. Der interessante Teil ist die Begründung, deshalb fange ich damit an.
Mein Rechner bootet von einer NVMe-SSD. Er hat das noch nie anders gemacht und wird es auch nicht. Trotzdem lädt das BIOS bei jedem Start die Pre-Boot-Netzwerktreiber für vier Netzwerkanschlüsse, jeweils für IPv4 und IPv6, und baut daraus Boot-Einträge, die niemand benutzt. Dazu kommen die Option-ROMs von drei leeren Steckplätzen.
Ein Option-ROM ist ein kleines Stück Firmware auf einer Steckkarte, das beim Start ins BIOS geladen wird, damit die Karte schon vor dem Betriebssystem funktioniert. Für eine Netzwerkkarte heisst das Netzwerk-Boot, für einen Speichercontroller das Booten von daran angeschlossenen Platten. Wer von keinem dieser Geräte bootet, braucht den Code nicht.
Also:
– Network Stack von *Enabled* auf *Disabled*. Damit fällt die komplette UEFI-Netzwerkinitialisierung weg. – Onboard LAN1 Option ROM aus. Der Pre-Boot-Treiber der onboard X550 wird nicht gebraucht. – CPU SLOT6 OPROM aus. Dort steckt meine X710. Dazu gleich mehr, das ist der eigentliche Grund für die Aktion. – CPU SLOT1, SLOT2 und SLOT7 OPROM aus. Alle drei Steckplätze sind leer.
Bei den drei leeren Steckplätzen bin ich ehrlich: der Zeitgewinn ist exakt null. Wo keine Karte steckt, gibt es auch kein Option-ROM zu laden. Ich habe sie trotzdem mitgenommen, weil ich einen dokumentierten Sollzustand haben will und nicht eine Mischung aus bewusst gesetzt und zufällig übrig.
Die siebte Änderung ist die, um die es mir wirklich ging.
Die eine Zeile, die eine Woche Rätselraten beendet hat
Beim Schreiben meiner BIOS-Serie ist mir etwas aufgefallen, das ich mir lange nicht erklären konnte. Mein Prozessor ist ein Xeon Gold 5315Y, Ice Lake-SP. Diese Generation beherrscht Hardware P-States, kurz HWP. Die CPU regelt ihren Takt dabei selbst, in feineren Stufen und deutlich schneller, als das Betriebssystem es könnte.
Nur meldete mein Kernel davon nichts. In /proc/cpuinfo fehlte das hwp-Flag, der Treiber intel_pstate lief im passiven Modus, und die Taktregelung machte der Governor schedutil. Also genau der Zustand, den man auf einer CPU erwartet, die HWP gar nicht kann.
Ich habe eine Weile in Richtung Kernel gesucht. Das war die falsche Richtung. Der Schalter sass im BIOS, ziemlich tief vergraben:
Advanced > CPU Configuration > Advanced Power Management Configuration
> Hardware PM State Control > Hardware P-States
[Disable]Der Auslieferungszustand dieser Option ist tatsächlich *Disable*. Es gibt vier Werte, und der Hilfetext im BIOS beschreibt sie so:
Disable hardware will choose a P-state setting for
the system based on an OS request
Native Mode hardware will choose a P-state setting
based on OS guidance
Native Mode with No Legacy Support hardware will choose a P-state setting
independently without OS guidance
Out of Band Mode hardware autonomously choose a P-state
without OS guidance
Ich habe Native Mode genommen, also die zahmste der drei aktiven Varianten. Der Unterschied zu den beiden anderen ist wichtig: bei *Native Mode* behält das Betriebssystem seinen Einfluss, es wandert nur die Feinsteuerung in die CPU. Bei den beiden anderen wird der Kernel bei der Taktwahl übergangen, und dann kann er dir auch nicht mehr sinnvoll sagen, was die CPU gerade tut.
Was ich bewusst nicht angefasst habe
Diese Liste finde ich wichtiger als die Liste der Änderungen, denn hier hätte ich mir den Rechner unbedienbar machen können.
Das Option-ROM von SLOT4 bleibt an. Dort sitzt die Grafikkarte. Ihr GOP-Modul ist das, was beim Start überhaupt ein Bild auf den Monitor bringt. Wer es abschaltet, sitzt bis zum Laden des Grafiktreibers im Dunkeln, und wenn dabei etwas schiefgeht, sitzt er dauerhaft im Dunkeln.
Onboard Video Option ROM bleibt an. Das ist die Grafik des Management-Controllers, und daran hängt die Fernkonsole. Schaltet man sie ab, bleibt beim Start das Fenster schwarz, über das man aus der Ferne ins Setup kommt. Das ist genau der Rettungsweg, den man sich nicht abschneiden will, wenn man gerade anfängt, das BIOS aus dem laufenden Betrieb heraus umzukonfigurieren.
Beide NVMe-Option-ROMs bleiben an. Das erste trägt das Betriebssystem. Auf das zweite soll irgendwann Windows, und auch wenn der Bootloader auf der ersten Platte das Kommando behält, muss die zweite dem Firmware-Bootmanager sichtbar bleiben.
Legacy USB Support bleibt an. Hier hätte ich vermutlich etwas Startzeit gewinnen können. Ich habe es gelassen, weil ich den Gewinn nicht gemessen habe und das Risiko eine tote Tastatur im Setup wäre. Eine Einstellung, deren Nutzen man nicht beziffern kann, deren Schaden aber konkret ist, ändert man nicht.
Der Weg: eine Teildatei, nicht die ganze
Naheliegend wäre, die ausgelesene XML zu bearbeiten und komplett zurückzuschreiben. Bei 372 Einstellungen und 260 Kilobyte ist das unnötig riskant, und es ist auch nicht der vorgesehene Weg.
Das Werkzeug kennt einen Filter, der genau die Einstellungen ausgibt, die vom Auslieferungszustand abweichen:
./saa -c GetCurrentBiosCfg --file nondefault.xml --overwrite --filter nondefault
Heraus kommt eine kleine Datei mit derselben Struktur wie die grosse, nur eben mit den Menüzweigen, die auch wirklich etwas enthalten. Und genau diese Struktur nimmt das Schreibkommando entgegen. Teildateien sind also kein Trick, sondern der normale Betriebsfall.
Hier der erste Fallstrick, und der hat mich ehrlich geärgert: die eingebaute Hilfe des Werkzeugs beschreibt den Filter als Ziffer.
--filter Sets filter type to: 1 = nondefault
Die Ziffer 1 wird abgewiesen. Das Kommando bricht ab und wirft den Hilfetext aus, der einem gerade die Ziffer empfohlen hat. Akzeptiert wird ausschliesslich das ausgeschriebene Wort nondefault. Wenn du also an dieser Stelle hängst, liegt es nicht an dir.
Meine Änderungsdatei habe ich nicht getippt, sondern mit einem kleinen Python-Skript aus dem Auslesestand erzeugt. Das klingt nach Übertreibung für sieben Werte, hat aber einen handfesten Grund: die Einstellungen müssen im richtigen Menüzweig stehen, und die Menünamen sind lang und fehleranfällig. CPU SLOT2 PCI-E 4.0 X8(IN X16) OPROM vertippt sich schneller, als man denkt, und ein Tippfehler im Namen führt nicht zu einer Fehlermeldung, sondern dazu, dass die Einstellung stillschweigend nicht gesetzt wird.
Das Schreiben selbst ist unspektakulär:
./saa -c ChangeBiosCfg --file change-boot-oprom-hwp.xml
Status: The BIOS configuration is updated for the managed system
Note: You have to reboot or power up the system for the changes to take effect.
Es gibt eine Option --reboot, die den Neustart gleich mit erledigt. Die habe ich weggelassen. Wann ein Rechner neu startet, entscheide ich lieber selbst.
Der zweite Fallstrick, und der ist gemein
Nach dem Schreiben will man natürlich nachsehen, ob es geklappt hat. Also dasselbe Auslesekommando noch einmal, und dann steht da:
Hardware P-States = Disable (geschrieben: Native Mode)
Network Stack = Enabled (geschrieben: Disabled)
CPU SLOT6 PCI-E 4.0 X16 OPROM = EFI (geschrieben: Disabled)
Nichts. Alle alten Werte, unverändert.
Der erste Reflex ist, das Schreibkommando noch einmal laufen zu lassen. Tu das nicht. Das Auslesen liefert die aktive Konfiguration, und die ändert sich erst beim nächsten Start. Deine Änderung liegt so lange in einem Bereich, den das Werkzeug nicht anzeigt. Zwischen dem Schreiben und dem Neustart gibt es damit keine Möglichkeit, die Änderung zu überprüfen, ausser dem Rückgabewert des Kommandos.
Das ist unschön, aber es ist logisch. Die Einstellungen werden erst beim Start aus dem Speicher gelesen, und vorher gibt es schlicht nichts Aktives, das anders wäre.
Nach dem Neustart
Und dann stimmt alles. Die Zahl der Abweichungen vom Auslieferungszustand ist von sechs auf dreizehn gestiegen, also genau um meine sieben:
Quiet Boot Unchecked
Restore on AC Power Loss Stay Off
Power Button Function 4 Seconds Override
Hardware P-States Native Mode
Network Stack Disabled
Re-Size BAR Support Enabled
VGA Priority Offboard
CPU SLOT1 PCI-E 4.0 X8 OPROM Disabled
CPU SLOT2 PCI-E 4.0 X8(IN X16) OPROM Disabled
CPU SLOT6 PCI-E 4.0 X16 OPROM Disabled
CPU SLOT7 PCI-E 4.0 X8 OPROM Disabled
Onboard LAN1 Option ROM Disabled
WHEA Support Disabled
Die Netzwerk-Booteinträge sind verschwunden, übrig bleibt der Bootloader und die eingebaute Shell:
BootCurrent: 000F
BootOrder: 000F,0001
Boot0001* UEFI: Built-in EFI Shell
Boot000F* ubuntu
Und der Punkt, um den es mir ging, ist eingetreten. Der Prozessor meldet jetzt Fähigkeiten, die er die ganze Zeit hatte:
$ grep -o ' hwp[_a-z]*' /proc/cpuinfo | sort -u
hwp
hwp_act_window
hwp_epp
hwp_pkg_req
$ cat /sys/devices/system/cpu/intel_pstate/status
active
Der Treiber ist damit vom passiven in den aktiven Modus gewechselt. Was dabei kurz irritiert: der Governor heisst jetzt powersave statt schedutil, und das sieht nach einem Rückschritt aus. Ist es nicht. Bei intel_pstate im aktiven Modus ist powersave der Name für den Betrieb, bei dem die Hardware regelt. Wie sie das tut, steuert ein separater Wert:
$ cat /sys/devices/system/cpu/cpu0/cpufreq/energy_performance_preference
balance_performance
Die CPU geht im Leerlauf auf 800 MHz und hat den vollen Turbo bis 3600 MHz zur Verfügung. Genau so soll es sein.
Wichtig war mir noch die Gegenprobe, dass ich mir das Netzwerk nicht zerschossen habe. Die Karte, deren Option-ROM ich abgeschaltet habe, ist schliesslich die, über die diese Maschine am Netz hängt:
$ ethtool ens6f1np1 | grep -E 'Speed|Link detected'
Speed: 10000Mb/s
Link detected: yes
Unverändert. Das ist auch zu erwarten, denn der Treiber im laufenden Betrieb kommt aus dem Kernel und hat mit dem Option-ROM nichts zu tun. Das Option-ROM ist reiner Startcode. Trotzdem ist das der Punkt, an dem die meisten zögern, deshalb steht die Messung hier.
Ein Punkt ist noch offen, und den will ich nicht verschweigen: der ursprüngliche Anlass für das Abschalten von SLOT6 war eine Meldung auf der Treiberstatus-Seite im Setup, wo meine Netzwerkkarte seit einem Firmware-Update als *Failed* geführt wird. Ob die Meldung jetzt weg ist, kann ich von aussen nicht sehen. Das prüfe ich beim nächsten Setup-Besuch nach.
Gibt es dafür keine Oberfläche?
Diese Frage lag für mich die ganze Zeit im Raum, und die Antwort ist unbefriedigend.
Es gäbe einen herstellerneutralen Weg unter Linux. Der Kernel kennt eine Geräteklasse namens firmware-attributes, über die sich BIOS-Einstellungen als ganz normale Dateien lesen und schreiben lassen. Der Firmware-Updater fwupd kann das seit Version 1.8.4 direkt bedienen. Das wäre die Lösung: ein Kommando, egal welcher Hersteller.
Auf meiner Maschine sieht das so aus:
$ ls /sys/class/firmware-attributes/
ls: cannot access '/sys/class/firmware-attributes/': No such file or directory
$ fwupdmgr get-bios-setting
This system doesn't support firmware settings
Das Hilfsmodul dafür liegt im Kernel, es ist also nicht so, dass die Infrastruktur fehlen würde:
/lib/modules/7.0.0-28-generic/kernel/drivers/platform/x86/firmware_attributes_class.ko.zst
Was fehlt, ist der Treiber des Herstellers. Der Kernel bringt genau drei mit:
drivers/platform/x86/dell/dell-wmi-sysman Dell
drivers/platform/x86/lenovo/think-lmi Lenovo
drivers/platform/x86/hp/hp-bioscfg HP
Supermicro ist nicht dabei. Statt eines Treibers, der diese Kernel-Schnittstelle bedient, gibt es ein eigenes Werkzeug und eine Lizenz. Auf einem Dell oder Lenovo wäre der Inhalt dieses Beitrags ein Einzeiler ohne Zusatzkosten.
Ganz ohne Oberfläche ist man aber nicht. Das Werkzeug bringt einen textbasierten Editor mit, der das Setup im Terminal nachbaut:
./saa -c GetCurrentBiosCfg --tui
Dazu gibt es --compact, das anschliessend nur die geänderten Zeilen herausschreibt. Über eine SSH-Pipe blieb das Fenster bei mir schwarz, es braucht ein echtes Terminal. Ausprobiert habe ich es deshalb noch nicht richtig. Und es gibt das Werkzeug ausserdem als Windows-Version und als Variante für die UEFI-Shell, also für den Fall, dass überhaupt kein Betriebssystem installiert ist.
Eine echte grafische Oberfläche gibt es auch, sie heisst SSM. Die will dann allerdings wieder die grosse Lizenz.
Zurück auf Anfang
Das Wichtigste zum Schluss, und man legt es sich besser vorher zurecht als hinterher. Vor dem Schreiben habe ich den vollständigen Stand weggesichert. Der Rückweg ist dann dasselbe Kommando mit dieser Datei:
./saa -c ChangeBiosCfg --file bios-current-2026-08-09.xml
Als Notnagel gibt es darunter noch LoadDefaultBiosCfg, das alles auf den Auslieferungszustand zurücksetzt. Das ist aber ein grober Hebel: es wirft auch die sechs Abweichungen weg, die ich absichtlich eingestellt habe, und die stehen dann eben nicht mehr so, wie ich sie haben will. Die Teildatei ist der bessere Weg, der Vollreset die letzte Reserve.
Und weil es hier um Firmware geht, der offensichtliche Hinweis: bei einem Rechner, an den du nicht rankommst, änderst du keine Boot-Einstellungen, ohne dass jemand vor Ort ist oder die Fernkonsole zuverlässig läuft. Ich habe das Option-ROM der Grafik und das des Management-Controllers genau deshalb nicht angefasst.
Was bleibt
Sieben Einstellungen, ein Neustart, kein Setup-Besuch. Das klingt nach wenig, ändert aber die Arbeitsweise. BIOS-Einstellungen waren für mich bisher etwas, das man beim Aufbau einmal einstellt und danach ungern anfasst, weil jede Änderung einen Neustart mit Tastatur und Monitor bedeutet. Jetzt sind sie eine Datei, die ich versionieren, vergleichen und zurückspielen kann.
Der schönste Nebeneffekt war die Sache mit den Hardware P-States. Ich hatte das Verhalten meiner CPU wochenlang für eine Eigenheit des Kernels gehalten und in die falsche Richtung gesucht. Es war eine einzige Zeile in einem Menü, das vier Ebenen tief liegt und das ich beim Durchklicken nie geöffnet hatte. Eine durchsuchbare Datei aller 372 Einstellungen hätte mir das in dreissig Sekunden gezeigt.
Falls du auf demselben Board sitzt: das Auslesen ist der Beitrag davor, das Schreiben braucht keine weitere Lizenz, und die drei Stolperstellen sind der Filter, der nur als Wort funktioniert, die Gegenprobe, die vor dem Neustart nichts zeigt, und die Versuchung, mehr auf einmal zu ändern, als man beim nächsten Start noch reparieren kann.
Siehe auch: Achtundzwanzig Euro für eine Textdatei: die BIOS-Konfiguration meines Supermicro-Boards auslesen und die Serie BIOS erklärt.
Wenn dazu etwas unklar ist oder du es auf deinem Board anders erlebt hast, dürft ihr mich sehr gerne fragen.
Achtundzwanzig Euro für eine Textdatei: die BIOS-Konfiguration meines Supermicro-Boards auslesen
In meiner Serie BIOS erklärt arbeite ich mich durch das Setup eines Supermicro X12SPi-TF. Die Grundlage dafür war bisher eine Bildschirmaufnahme: ich bin durch alle Menüs gelaufen, habe das Video in Einzelbilder zerlegt und die Werte abgetippt. Das funktioniert, ist aber Handarbeit, und Handarbeit übersieht Dinge.
Was ich eigentlich wollte, ist eine Datei. Eine Liste aller Optionen mit ihrem aktuellen Wert, maschinenlesbar, damit ich sie durchsuchen und mit einem späteren Stand vergleichen kann. Das Board kann das. Es rückt es nur nicht heraus.
Drei Wege, drei Absagen
Der erste Weg führt über Redfish, die HTTP-Schnittstelle des Management-Controllers. Der passende Endpunkt existiert, antwortet aber nicht mit Daten:
GET /redfish/v1/Systems/1/Bios
HTTP 403
"MessageId": "SMC.1.0.OemLicenseNotPassed",
"Message": "Not licensed to perform this request. The following licenses DCMS were needed"
Der zweite Weg ist Supermicros eigenes Kommandozeilenwerkzeug. Es heißt inzwischen SAA, SuperServer Automation Assistant, und liegt dem BIOS-Paket bei. Es kann genau das, was ich suche, und arbeitet dabei nicht über das Netz, sondern direkt über die Firmware:
./saa -c GetCurrentBiosCfg --file bios-current.xml
ExitCode 80
Node product key is not activated.
One of the node product key (SFT-OOB-LIC or SFT-DCMS-SINGLE) should be activated
Der dritte Weg wäre, die UEFI-Variablen selbst zu lesen. Die liegen unter /sys/firmware/efi/efivars/, und tatsächlich gibt es dort Einträge, die nach BIOS-Einstellungen aussehen. Nur sind das undurchsichtige Datenblöcke ohne die Zuordnungstabelle des Boards. Man sieht Bytes, aber man weiß nicht, welches Byte welcher Menüpunkt ist.
Drei unabhängige Wege, dieselbe Sperre. An dieser Stelle habe ich in meinen Notizen etwas geschrieben, das sich später als falsch herausstellte. Dazu komme ich am Ende.
Zwei Lizenzen, und sie sind nicht dasselbe
Lies die beiden Fehlermeldungen oben noch einmal nebeneinander. Sie verlangen nicht das Gleiche. Redfish nennt namentlich DCMS. SAA nennt SFT-OOB-LIC oder SFT-DCMS-SINGLE, also eine von zweien.
Das ist der Punkt, an dem man leicht zu viel Geld ausgibt. Supermicro verkauft für diese Board-Generation zwei Lizenzen. Die kleine heißt Out of Band, kurz OOB. Die große heißt DCMS und kostet etwa das Fünffache. Wer nur die Fehlermeldung von Redfish liest, kauft DCMS. Wer die Fehlermeldung von SAA liest, merkt, dass es für seinen Zweck auch die kleine tut.
Nebenbei taucht dieselbe Lizenz an einer Stelle auf, die ich nicht erwartet hätte. Im Handbuch zum Board stehen bei zwei Sicherheitseinstellungen, nämlich beim Abschalten der vorderen und der hinteren USB-Anschlüsse, die Worte *available for configuration if the SFT-DCMS-SINGLE license is installed*. Es fehlen also nicht nur Management-Schnittstellen. Es fehlen zwei Menüpunkte im Setup selbst.
Warum man den Schlüssel nicht selbst baut
Bei dieser Recherche stößt man unweigerlich auf ein Werkzeug auf GitHub, das Supermicro- Produktschlüssel behandelt. Für die Generationen 9 bis 11 kann es welche erzeugen, denn dort war der Schlüssel ein berechneter Wert über die MAC-Adresse des Management-Controllers.
Für die zwölfte Generation, also mein Board, kann es das nicht, und das Projekt schreibt es selbst deutlich hin: dieses Format lässt sich mit dem Werkzeug prüfen, aber nicht erzeugen. Der Grund ist, dass Supermicro umgestellt hat. Der Schlüssel ist heute eine von Supermicro signierte Datei, und der Management-Controller prüft die Signatur gegen einen öffentlichen Schlüssel in seiner eigenen Firmware. Ohne den privaten Schlüssel des Herstellers entsteht da nichts Gültiges.
Mein Board bestätigt das Format auf Nachfrage:
Node Product Key Format..........JSON
Damit ist die naheliegende Abkürzung nicht moralisch, sondern rechnerisch verschlossen. Man muss die Frage also wirklich beantworten.
Der Kauf, und eine Überraschung beim Erzeugen
Gekauft habe ich im Supermicro eStore. 23,67 Euro netto, 28,17 Euro brutto. Bei der Bestellung wählt man das Mainboard-Modell aus einer Liste, und mein X12SPi-TF steht darin. Das ist erwähnenswert, weil mehrere Händlerbeschreibungen dieser Lizenz nur X10 und X11 nennen. Diese Texte sind veraltet.
Jetzt kommt der Teil, den ich falsch erwartet hatte. Ich dachte, ich kaufe und bekomme einen Schlüssel. So läuft es nicht. Man bekommt zunächst nur eine Zertifikatsnummer und die Aufforderung, den Schlüssel selbst zu erzeugen. Dafür meldet man sich im Store an, wählt die Bestellung aus und gibt an, für welches Gerät der Schlüssel gelten soll: entweder die MAC-Adresse des Management-Controllers oder die Seriennummer des Boards.
Die Bindung an die Hardware entsteht also nicht beim Verkauf, sondern beim Käufer, im Moment des Erzeugens. Das ist konsequent, denn Supermicro weiß beim Verkauf ja gar nicht, in welchem Gerät die Lizenz landen soll. Es heißt aber auch, dass man sich vertippen kann, und dann hat man einen Schlüssel für ein Gerät, das es nicht gibt.
Der Ablauf war zügig. Bestellbestätigung um 14:17, die Freigabe zum Erzeugen um 14:42, der fertige Schlüssel um 14:44, aktiv im Board um 14:46. Unter einer halben Stunde vom Klick bis zur Funktion, und die zugesagte Stunde war damit nicht zu optimistisch.
Der Schlüssel selbst ist eine kleine Textdatei, benannt nach der MAC-Adresse, mit einem JSON-Objekt darin: Lizenzname, Ausstellungsdatum und eine lange Signatur. Mehr ist es nicht.
Eine Kuriosität am Rande: die Mail mit dieser Textdatei trägt einen Ausfuhrhinweis der US-Regierung. Die Ware sei nur für das Bestimmungsland freigegeben und dürfe nicht weiterveräußert oder an Dritte weitergegeben werden. Das gilt hier für eine Datei von wenigen hundert Byte, deren einzige Wirkung darin besteht, in einem Verwaltungscontroller einen Menüpunkt sichtbar zu machen.
Aktivieren
Supermicro nennt vier Wege, den Schlüssel einzuspielen: die Weboberfläche des Management-Controllers, das Werkzeug SUM, die Verwaltungssoftware SSM und Redfish. Die Weboberfläche ist der ruhigste Weg, weil sie eine Bestätigungsseite hat, und bei einem Schlüssel, der genau einmal auf genau ein Gerät passt, will man die haben.
Wer es lieber skriptet, findet die passenden Endpunkte im Management-Controller, und die sind auch ohne Lizenz erreichbar:
POST /redfish/v1/Managers/1/LicenseManager/Actions/LicenseManager.ActivateLicense
POST /redfish/v1/Managers/1/LicenseManager/Actions/LicenseManager.ClearLicense
GET /redfish/v1/Managers/1/LicenseManager/QueryLicense
Die Abfrage danach gibt genau den Inhalt der Datei zurück, die man hochgeladen hat. Der Controller speichert den Schlüssel also unverändert und prüft ihn bei Bedarf.
Das Kommando, auf das es ankommt
Nach der Aktivierung meldet SAA einen anderen Zustand:
Node Product Key Activated.......SFT-OOB-LIC
Feature Toggled On...............Yes
BMC Supports OOB BIOS Config.....Yes
BIOS Supports OOB BIOS Config....Yes
Und dasselbe Kommando, das vorher mit ExitCode 80 abgebrochen ist, läuft durch:
./saa -c GetCurrentBiosCfg --file bios-current.xml
File "bios-current.xml" is created.
Heraus kommt eine Datei von 260 Kilobyte mit 60 Menüs und 372 Einstellungen. Zum Vergleich: das offizielle Handbuch beschreibt 180 Optionen. Und die Datei enthält pro Eintrag mehr, als man im Setup sieht, nämlich zusätzlich den Auslieferungszustand und den Hilfetext:
<Setting name="Quiet Boot" checkedStatus="Unchecked" type="CheckBox">
<Information>
<DefaultStatus>Checked</DefaultStatus>
<Help>Enables or disables Quiet Boot option</Help>
</Information>
</Setting>
Der Auslieferungszustand ist der eigentliche Gewinn. Damit sehe ich auf einen Blick, welche Einstellungen an dieser Maschine vom Werkszustand abweichen, und das ist genau die Liste, die man nach einem BIOS-Update wiederherstellen will.
Zwei komplette Hauptmenüs standen darin, die ich beim Durchklicken schlicht nie geöffnet hatte. Und ein Untermenü, das ich in meinen Notizen als offene Lücke geführt habe, war vollständig enthalten. So viel zum Thema Handarbeit übersieht Dinge.
Was die Lizenz nicht freischaltet
Jetzt der ehrliche Teil, und der ist mir wichtiger als der Erfolg. Ich hatte vor dem Kauf drei Messungen aufgeschrieben, damit ich hinterher vergleichen kann. Drei von vier Erwartungen sind eingetroffen, und die vierte war die interessante.
Der Redfish-Endpunkt, mit dem alles anfing, antwortet weiterhin mit 403 und verlangt weiterhin DCMS. Die kleine Lizenz öffnet den Weg über SAA und eben nicht den über Redfish. Wer also ausdrücklich die Netzwerkschnittstelle braucht, etwa weil er hunderte Server ohne Betriebssystem konfigurieren will, kommt um die große Lizenz nicht herum.
Das hat eine Nebenwirkung, die ich nicht auf dem Zettel hatte. Der Firmware-Updater fwupd kann inzwischen mit Supermicros Redfish-Schnittstelle sprechen. Er sieht bei mir aber nur zwei von zwölf Firmware-Komponenten, und die beiden BIOS-Einträge fehlen. Der Grund ist, dass er zur Identifikation eines Geräts das Objekt lesen muss, das hinter genau diesem gesperrten Endpunkt liegt. Die Lizenz sperrt hier also nicht das Aktualisieren, sondern das Erkennen, und das Aktualisieren scheitert dann als Folge. Nach der Aktivierung sind es unverändert zwei von zwölf.
Und der dritte Weg, den ich vorher gar nicht gesehen hatte: fwupd sieht den BIOS-Speicher auch ganz direkt am Chipsatz, liest die Version korrekt aus und verweigert trotzdem den Dienst:
Internal SPI Controller (BIOS):
Aktuelle Version: 2.5
Probleme: Device firmware has been locked
Das ist keine Lizenzsache, und daran hat sich erwartungsgemäß nichts geändert. Der Speicher ist auf Chipsatzebene schreibgeschützt, weil das Board mit aktivem Root of Trust läuft. Ein BIOS, das sich aus einem laufenden Betriebssystem heraus überschreiben lässt, wäre genau die Lücke, die dieser Schutz verhindern soll. Der Reflex sagt hier Hersteller blockiert Linux. Tatsächlich blockiert eine Sicherheitsfunktion, die ich selbst haben will.
Mein Denkfehler
Bleibt der Satz, den ich weiter oben angekündigt habe. In meinen Notizen stand nach der dritten Absage sinngemäß: drei unabhängige Wege, dieselbe Sperre, nicht erneut versuchen.
Gemessen hatte ich: ohne Lizenz gibt es keinen Weg. Aufgeschrieben hatte ich: es gibt keinen Weg. Und die dritte Möglichkeit, nämlich die Lizenz einfach zu kaufen, kam in meiner Aufzählung der drei gesperrten Wege überhaupt nicht vor, obwohl das Werkzeug sie mir wörtlich genannt hatte.
Dass drei Wege an derselben Sperre scheitern, beweist, dass es eine Sperre gibt. Es beweist nicht, dass sie unüberwindbar ist. Wenn eine Fehlermeldung den Namen der fehlenden Berechtigung nennt, ist das ein Hinweis und kein Schlusspunkt.
Lohnt sich das?
Für einen einzelnen Rechner zu Hause: nur, wenn man Freude daran hat. Ich hätte die Werte auch weiter abschreiben können, und der Screencast hat mir immerhin eine fünfzehnteilige Serie eingebracht, die aus einer XML-Datei nie entstanden wäre. Man liest eine Datei nicht so aufmerksam wie ein Menü, durch das man sich selbst klicken muss.
Für alles, was mehr als eine Handvoll Maschinen betrifft, sieht es anders aus. Konfiguration auslesen, versionieren, nach einem Update wieder einspielen und im Zweifel gegen einen bekannten Stand vergleichen, das ist bei 28 Euro pro Board keine Diskussion. Ärgerlich finde ich nur, dass man diese Rechnung überhaupt aufmachen muss. Es geht um das Auslesen der eigenen Einstellungen auf der eigenen Hardware.
Wenn du auf demselben Board sitzt und dieselbe Fehlermeldung vor dir hast, ist die Kurzfassung: für die Konfiguration reicht die kleine Lizenz, für Redfish brauchst du die große, und für Firmware-Updates brauchst du bei einem X12 mit Root of Trust vermutlich gar keine.
Siehe auch: BIOS erklärt, Teil 1: ein Serverboard als Workstation und der Weg ins Setup und die übrigen Folgen unter BIOS & Firmware.
Wenn dazu etwas unklar ist oder du es auf deinem Board anders erlebt hast, dürft ihr mich sehr gerne fragen.
Kontaktdaten von Sebastian van de Meer — erreichbar per E-Mail mit GPG-Verschlüsselung, Matrix, Threema/Signal und weiteren sicheren Kommunikationswegen.
Sebastian van de Meer (Kernel-Error)
