Vielleicht passen in diesen Thread noch ein paar Erfahrungen, die ich gerade mit dem Boot von buster gemacht habe.
Anlass für eine Neuinstallation von buster war, daß ich mit einem kleinen Acer E3 notebook ständig Probleme im UEFI legacy modus hatte (nach kernel-updates inklusive initramfs-Aktualisierungen hing der Boot meist beim Laden der initramfs). Vermutlich ein realer Fall von schlampig implementiertem Kompatibilitätsmodus, von dem man gelegentlich nur liest.
Diesmal sollte es deshalb "normales" UEFI mit GPT werden. Also UEFI-BIOS resettet und die eMMC-Flashdisk neu formatiert und eine EFI-Partition anlegen lassen. Um es etwas abzukürzen: Das neue System startete nach vielen Umwegen erst, nachdem ich im expert install mode explizit die Installation von grub auch im removable path oder so ähnlich zugelassen und SecureBoot im BIOS-setup abgestellt hatte.
Ich war die letzten Tage erstmal froh, wieder ein bootfähiges Gerät zu haben. Unangenehm aufgefallen war mir aber schon, daß in der Boot-Reihenfolge ganz oben ein Eintrag mit "Linpus" auftauchte und erst an zwei die eMMC 32 GB (boot über den eMMC-Eintrag funktionierte aber nicht). Das Acer war ursprünglich mal mit Linpus-Linux ausgeliefert worden und irgendwo im UEFI / der eMMC sind da wohl noch Reste verankert (??).
Und schon beim ersten dist-upgrade heute ist mir dieses obskure Konstrukt gleich auf die Nase gefallen. Es waren nur rund 10 Paket-Updates, aber darunter grub-efi-amd64 und grub-efi-amd64-signed, die wohl beim Update alles wieder durchgerüttelt haben.
Das Acer kam in eine endlose Boot-Loop, bei der zwar immer ein paar Textzeilen aufblitzen, aber zu kurz zum Lesen.
Da ich wenigstens noch mit F2 ins BIOS-Setup gelangte, habe ich Rettungsversuche von dort unternommen. Irgendwo hatte ich mal aufgeschnappt, daß man im "SecureBoot" diverse Boot-Werkzeuge registrieren kann/muss. Unter einem entsprechenden Menüpunkt bekam ich Zugriff auf die EFI-Partition und zwei Pfade boot und debian. Etwas überfordert bzw. ohne ganz sicher zu sein entschied ich mich für debian/grubx64.efi und musste ihm noch einen Namen vergeben. Das reichte für einen erfolgreichen Boot noch nicht aus, erst musste im BIOS noch der neuentstandene Eintrag von grubx64 an oberste Stelle geschoben werden. Yay, Minimalziel war erreicht!
Da im debian Pfad aber auch noch 3-4 andere *.efi gelegen hatten, war ich erneut verunsichert, ob jetzt alles seine Richtigkeit hat. Insbesondere "shim", genauer debian/shimx64.efi, hatte ich hier im Forum schonmal aufgeschnappt. Also habe ich diese Datei im SecureBoot auch noch registriert, was abermals zu einem weiteren Eintrag in der Liste der Boot-Reihenfolge führte.
Auch mit shimx64.efi ließ sich das System booten, aber erst als ich SecureBoot im UEFI aktiviert habe, hat er den aktuellen buster-kernel zugelassen und gestartet.
Wenn ich das richtig sehe, beherrscht debian buster auf meinem System demnach jetzt
UEFI SecureBoot. Das erforderliche Authorisierungsgeraffel besteht demnach im Wesentlichen aus shim-signed, grub-efi-amd64-signed und linux-image-amd64.
Mal wieder ist alles irgendwie umständlicher geworden!
Ich überlege allerdings gerade, ob ich shimx64.efi wieder deaktiviere, denn auf dem Laptop läuft keine Window$-Software, weshalb ich mich eigentlich auch nicht auf die Micro$oft-lizensierten Boot-Werkzeuge einlassen sollte. Hmm ...
