EFI-Fehlermeldung beim Booten

[susejunky]

Hallo @BeastXXL ,

da ich secureboot nicht nutze, habe ich mich auch noch nie richtig damit befasst.

Ich habe das Thema lediglich in der openSUSE-Mailingliste und im openSUSE-Forum gelesen und kann Dich nur an diese beiden Stellen verweisen (der von mir unter #19 verlinkte Mailinglisten-Beitrag beinhaltet Verweise auf das openSUSE-Forum und auf Bugzilla).

Tut mir leid! Aber vielleicht findet sich hier im Forum noch jemand, der Dir weiterhelfen kann.

Viele Grüße

susejunky

 

[BeastXXL]

Als ich auf der Suche war, wie andere einen Reset vom SBAT machen (würde), stieß ich auf diese Seite.
Mit meiner Vorgehensweise war ich gar nicht so falsch, denn im letzten Absatz steht:

To delete the policy, disable secure boot, run mokutil --set-sbat-policy delete, reboot, boot into the old shim to apply, and then turn secure boot back on again. Please note that booting the new shim after the reset will reapply the “previous” policy again.

Mich wundert, dass dort behauptet wird, dass mit dem shim-Update auf 15.7 die grub 1-Ebene nicht mehr läd und man bitte auf neuere Versionen der Distribution wechseln soll. Ist openSuse Leap 15.4 in diesem Punkt so alt, dass es hier Probleme gibt? Wenn ja, wie fixt man das?

Und noch eine Frage:
Vermutlich ist bootx64.efi der Fallback Bootloader. Wenn ich unter Windows der Pfad auf diese Datei statt auf shim lenke, sollte das Booten doch ohne Fehlermeldung funktionieren. Wenn dem so ist, warum sollte ich shim verwenden? Was ist der Vorteil von shim? Oder gibt es einen (großen?) Nachteil bei bootx64.efi?

 

[josef-wien]

Auf Grund von Beitrag 3 vermute ich, daß \EFI\BOOT\BOOTX64.EFI eine Kopie von \EFI\MICROSOFT\BOOT\BOOTMGFW.EFI ist.

\EFI\OPENSUSE\SHIM.EFI benötigst Du bei aktiviertem "secure boot". \EFI\OPENSUSE\GRUBX64.EFI funktioniert nur ohne "secure boot" (und kann laut Beitrag 1 im UEFI-Boot-Menü ausgewählt werden).

 

[susejunky]

Hallo @BeastXXL ,

... warum sollte ich shim verwenden? Was ist der Vorteil von shim?

siehe:

In the world of UEFI, securing the bootstrapping process means establishing a chain of trust. The “platform” is the root of this chain of trust; in the context of openSUSE Leap, the mainboard and the on-board firmware could be considered the “platform”. In other words, it is the hardware vendor, and the chain of trust flows from that hardware vendor to the component manufacturers, the OS vendors, etc.

The trust is expressed via public key cryptography. The hardware vendor puts a so-called Platform Key (PK) into the firmware, representing the root of trust. The trust relationship with operating system vendors and others is documented by signing their keys with the Platform Key.

Finally, security is established by requiring that no code will be executed by the firmware unless it has been signed by one of these “trusted” keys—be it an OS boot loader, some driver located in the flash memory of some PCI Express card or on disk, or be it an update of the firmware itself.

To use Secure Boot, you need to have your OS loader signed with a key trusted by the firmware and you need the OS loader to verify that the kernel it loads can be trusted.

Viele Grüße

susejunky

 

[BeastXXL]

Zunächst einmal zu meiner Frage, wozu man shim benötigt: Die Frage war etwas zu kurz gedacht, da ja nicht jeder ein Dualboot-PC hat und dann natürlich shim braucht, wenn er/sie ein Linux mit aktiviertem SecureBoot booten möchte.

Wie man sehen kann, scheint das Problem gelöst zu sein (jedenfalls hoffe ich das ).

Das Problem dabei ist, dass ich nicht wirklich weiß, was ich gemacht habe bzw. was genau die Lösung bewirkt hat. Ich versuche das mal zu rekonstruieren:
Mit deaktiviertem SecureBoot habe ich

sudo mokutil --set-sbat-policy delete

ausgeführt und bei dem folgenden Reboot gesehen, dass die Fehlermeldung noch existiert.
Den obigen Code habe ich noch einmal ausgeführt, dann shim auf Vers. 15.4 downgradet. Nach dem Neustart war alles super (keine Fehlermeldung mehr).
Neustart, aber SecureBoot wieder aktiviert. Auch alles gut, aber leider shim auf Vers. 15.4. Und da ich keine Lust hatte, ein Update bei shim zu blocken, habe ich weiter experimentiert.
Daher wieder Neustart, dabei SecureBoot deaktiviert, den obigen Code ausgeführt, shim auf Vers. 15.7 upgegradet, Neustart. Nun kam ich zum ersten Mal auf die GRUB-Konsole. Da ich keine Ahnung habe/hatte, was ich hätte machen sollen, habe ich Reset gedrückt, SecureBoot deaktiviert und bin wieder ohne Fehlermeldung ins GRUB-Boot-Menü gekommen.
Wieder den obigen Code ausgeführt, Neustart, aber SecureBoot aktiviert, wieder auf die GRUB-Konsole gekommen.
Wieder Reset gedrückt. Ich wollte wieder mit deaktiviertem SecureBoot neustarten, da fiel mein Blick zufällig auf den Eintrag, welcher BootManager geladen werden soll. Statt meinem üblichen Windows Boot Manager (der nur entsteht, wenn ich unter Windows den Pfad auf shim leite), stand dort der "normale" openSuse-Boot-Loader (also der mit GRUBX64.EFI). Da das natürlich nicht mit SecureBoot funktioniert, wollte ich eigentlich wieder meinen alten Windows Boot Manager einstellen.
Dieser war nicht mehr da, dafür aber der opensuse-secureboot-Boot-Manager (der auch auf shim verweist). Den habe ich dann eingestellt und gebootet.
Siehe da: keine Fehlermeldung mehr und die Kistet bootet mit aktivem SecureBoot ganz normal.
Hier noch ein paar Ausgaben:

beastxxl@linux-5099:~> su
Passwort:
linux-5099:/home/beastxxl # efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0006,0005
Boot0000* opensuse-secureboot   HD(2,GPT,73a54532-793d-4332-97f9-48d9d4f783bb,0x109000,0x31800)/File(\EFI\OPENSUSE\SHIM.EFI)
Boot0005* opensuse      HD(2,GPT,73a54532-793d-4332-97f9-48d9d4f783bb,0x109000,0x31800)/File(\EFI\OPENSUSE\GRUBX64.EFI)..BO
Boot0006* Windows Boot Manager  HD(2,GPT,73a54532-793d-4332-97f9-48d9d4f783bb,0x109000,0x31800)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)..BO
linux-5099:/home/beastxxl # mokutil --sb-state
SecureBoot enabled
linux-5099:/home/beastxxl # sudo zypper se -s shim
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...

