Failed to open \EFI\BOOT\`- Invalid Parameter ist die erste Zeile, die man beim Booten von Ventoy 1.0.99 zu Gesicht bekommt. Neben Ventoy sind auch GNU/Linux Distributionen wie Fedora betroffen. Dort liegt allerdings nicht die Ursache, sondern im Shim, der wiederum für UEFI Secure Boot zur freiwilligen Pflicht geworden ist.
Das Problem
Tritt nur auf, wenn ausschließlich Secure Boot im UEFI aktiviert ist. Viele UEFI-Implementierungen haben (noch) einen Kompatibilitätsmodus, in dem sie sich wie der Vorgänger (BIOS) verhalten. Die Einstellung dazu heißt meist Legacy mode oder CMOS mode. Je nach Hersteller lässt sich nur einer der beiden Varianten aktivieren bzw. Secure Boot ist an UEFI gebunden. Manche erlauben auch eine Priorisierung: Beispielsweise bevorzugt UEFI starten und nur wenn das fehlschlägt, zurück zum BIOS-Modus.
In diesem Falle erscheint der Fehler ebenfalls, allerdings funktioniert Ventoy trotzdem – wird danach allerdings im BIOS Modus geladen, also ohne Secure Boot. Daher startet es selbst zum ersten Mal auf einem Gerät direkt in die Hauptoberfläche und überspringt die Schlüsselverwaltung.
Wegen eines Tests für einen anderen Beitrag brauchte ich eine Installation mit Secure Boot. Der Dell OptiPlex 7040 unterstützt das nur bei der Deaktivierung des BIOS-Modus, d.H. dieser wird erzwungen. Nach obiger Fehlermeldung meldet Ventoy Security Violation und bricht einige Sekunden später ab – ohne Möglichkeit, den Schlüssel hinterlegen zu können.
Das UEFI weiß dann auch nicht mehr weiter und fragt, was es nun tun soll.
Kontext: UEFI & Secure Boot zusammengefasst
Geht tiefer in Details, wie UEFI-Systeme mit Secure Boot starten. Die Grundidee dahinter: Man möchte den Startprozess in der Anfangsphase absichern. Das BIOS war simpel aufgebaut – In der Startreihenfolge sind verschiedene Medien (SSD/HDD, USB, Netzwerk usw.) definiert. Er versucht, nacheinander von jedem Medium zu starten, bis er ein startbares findet. Dort liegt im Regelfall ein Bootloader, der das Betriebssystem startet. Wer physischen Zugriff zum System hat, kann theoretisch Veränderungen vornehmen. Dank BIOS/UEFI Upgrades aus dem laufenden Betriebssystem heraus sind sogar Manipulationen der Firmware denkbar – in der Praxis selten.
Secure Boot setzt an, bevor das UEFI an den Bootloader übergibt und erlaubt nur noch bestimmte signierte Bootloader. Versucht man einen anderen (oder manipulierten) Bootloader zu starten, weicht die Prüfsumme ab – das UEFI verweigert den Start. In der Praxis ist das im Detail noch kompliziert. Außerdem funktioniert es alles andere als reibungslos, wie es dieser theoretische Ablauf vermuten lässt. Microsoft hielt es nicht davon ab, Secure Boot ab Windows 8 (2012) stark zu fördern.
Einer der größten Kritikpunkte daran ist: Um Signaturen prüfen zu können, bedarf es einer Stelle, die das beurteilt. Üblicherweise liefern Mainboard-Hersteller nur die Zertifikate von Microsoft aus.1 MS hat somit das Monopol für die Entscheidung, welche Bootloader starten dürfen. Ein Glück, dass MS so gnädig war, Shim zu signieren. Das ist ein Bootloader, der andere Bootloader nachladen kann. Unter GNU/Linux ist das meist ein Grub.2 Zusammengefasst wird schnell klar: Der Startprozess ist damit deutlich komplizierter geworden. Beim klassischen BIOS reichte die korrekte Startreihenfolge in der Regel aus.
Die Ursache
Liegt in den load options von UEFI, die dort als EFI_LOAD_OPTION definiert sind.3 Soweit ich es verstehe, geht es dabei um Parameter für den Bootloader,4 den Shim laden soll (second stage bootloader). Der Code von load-options.c ist schwer nachzuvollziehen.
Je nach Aufrufquelle scheinen diese Optionen unterschiedlich anzukommen. Bisher wurde geprüft, ob sämtliche Buchstaben der Zeichenkette NUL sind (also \0). Laut dem Pull Request rufen sie manche mit NUL gefolgt von Füllmaterial und einem Dateipfad auf.5 Das Problem scheint mit anderen ebenfalls zu existieren, die laut Code-Doku L"\0\0" übermitteln. Im Shim wurde die Prüfung abgeändert: Wenn diese im ersten Zeichen mit \0 beginnen, verwirft er sie.6 Anscheinend ist Ventoy einer von ihnen.
Klingt nach Chaos. Die Entwickler machen um die Umstände kein Geheimnis und beschreiben es wie folgt:
So, load options are a giant pain in the ass.
Der Workaround
Das Problem ist seit mehreren Monaten bekannt und tritt vor allem mit Geräten von Dell auf.7 Bei mir war es ein Dell OptiPlex 7040. Neben der Deaktivierung von Secure Boot gibt es einen Workaround. Für einen anderen Beitrag benötigte ich jedoch auf dem Testsystem zwingend Secure Boot, da die Windows 11 24H2 Builds ansonsten keine Zwangsverschlüsselung mit Bitlocker durchführen.
Lediglich ein Downgrade von Version 1.0.99 auf die vorherige 1.0.98 blieb somit als Workaround. Die älteren Versionen sind im Archiv von Ventoy selbst zu finden.8 Glücklicherweise unterstützt Ventoy2Disk auch das Herunterstufen der Version auf eine ältere. Durch Aufrufen der Anwendung aus dem älteren Paket war das auf identischem Wege möglich, wie man es sonst bei Upgrades durchführt. Mit 1.0.98 funktionierte der Start wieder.
- https://www.thomas-krenn.com/de/wiki/UEFI_Secure_Boot ↩︎
- https://www.pro-linux.de/news/1/19063/uefi-secure-boot-technische-beschreibung-von-shim.html ↩︎
- https://uefi.org/specs/UEFI/2.10/03_Boot_Manager.html#load-options ↩︎
- https://forum.osdev.org/viewtopic.php?t=55992 ↩︎
- https://github.com/rhboot/shim/pull/505 ↩︎
- https://github.com/rhboot/shim/pull/505/commits/72cd577ef0cea5d0e7fef4e98c2bbacf3b6a7210 ↩︎
- https://forums.ventoy.net/showthread.php?tid=2896&pid=8578#pid8578 ↩︎
- https://www.ventoy.net/en/downloadold.html ↩︎