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:

1. Update AMD AM4 AGESA Combov2 PI 1.2.0.10
2. 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:

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:

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:

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

Manchmal sieht man den Wald vor lauter Bäumen nicht und so habe ich die Tage einiges an Nerven (und auch Zeit) investiert, um herauszufinden, warum das Partial, welches für die Einbindung des Footers dieser Website zuständig ist, “.IsHome” so überhaupt nicht auswerten wollte.

Alle möglichen und unmöglichen Tricks über temporäre Variablenzuweisungen führten nicht zum gewünschten Ergebnis und wie so oft half eine Pause und anschließend ein frischer Blick auf den Code:

Das Partial “page-footer.html” war mittels der Funktion “partialCached” eingebunden, da der Footer rein statisch ist und somit nicht für jede Seite neu erzeugt werden muß. Dies bewirkt “leider” auch, daß der Wert von “.IsHome” nur bei der ersten Erstellung ermittelt und der ermittelte Wert anschließend auf allen weiteren Seiten verwendet wird.

Nach der Änderung von “partialCached” zu “partial” wurde “.IsHome” auch wie erwartet ausgewertet.

Spiel-Designer haben eine schwierige Aufgabe: in einer glaubwürdigen Welt für die Spieler herausfordernde - und gleichzeitig schaffbare - Aufgaben zu entwickeln, die im besten Fall auch noch originell und spannend sind.

In der Regel wird hierzu auch auf geskriptete Ereignisse zurückgegriffen, d.h. sobald der Spieler eine für ihn unsichtbare Linie in der Spielwelt überschreitet, wird ein Ereignis oder eine Reihe von Ereignissen ausgelöst. Was in räumlich begrenzten Spielwelten wie z.B. den engen Korridoren von Doom hervorragend funktioniert, wird umso schwieriger, je offener die Spielwelt wird.

Ein unschönes Beispiel, was passieren kann, wenn Spieler sich frei bewegen (können) zeigt eine der ersten Missionen “Spider and the Fly” aus dem Cyberpunk 2077-Addon “Phantom Liberty”, in deren Verlauf bei Annäherung an eine Straßenschlucht die Aufgabe

Reach the building while avoiding the patrols

gestellt wird.

Solange sich der Spieler an den wohl geplanten Weg hält, ist alles bestens: in der zu überquerenden Straßenschlucht stehen einige Wachen herum, ein Mech ist als Aufpasser zugegen und es kommen aus dem rechten Bereich immer wieder Patrouillenfahrzeuge entlang der Straße, welche die Aufgabe erschweren.

Nutzt man aber die Möglichkeiten der offenen Spielwelt und versucht, den Bereich von einem angrenzenden Gebäude aus vorab zu entschärfen, so wird der Eindruck einer lebendigen Welt schnell zerstört:

Nicht nur, daß die Fahrer der Patrouillenfahrzeuge ab und an so dämlich sind und schwungvoll in den eigenen Mech krachen - wenn die zum Fahrzeug gehörenden Wachen aussteigen und man diese z.B. als Netrunner mit einem Hack auschaltet, so löst sich das Fahrzeug nach einigen Sekunden sichtbar in Luft auf, nur um anschließend wieder vom (aus der Screenshot-Perspektive) hinteren Bildschirmrand erneut um die Ecke zu kommen.

Keine Ahnung, ob sich die Sequenz beliebig oft wiederholen lässt - ich habe nach ein paar Runden meine Idee enttäuscht zu den Akten gelegt und bin wie offensichtlich vorgesehen ohne weitere Vorbereitung durch die Straßenschlucht geschlichen.

Ungewöhnliche Fahrgastinformationen in Rouen: statt dem nächsten Halt und der aktuellen Fahrzeit gibt es die aktuelle IP-Adresse und noch ein paar zusätzliche technische Details zum Nahverkehrsbus der Transports en commun de l’agglomération rouennaise (TCAR) - touristenfreundlich in deutscher Sprache.

Bein Verfassen des Beitrags “Sechs Jahre Debian” stellte sich die Frage, wie der Installationszeitpunkt eines Linux-Systems herauszufinden ist. Die einfachste Variante ist wahrscheinlich der Befehlt “stat /”, welcher in der Ausgabe-Zeile “Geburt …” die gewünschte Information anzeigt:

Handelt es sich um ein Debian-basiertes System, so kann der Blick in das Verzeichnis “/var/log/installer/” ein paar zusätzliche Informationen liefern:

Die Datei “lsb-release” gibt hierbei auch Informationen zum verwendeten Installationsmedium: