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
Code:
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:
Code:
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.
Nach einem Shutdown (für über eine Stunde) war die Fehlermeldung wieder da.