S  | Name                  | Type       | Version              | Arch   | Repository
---+-----------------------+------------+----------------------+--------+-------------------------------------------------------------
   | python3-ec2publishimg | Paket      | 2.0.0-1.20           | noarch | openSUSE-Leap-15.4-Oss
   | rshim                 | Paket      | 2.0.6.1.5-bp154.1.33 | x86_64 | openSUSE-Leap-15.4-Oss
i+ | shim                  | Paket      | 15.7-150300.4.11.1   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
v  | shim                  | Paket      | 15.4-4.7.1           | x86_64 | openSUSE-Leap-15.4-Oss
   | shim                  | Quellpaket | 15.7-150300.4.11.1   | noarch | Update repository with updates from SUSE Linux Enterprise 15
   | shim-susesigned       | Paket      | 15.4-3.10.1          | x86_64 | openSUSE-Leap-15.4-Oss
linux-5099:/home/beastxxl #

Ich freue mich auf jeden Fall, dass das Problem nicht mehr existiert. Bitte Daumen drücken, dass es so bleibt.

 

[BeastXXL]

OK, leider hat es doch nicht geklappt. Nach einem Shutdown (für über eine Stunde) war die Fehlermeldung wieder da.
Bin jetzt bei shim auf Vers. 15.4 runter, habe es für Updates geblockt und nun keine Fehlermeldung mehr. Das Problem ist zwar "quasi gelöst", aber nicht richtig.

Daher bitte Hinweise geben, wie ich das Problem beheben kann. Bin nun wirklich am Ende meines Lateins.

 

[susejunky]

