ASRock DeskMini X300: Secure Boot Violation nach BIOS-Update
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”.
Bis dahin kann der alte Key von Microsoft heruntergeladen und händisch im BIOS hinzugefügt oder Secure Boot deaktiviert werden.