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.