Hallo @BeastXXL ,

Daher bitte Hinweise geben, wie ich das Problem beheben kann. Bin nun wirklich am Ende meines Lateins.

wenn ich den zugehörigen Fehlerbericht richtig verstehe, dann gibt es im Augenblick noch keine zuverlässige Lösung.

Ich würde secureboot vorerst deaktivieren und den Fortschritt der Fehlerbearbeitung verfolgen.

Viele Grüße

susejunky

 

[BeastXXL]

Hallo @susejunky,

vielen Dank für den Link zum Fehlerbericht! Ich habe schon langsam an mir zu zweifeln begonnen. Dann besteht ja die berechtigte Hoffnung, dass das Problem tatsächlich genauer untersucht und wahrscheinlich sogar gelöst wird.

Aber, wenn schon diese Frage im Raum steht (Comment 17):

Question is how the new shim was installed and executed at least once and later the old one took over again, from some mystery location.

dann brauch ich mich nicht wundern, dass ich nicht weiterkomme.

Ja, dann werde ich wohl secureboot erstmal abschalten und den Standard-opensuse-Bootmanager (GRUBX64.efi) verwenden.

 

[BeastXXL]

Gestern gab es ein Update der shim-Datei. Hat aber nicht die erhoffte Wirkung gezeigt. Bin mir aber nicht sicher, ob ich einen Fehler gemacht habe.
Hab das Update installiert, unter Windows den Pfad für den Win-Boot-Manager auf shim gelenkt (bcdedit ...) und beim Neustart im BIOS SecureBoot aktiviert und den passenden Bootmanager bei den Prioritäten auf #1 gesetzt.
Beim Neustart kam dann der Bluescreen mit der MOK-Sache. Und hier weiß ich nicht genau, ob ich alles richtig gemacht habe.
Bei der Passworteingabe habe ich das Linux-Passwort genommen, was mich dann zur Auswahl brachte "Reboot, Key from disk, Key from hash". Hier habe ich Reboot genommen, weil mir das am Sichersten schien.

Lange Rede, kurzer Sinn: ich bekomme die selbe Fehlermeldung wie früher und bin mir nicht sicher, ob ich bei der MOK-Aktion etwas anders hätte machen müssen, damit die Fehlermeldung verschwindet.

Bin jetzt wieder ohne SecureBoot auf den opensuse-Bootmanager.

 

[susejunky]

Hallo @BeastXXL ,

Bei der Passworteingabe habe ich das Linux-Passwort genommen, ...

was muss man sich unter "Linux-Passwort" vorstellen? Das Kennwort eines Benutzers? Das Kennwort des Administrators ("root")?

Beim Neustart kam dann der Bluescreen mit der MOK-Sache. Und hier weiß ich nicht genau, ob ich alles richtig gemacht habe.

wie bereits gesagt, ich nutze kein secureboot aber ich hatte mir einmal folgendes notiert (aber nie verifiziert!):

cd /etc/uefi/certs

mokutil --import NAME_DES_AKTUELLEN_ZERTIFIKATS.crt --root-pw

systemctl isolate reboot

Beim Neustart wird ein blauer Bildschirm angezeigt mit

(select)
    "Press any key to perform MOK management"

    - continue boot
    - enroll MOK
    - enroll key from disk
    - enroll hash from disk
    
auswählen:     - enroll MOK

dann wird angezeigt:

    - View key0
    - Continue

auswählen:     - Continue

dann wird angezeigt:

Enroll the key(s)?
    - No
    - Yes

auswählen:     - Yes

dann "root"-Kennwort eingeben

dann wird angezeigt:

Perform MOK management
    - reboot
    - Enroll key from disk
    - Enroll hash from disk

auswählen:     - reboot

Viele Grüße

susejunky

 

[BeastXXL]

Hallo @susejunky ,

ja, ich hatte das Admin-Passwort gemeint.

Ich kann es nicht mehr 100% bestätigen, aber anhand deines Ablaufes glaube ich, dass ich bei den einzelnen Punkten intuitiv die "richtige" Auswahl gewählt hatte. Bei meinem Post #29 meinte ich, dass ich mir beim letzten Punkt (deines Ablaufes) nicht sicher war, ob ich mit "reboot" die richtige Wahl getroffen hatte. Aber anscheinend habe ich es.

Hat nur leider nicht geholfen

Viele Grüße,
B.