Schlagwort ASRock DeskMini X300 (Seite 1/1)

Nach der BIOS-Aktualisierung eines ASRock DeskMini X300 auf die seit 16. Januar 2026 angebotene Version 2.20 erschien beim folgenden Systemstart eine Warnmeldung:

Laut Changelog sollte das Update im Wesentlichen zwei Punkte verändern:

Update AMD AM4 AGESA Combov2 PI 1.2.0.10

Update Secure Boot Key (2023 KEK/DB/PK)

Somit lag der Gedanke nahe, daß ASRock mit Hinzufügen des ab 2023 gültigen Keysgleichzeitig den seit 2011 gültigen Secure Boot Key entfernt hatte, so daß es - je nach Kombination aus Betriebssystem und fehlender Signatur - zu der “Secure Boot Violation” kommt.

Erste Anlaufstelle war der “Secure Boot"-Beitrag des Debian Wikis, der im Abschnitt “I have shim and the Debian bootloader installed, and with secure boot enabled the machine fails to boot!” auf auf das mögliche Fehlen genau dieses Schlüssels und die damit verbundenen Probleme hinweist.

Mit Hilfe von “mokutil” lassen sich die in der Datenbank vorhandenen Schlüssel überprüfen und der “UEFI CA 2011”-Schlüssel war weiterhin auf dem System vorhanden:

	$ mokutil --db | grep UEFI
        Subject: C=US, O=Microsoft Corporation, CN=Microsoft UEFI CA 2023
        Subject: C=US, O=Microsoft Corporation, CN=Windows UEFI CA 2023
        Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011

Somit konnte ein fehlender Schlüssel nicht der Grund des veränderten Bootverhaltens sein und weitere Recherche war angesagt.

Den entscheidenden Hinweis lieferte die Ausgabe von “efibootmgr” - zum ursprünglichen Boot-Eintrag hatte sich noch ein zweiter Eintrag gesellt und dieser wurde auch zum Starten verwendet:

	$ efibootmgr
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0000
Boot0000* debian	HD(...)/File(\EFI\DEBIAN\SHIMX64.EFI)
...
Boot0001* debian	HD(...)/File(\EFI\DEBIAN\GRUBX64.EFI)0000424f
...

Wie in der Ausgabe zu sehen, verwendet der Eintrag “Boot0001” den Pfad “\EFI\DEBIAN\GRUBX64.EFI” und da “GRUBX64.EFI” nicht mit dem “UEFI CA 2011”-Schlüssel signiert ist, kommt es zu der “Secure Boot Violation”. Der ursprüngliche (korrekte) Eintrag ist “Boot0000” mit dem Pfad “\EFI\DEBIAN\SHIMX64.EFI”, der mit “SHIMX64.EFI” auch den von Microsoft signierten Bootloader verwendet.

Nach Änderung der Bootreihenfolge startete das System wieder ohne zu Meckern mit Secure Boot:

	$ mokutil --sb-state
SecureBoot enabled

Hintergrundinformationen zur grundlegenden Thematik liefert der Mircosoft Support-Beitrag “Ablauf des Windows Secure Boot-Zertifikats und Updates der Zertifizierungsstelle”.

Nachdem der aktuelle Arbeits-PC inzwischen mehr als sechs Jahre alt ist wurde es Zeit, sich über einen Nachfolger Gedanken zu machen. Grundlegend stellt sich die Frage, ob ein klassischer PC im Tower-Gehäuse überhaupt noch zeitgemäß ist, denn im Gegensatz zu früheren Jahren übernimmt der Chipsatz die meisten Zusatzfunktionen und lediglich eine steckbare Graphikkarte bleibt als Argument für ein größeres Gehäuse.

Im bisherigen PC ist eine NVIDIA GeForce GTX 1050 Ti verbaut, eine Tatsache die ich seit dem Wechsel auf Linux gerne geändert hätte. Daß sinnvolle NVIDIA-Treiber nur als proprietäre Lösung verfügbar sind ist eine Sache, weit ärgerlicher ist aber, daß diese nur den veralteten X-Server unterstützen und nicht das deutlich modernere Wayland Display-Server-Protokoll.

Passend zu den Überlegungen erschien im Laufe des Jahres der c’t Bauvorschlag: Ryzen-Mini-PC, der die Blaupause für den neuen PC lieferte. Auf Bildern sind Größen meist schlecht einzuschätzen, vor allem ohne Vergleich. Freundlicherweise hat sich Harumi für einen Fototermin eingefunden und vor dem Gerät posiert.

Vollständigen Beitrag lesen

ASRock DeskMini X300

ASRock DeskMini X300: Secure Boot Violation nach BIOS-Update

Ryzen-Mini-PC