Buster- Paket 'shim'?

Du kommst mit der Installation nicht voran oder willst noch was nachfragen? Schau auch in den "Tipps und Tricks"-Bereich.
Antworten
bullgard
Beiträge: 1432
Registriert: 14.09.2012 23:03:01

Buster- Paket 'shim'?

Beitrag von bullgard » 14.06.2019 15:41:24

Hallo debianforum.de,
https://bits.debian.org/tag/buster.html schreibt:
On amd64 machines, by default the Debian installer will now boot (and install) a signed version of the shim package as the first stage boot loader.
Auf meinem Debian unstable zeigt

Code: Alles auswählen

$ apt search shim
kein Paket
shim
an. Welches Paket »shim« ist hier gemeint?
Mit feundlichen Güßen
bullgard

Benutzeravatar
Lord_Carlos
Beiträge: 4532
Registriert: 30.04.2006 17:58:52
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Dänemark

Re: Buster- Paket 'shim'?

Beitrag von Lord_Carlos » 14.06.2019 15:46:30

Debianshim-signed nehme ich an.

Code: Alles auswählen

╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!

bullgard
Beiträge: 1432
Registriert: 14.09.2012 23:03:01

Re: Buster- Paket 'shim'?

Beitrag von bullgard » 14.06.2019 16:10:23

Hallo Lord_Carlos,
Lord_Carlos hat geschrieben: ↑ zum Beitrag ↑
14.06.2019 15:46:30
Debianshim-signed nehme ich an.

Code: Alles auswählen

$ apt search shim-signed
gibt aus:
Secure Boot chain-loading boot loader (Microsoft-signed binary)
.

whiizy
Beiträge: 569
Registriert: 23.07.2011 22:09:37

Re: Buster- Paket 'shim'?

Beitrag von whiizy » 23.06.2019 17:20:33

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 ...

Antworten