• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

EFI-Fehlermeldung beim Booten

B

BeastXXL

Hacker
Hallo,

neuerdings bekomme ich beim Booten kurz eine Fehlermeldung angezeigt. Da ich kein vernünftiges Foto hinbekomme, verweise ich auf diesen Link, bei dem es ähnlich aussieht: Failed to open \EFI\UBUNTU\*garbled* - Invalid parameter
Unterschied zu mir: "opensuse" statt "ubuntu" beim Dateipfad und ich meine "shim" am Ende des Dateipfads gelesen zu haben

Kurz danach komme ich zum Grub-Boot-Menü und ich kann sowohl openSuse als auch Windows erfolgreich starten. Allerdings macht mich die Fehlermeldung nervös und ich habe keinen Plan, was das Problem bzw. die Lösung des Problems ist. Ich vermute ein Update für diesen Fehler (k.A., ob eine Windows- oder openSuse-Update).

Hier schon einmal folgende Ausgaben:
Code: 
beastxxl@linux-5099:~> sudo fdisk -l
[sudo] Passwort für root:
Festplatte /dev/nvme0n1: 465,76 GiB, 500107862016 Bytes, 976773168 Sektoren
Festplattenmodell: Samsung SSD 970 EVO Plus 500GB         
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: gpt
Festplattenbezeichner: EA09713B-815A-4E24-AB75-68DB3CF06510

Gerät             Anfang      Ende  Sektoren Größe Typ
/dev/nvme0n1p1      2048   1085439   1083392  529M Windows-Wiederherstellungsumgebung
/dev/nvme0n1p2   1085440   1288191    202752   99M EFI-System
/dev/nvme0n1p3   1288192   1320959     32768   16M Microsoft reserviert
/dev/nvme0n1p4   1320960 174112767 172791808 82,4G Microsoft Basisdaten
/dev/nvme0n1p5 174112768 593543167 419430400  200G Microsoft Basisdaten
/dev/nvme0n1p6 593543168 597737471   4194304    2G Linux Swap
/dev/nvme0n1p7 597737472 660649983  62912512   30G Linux-Dateisystem
/dev/nvme0n1p8 660649984 765507583 104857600   50G Linux-Dateisystem
beastxxl@linux-5099:~> sudo efibootmgr -v
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0004,0005
Boot0001* Windows Boot Manager  HD(2,GPT,73a54532-793d-4332-97f9-48d9d4f783bb,0x109000,0x31800)/File(\EFI\OPENSUSE\SHIM.EFI)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...9................
Boot0004  Windows Boot Manager  HD(2,GPT,73a54532-793d-4332-97f9-48d9d4f783bb,0x109000,0x31800)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)..BO
Boot0005  opensuse      HD(2,GPT,73a54532-793d-4332-97f9-48d9d4f783bb,0x109000,0x31800)/File(\EFI\OPENSUSE\GRUBX64.EFI)..BO
beastxxl@linux-5099:~>

Unter Windows habe ich einfach mal folgendes probiert, allerdings ohne Erfolg die Fehlermeldung zu beseitigen (SecureBoot ist aktiv):
Code: 
bcdedit /set {bootmgr} path \EFI\opensuse\shim.efi

Im Netz habe ich schon gesucht, aber da ich mich mit EFI so gar nicht auskenne, bin ich mir unsicher, was Erfolg verspricht und was nicht.

Vielen Dank im Voraus für Hinweise und Hilfe.
 
J

josef-wien

Ultimate Guru
Bei secure boot und openSUSE muß ich mich ziemlich heraushalten, aber die Ausgabe von efibootmgr gefällt mir nicht. Erstens meint das Ding, daß aktuell mit Boot0001 (= Windows) gestartet wurde. Hast Du in dessem Boot-Manager etwas hinsichtlich Linux eingetragen? Zweitens konnte man früher mit GRUBX64.EFI nicht bei aktivem secure boot starten (aber das mag sich geändert haben).

Die Ausgabe von
Code: 
ls -lR /boot/efi/EFI
könnte hilfreich sein,
 
OP
B

BeastXXL

Hacker
josef-wien schrieb:
Bei secure boot und openSUSE muß ich mich ziemlich heraushalten, aber die Ausgabe von efibootmgr gefällt mir nicht. Erstens meint das Ding, daß aktuell mit Boot0001 (= Windows) gestartet wurde. Hast Du in dessem Boot-Manager etwas hinsichtlich Linux eingetragen? Zweitens konnte man früher mit GRUBX64.EFI nicht bei aktivem secure boot starten (aber das mag sich geändert haben).
Zum Vergrößern anklicken....
Naja, mit meinem naiven Halbwissen dachte ich bisher, dass ich mit
Code: 
bcdedit /set {bootmgr} path \EFI\opensuse\shim.efi
den Windows-"Bootloader" dazu verwende, um zum GRUB-Bootloader zu navigieren. Jedenfalls hat das immer bei Installationen und Updates funktioniert, seit ich ein EFI-System habe (also seit ca. 3-4 Jahren).

Hier die Ausgabe (gekürzt, weil mein Beitrag sonst die 1000 Zeichen-Grenze sprengt):
Code: 
beastxxl@linux-5099:~> ls -lR /boot/efi/EFI
/boot/efi/EFI:
insgesamt 3
drwxr-xr-x 2 root root 1024 24. Aug 2019  Boot
drwxr-xr-x 4 root root 1024 24. Aug 2019  Microsoft
drwxr-xr-x 2 root root 1024  1. Sep 2019  opensuse

/boot/efi/EFI/Boot:
insgesamt 1551
-rwxr-xr-x 1 root root 1587552 10. Jan 20:13 bootx64.efi

/boot/efi/EFI/Microsoft:
insgesamt 6
drwxr-xr-x 40 root root 5120 24. Aug 2019  Boot
drwxr-xr-x  2 root root 1024 24. Aug 2019  Recovery

/boot/efi/EFI/Microsoft/Boot:
insgesamt 5852
-rwxr-xr-x 1 root root   45056 31. Mär 17:44 BCD
-rwxr-xr-x 1 root root   65536 24. Aug 2019  BCD.LOG
-rwxr-xr-x 1 root root       0 24. Aug 2019  BCD.LOG1
-rwxr-xr-x 1 root root       0 24. Aug 2019  BCD.LOG2
drwxr-xr-x 2 root root    1024 24. Aug 2019  bg-BG
-rwxr-xr-x 1 root root 1587552 10. Jan 20:13 bootmgfw.efi
-rwxr-xr-x 1 root root 1571168 10. Jan 20:13 bootmgr.efi
-rwxr-xr-x 1 root root   65536 14. Mär 21:52 BOOTSTAT.DAT
-rwxr-xr-x 1 root root    4933  9. Mär 2022  boot.stl
drwxr-xr-x 2 root root    1024 24. Aug 2019  cs-CZ
drwxr-xr-x 2 root root    1024 24. Aug 2019  da-DK
drwxr-xr-x 2 root root    1024 24. Aug 2019  de-DE
drwxr-xr-x 2 root root    1024 24. Aug 2019  el-GR
drwxr-xr-x 2 root root    1024 24. Aug 2019  en-GB
drwxr-xr-x 2 root root    1024 24. Aug 2019  en-US
drwxr-xr-x 2 root root    1024 24. Aug 2019  es-ES
drwxr-xr-x 2 root root    1024 24. Aug 2019  es-MX
drwxr-xr-x 2 root root    1024 24. Aug 2019  et-EE
drwxr-xr-x 2 root root    1024 24. Aug 2019  fi-FI
drwxr-xr-x 2 root root    3072 24. Aug 2019  Fonts
drwxr-xr-x 2 root root    1024 24. Aug 2019  fr-CA
drwxr-xr-x 2 root root    1024 24. Aug 2019  fr-FR
drwxr-xr-x 2 root root    1024 24. Aug 2019  hr-HR
drwxr-xr-x 2 root root    1024 24. Aug 2019  hu-HU
drwxr-xr-x 2 root root    1024 24. Aug 2019  it-IT
drwxr-xr-x 2 root root    1024 24. Aug 2019  ja-JP
-rwxr-xr-x 1 root root   32616 14. Sep 2022  kd_02_10df.dll
-rwxr-xr-x 1 root root  380240 14. Sep 2022  kd_02_10ec.dll
-rwxr-xr-x 1 root root   27488 14. Sep 2022  kd_02_1137.dll
-rwxr-xr-x 1 root root  240992 14. Sep 2022  kd_02_14e4.dll
-rwxr-xr-x 1 root root   45392 14. Sep 2022  kd_02_15b3.dll
-rwxr-xr-x 1 root root   45408 14. Sep 2022  kd_02_1969.dll
-rwxr-xr-x 1 root root   32600 14. Sep 2022  kd_02_19a2.dll
-rwxr-xr-x 1 root root   21344 14. Sep 2022  kd_02_1af4.dll
-rwxr-xr-x 1 root root  299360 14. Sep 2022  kd_02_8086.dll
-rwxr-xr-x 1 root root   19800 14. Sep 2022  kd_07_1415.dll
-rwxr-xr-x 1 root root   50000 14. Sep 2022  kd_0C_8086.dll
-rwxr-xr-x 1 root root   18784 14. Sep 2022  kdnet_uart16550.dll
-rwxr-xr-x 1 root root   28512 14. Sep 2022  kdstub.dll
drwxr-xr-x 2 root root    1024 24. Aug 2019  ko-KR
drwxr-xr-x 2 root root    1024 24. Aug 2019  lt-LT
drwxr-xr-x 2 root root    1024 24. Aug 2019  lv-LV
-rwxr-xr-x 1 root root 1351536 14. Sep 2022  memtest.efi
drwxr-xr-x 2 root root    1024 24. Aug 2019  nb-NO
drwxr-xr-x 2 root root    1024 24. Aug 2019  nl-NL
drwxr-xr-x 2 root root    1024 24. Aug 2019  pl-PL
drwxr-xr-x 2 root root    1024 24. Aug 2019  pt-BR
drwxr-xr-x 2 root root    1024 24. Aug 2019  pt-PT
drwxr-xr-x 2 root root    1024 24. Aug 2019  qps-ploc
drwxr-xr-x 3 root root    1024 24. Aug 2019  Resources
drwxr-xr-x 2 root root    1024 24. Aug 2019  ro-RO
drwxr-xr-x 2 root root    1024 24. Aug 2019  ru-RU
drwxr-xr-x 2 root root    1024 24. Aug 2019  sk-SK
drwxr-xr-x 2 root root    1024 24. Aug 2019  sl-SI
drwxr-xr-x 2 root root    1024 24. Aug 2019  sr-Latn-RS
drwxr-xr-x 2 root root    1024 24. Aug 2019  sv-SE
drwxr-xr-x 2 root root    1024 24. Aug 2019  tr-TR
drwxr-xr-x 2 root root    1024 24. Aug 2019  uk-UA
-rwxr-xr-x 1 root root    9796  7. Dez 2019  winsipolicy.p7b
drwxr-xr-x 2 root root    1024 24. Aug 2019  zh-CN
drwxr-xr-x 2 root root    1024 24. Aug 2019  zh-TW

.
.
.

/boot/efi/EFI/Microsoft/Boot/de-DE:
insgesamt 210
-rwxr-xr-x 1 root root 83256  7. Dez 2019  bootmgfw.efi.mui
-rwxr-xr-x 1 root root 83472  7. Dez 2019  bootmgr.efi.mui
-rwxr-xr-x 1 root root 46120  7. Dez 2019  memtest.efi.mui

.
.
.

/boot/efi/EFI/Microsoft/Boot/en-US:
insgesamt 197
-rwxr-xr-x 1 root root 77112  7. Dez 2019  bootmgfw.efi.mui
-rwxr-xr-x 1 root root 77112  7. Dez 2019  bootmgr.efi.mui
-rwxr-xr-x 1 root root 45072  7. Dez 2019  memtest.efi.mui

.
.
.

/boot/efi/EFI/Microsoft/Boot/Fonts:
insgesamt 13175
-rwxr-xr-x 1 root root 3695830 23. Mär 2021  chs_boot.ttf
-rwxr-xr-x 1 root root 3878309 23. Mär 2021  cht_boot.ttf
-rwxr-xr-x 1 root root 1985767 23. Mär 2021  jpn_boot.ttf
-rwxr-xr-x 1 root root 2372900 23. Mär 2021  kor_boot.ttf
-rwxr-xr-x 1 root root  177888 23. Mär 2021  malgun_boot.ttf
-rwxr-xr-x 1 root root  175429 23. Mär 2021  malgunn_boot.ttf
-rwxr-xr-x 1 root root  145684 23. Mär 2021  meiryo_boot.ttf
-rwxr-xr-x 1 root root  144017 23. Mär 2021  meiryon_boot.ttf
-rwxr-xr-x 1 root root  165524 23. Mär 2021  msjh_boot.ttf
-rwxr-xr-x 1 root root  163496 23. Mär 2021  msjhn_boot.ttf
-rwxr-xr-x 1 root root  157064 23. Mär 2021  msyh_boot.ttf
-rwxr-xr-x 1 root root  155438 23. Mär 2021  msyhn_boot.ttf
-rwxr-xr-x 1 root root   44760 23. Mär 2021  segmono_boot.ttf
-rwxr-xr-x 1 root root   85764 23. Mär 2021  segoen_slboot.ttf
-rwxr-xr-x 1 root root   86077 23. Mär 2021  segoe_slboot.ttf
-rwxr-xr-x 1 root root   48992 23. Mär 2021  wgl4_boot.ttf

.
.
.

/boot/efi/EFI/Microsoft/Boot/qps-ploc:
insgesamt 53
-rwxr-xr-x 1 root root 54072  7. Dez 2019  memtest.efi.mui

/boot/efi/EFI/Microsoft/Boot/Resources:
insgesamt 92
-rwxr-xr-x 1 root root 92472 23. Mär 2021  bootres.dll
drwxr-xr-x 2 root root  1024 24. Aug 2019  de-DE

/boot/efi/EFI/Microsoft/Boot/Resources/de-DE:
insgesamt 13
-rwxr-xr-x 1 root root 13112 23. Mär 2021  bootres.dll.mui

.
.
.

/boot/efi/EFI/Microsoft/Recovery:
insgesamt 52
-rwxr-xr-x 1 root root 20480  6. Apr 2021  BCD
-rwxr-xr-x 1 root root 32768 24. Aug 2019  BCD.LOG
-rwxr-xr-x 1 root root     0 24. Aug 2019  BCD.LOG1
-rwxr-xr-x 1 root root     0 24. Aug 2019  BCD.LOG2

/boot/efi/EFI/opensuse:
insgesamt 3153
-rwxr-xr-x 1 root root      58 31. Mär 17:37 boot.csv
-rwxr-xr-x 1 root root     125 31. Mär 17:37 grub.cfg
-rwxr-xr-x 1 root root 1275904 31. Mär 17:37 grub.efi
-rwxr-xr-x 1 root root  143360 31. Mär 17:37 grubx64.efi
-rwxr-xr-x 1 root root  852408 31. Mär 17:37 MokManager.efi
-rwxr-xr-x 1 root root  953800 31. Mär 17:37 shim.efi
beastxxl@linux-5099:~>
Ich habe nur die vielen verschiedenen Sprachvarianten im EFI/Microsoft/Boot-Ordner weggelassen.
 
J

josef-wien

Ultimate Guru
BeastXXL schrieb:
Naja, mit meinem naiven Halbwissen dachte ich bisher, dass ich mit
Code: 
bcdedit /set {bootmgr} path \EFI\opensuse\shim.efi
den Windows-"Bootloader" dazu verwende, um zum GRUB-Bootloader zu navigieren.
Zum Vergrößern anklicken....
Es ist eine Möglichkeit, GRUB-2 vom Windows Boot Manager zu starten, aber es ist ein Umweg und entspricht nicht einer Linux-Standardinstallation.

Dein Problem wird vom Windows Boot Manager verursacht, und ob Dir da jemand aus einem Linux-Forum helfen kann, wäre abzuwarten.

Die Alternative ist, GRUB-2 direkt aus dem UEFI heraus zu starten. Bei secure boot ist aber mehr notwendig, als mit efibootmgr eine Eintragung im UEFI-Bootmenü vorzunehmen, da auch die Signatur von shim im UEFI eingetragen sein muß. Wenn Du diesen Weg gehen willst, müssen andere Helfer eingreifen (das Verzeichnis /boot/efi/EFI/opensuse paßt aus meiner Sicht).
 
OP
B

BeastXXL

Hacker
Hallo Josef,

um das "Problem" kurzfristig zu lösen, müsste ich also Secure Boot deaktivieren und im BIOS auf openSuse wechseln. Ok, werde ich kurzfristig ausprobieren.

Dennoch würde ich gerne auch den anderen Weg erfahren. Experten in dieser Sache mögen sich bitte melden oder Links zu dementsprechenden Webseiten posten.
Danke.
 
OP
B

BeastXXL

Hacker
Hallo @susejunky,

dein Link war zwar interessant, hat mir bei der Lösung nicht weitergeholfen (oder ich habe es nicht erkannt). Trotzdem danke.

Gesetz dem Fall, dass der Windows Boot Manager wirklich das Problem ist, habe ich evtl. diese Anleitung, um genau den zu reparieren.
Vermutlich muss ich danach noch einmal
Code: 
bcdedit /set {bootmgr} path \EFI\opensuse\shim.efi
ausführen, aber ist ja kein Problem.

Sollte die shim-Datei das Problem sein, wie repariere ich die Dateien im /boot/efi/EFI/opensuse-Ordner? Nur um sicher zu gehen.
 
susejunky

susejunky

Moderator
Teammitglied
Hallo @BeastXXL ,

meines Erachtens beschreibt die openSUSE-Dokumentation genau was zu tun ist:

https://doc.opensuse.org/documentation/leap/reference/single-html/book-reference/index.html#sec-uefi-secboot schrieb:
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.

Key Exchange Keys (KEK) can be added to the UEFI key database. This way, you can use other certificates, as long as they are signed with the private part of the PK.

...

9. Use mokutil to launch the MOK list automatically.

Import the certificate to MOK:

mokutil --root-pw --import cert.der

The --root-pw option enables usage of the root user directly.

Check the list of certificates that are prepared to be enrolled:

mokutil --list-new

Reboot the system; shim should launch MokManager. You need to enter the root password to confirm the import of the certificate to the MOK list.

Check if the newly imported key was enrolled:

mokutil --list-enrolled

Alternatively, this is the procedure if you want to launch MOK manually:

Reboot

In the GRUB 2 menu press the 'c' key.

Type:

chainloader $efibootdir/MokManager.efi
boot

Select Enroll key from disk.

Navigate to the cert.der file and press Enter.

Follow the instructions to enroll the key. Normally this should be pressing '0' and then 'y' to confirm.

Alternatively, the firmware menu may provide ways to add a new key to the Signature Database.
Zum Vergrößern anklicken....

mokutil ist das Werkzeug, um den openSUSE-Schlüssel in das NVRAM Deines UEFIs einzutragen und shim ist der signierte EFI-loader.

Da ich auf allen meinen Rechnern secureboot abgeschaltet habe, kann ich Dir leider keine genaueren Befehlsabläufe liefern.

Viele Grüße

susejunky
 
OP
B

BeastXXL

Hacker
Hallo,

@susejunky: Diesen Abschnitte hatte ich überlesen, da er mit "Booting a custom kernel" überschrieben war und für mich ist/war meine openSuse-Installation nicht "custom".

Zwischenzeitlich habe ich Secure Boot deaktiviert und im BIOS auf opensuse (also grubx64.efi) umgestellt. Die Fehlermeldung ist weg und ich kann beide OS erfolgreich booten. Die Reparatur des Windows Boot Managers bin ich noch nicht angegangen.

@Sauerland: Hier die Ausgabe:
Code: 
beastxxl@linux-5099:~> su
Passwort:
linux-5099:/home/beastxxl # mokutil -l
linux-5099:/home/beastxxl # ls -al /etc/uefi/certs/
insgesamt 24
drwxr-xr-x 2 root root 4096 31. Mär 17:36 .
drwxr-xr-x 3 root root 4096 28. Mär 16:12 ..
-rw-r--r-- 1 root root 1177 14. Jun 2022  1F673297-kmp.crt
-rw-r--r-- 1 root root 1288  9. Feb 14:02 40905999.crt
-rw-r--r-- 1 root root 1288 28. Mär 16:12 76B6A6A0.crt
-rw-r--r-- 1 root root 1257 22. Mär 11:32 BCA4E38E-shim.crt
linux-5099:/home/beastxxl #
Anmerkung: mokutil -l gab wirklich nichts zurück
 
OP
B

BeastXXL

Hacker
Ah, OK, mit aktiviertem Secure Boot sieht die Sache schon anders aus:
Code: 
beastxxl@linux-5099:~> su
Passwort:
linux-5099:/home/beastxxl # mokutil -l
[key 1]
SHA1 Fingerprint: bc:a4:e3:8e:d1:84:2b:c8:6f:f7:6d:4d:a7:49:51:f1:62:88:59:f8
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=SUSE Linux Enterprise Secure Boot CA, C=DE, L=Nuremberg, O=SUSE Linux Products GmbH, OU=Build Team/emailAddress=build@suse.de
        Validity
            Not Before: Apr 18 14:33:41 2013 GMT
            Not After : Mar 14 14:33:41 2035 GMT
        Subject: CN=SUSE Linux Enterprise Secure Boot CA, C=DE, L=Nuremberg, O=SUSE Linux Products GmbH, OU=Build Team/emailAddress=build@suse.de
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:cd:fd:ab:d7:2a:84:f8:81:c3:36:35:50:35:2c:
                    c7:ec:04:f1:f4:d6:cc:60:4b:c8:13:b3:74:9b:bd:
                    f6:c4:3f:63:3e:66:51:f2:7e:3f:6e:7c:76:7b:71:
                    9d:69:21:2a:15:9b:aa:a5:e5:56:c8:79:98:12:35:
                    cd:7b:63:8c:b8:37:29:ee:77:50:bc:b7:64:8f:fe:
                    26:4a:e5:83:18:1c:6c:5d:b4:87:ef:d7:33:c4:f8:
                    1a:3f:29:9a:84:5a:01:e0:d9:81:6d:31:77:62:29:
                    f5:c1:65:14:df:4a:1d:fb:b7:4a:46:3b:f3:90:8b:
                    a2:b8:26:2a:0a:c3:9e:54:b5:03:60:81:e3:d9:58:
                    35:ed:b0:0b:e2:4f:6b:ef:69:ba:8b:47:df:a4:c5:
                    da:d0:d2:25:aa:85:63:3e:2f:05:db:4c:69:02:a6:
                    0e:35:b3:c2:ae:70:b0:ff:25:80:31:c7:0d:39:74:
                    a3:c0:a4:50:cd:9f:3f:85:b7:62:fb:7b:92:6d:c8:
                    1e:12:d2:ee:0f:96:f4:01:30:d1:ed:e2:10:ec:d2:
                    b2:b8:a1:e1:c5:2d:b3:b1:1e:f8:c5:fa:79:68:9d:
                    e5:a1:92:0f:5e:4f:45:42:7e:90:18:55:8c:fe:c2:
                    13:31:b8:21:de:ac:30:9d:99:e1:6b:44:61:0c:43:
                    3d:75
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                EC:AB:0D:42:C4:56:CF:77:04:36:B9:73:99:38:62:96:5E:87:26:2F
            X509v3 Authority Key Identifier:
                keyid:EC:AB:0D:42:C4:56:CF:77:04:36:B9:73:99:38:62:96:5E:87:26:2F
                DirName:/CN=SUSE Linux Enterprise Secure Boot CA/C=DE/L=Nuremberg/O=SUSE Linux Products GmbH/OU=Build Team/emailAddress=build@suse.de
                serial:01

            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
    Signature Algorithm: sha256WithRSAEncryption
         12:be:2c:85:85:5a:94:59:cd:49:51:08:17:c1:d9:63:27:29:
         d3:9e:9d:3f:15:03:99:24:14:9e:ed:77:41:18:f9:b2:f7:5f:
         b7:21:3a:ab:5e:0c:aa:a3:fd:b5:f0:a2:12:89:09:79:dd:09:
         70:a6:af:9c:22:21:91:02:26:b5:0f:ba:7b:c1:b8:3b:c2:c8:
         3e:4e:bb:74:cd:91:57:7a:cd:f4:c1:f6:2a:e6:98:df:59:a7:
         44:04:08:0d:09:f7:e4:07:3d:74:4d:28:cb:8d:0a:d5:c1:6e:
         4d:fb:25:09:32:8a:be:af:ce:37:4f:35:79:e8:7b:b2:e8:b0:
         4e:56:12:39:c9:3c:fb:5f:b8:b6:ad:22:58:7f:24:16:33:ca:
         1e:1c:b8:fc:62:5e:4c:ac:e0:7d:83:24:ee:9b:10:78:98:e2:
         e6:4a:ac:0a:cc:98:94:07:4a:69:18:fa:21:74:b5:12:48:42:
         83:76:8e:8a:48:7f:c6:8d:1e:cc:ee:e0:62:73:09:f3:c0:90:
         f7:49:57:d3:f6:7c:7d:1c:a1:76:9d:76:65:1e:fb:39:56:24:
         10:ae:ed:ea:3f:5b:5c:ea:2d:1e:5c:49:cf:4d:85:b6:fb:39:
         19:70:dd:1e:e6:21:f2:a3:31:19:1e:c3:b4:ae:f7:35:a7:a1:
         b4:61:6b:4e
linux-5099:/home/beastxxl #
Die andere Ausgabe hat sich nicht geändert.

Ich lese da zwei Mal "critical". Könnte das das Problem sein?
 
OP
B

BeastXXL

Hacker
Hallo,

ich habe in der letzten Zeit versucht den Bootmanager von Windows zu reparieren, weil Josef meinte, dass dieser das Problem sei.
Nach meiner oben verlinkten Anleitung habe ich es bis jetzt noch nicht geschafft ("Zugriff verweigert"; "Fehler beim Kopieren..."), aber ich habe nach allen Regeln der Kunst die Systemdateien von Windows überprüfen und reparieren lassen.

Da die merkwürdige Fehlermeldung noch immer erscheint, habe ich mal überprüft, wann das Paket "shim" installiert wurde.
Ich weiß leider nicht, wie ich auf der Konsole den Verlauf der Installationen (History) anzeigen lassen kann. Aber über die Yast-GUI konnte ich erfahren, dass die derzeitige Version 15.7 am 30.03.23 installiert wurde. Ich kann mir nur denken, dass sie per Update installiert wurde (ich kann mich nicht erinnern, shim bewusst installiert zu haben). Am selben Tag, als ich diese Thread eröffnete (31.03.23), ist mir die Fehlermeldung aufgefallen.

Code: 
beastxxl@linux-5099:~> sudo zypper se -s shim
[sudo] Passwort für root:
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
beastxxl@linux-5099:~>
Nun liegt bei mir die Vermutung nahe, dass die Version 15.4-4.7.1 vorher installiert war und keine Probleme verursachte.

Übrigens: Warum gibt es ein Paket "shim-susesigned" und wie groß ist der Unterschied zu dem "shim"-Paket (außer der Versionsnr.)?

Nun die Gretchenfrage: Downgrade von shim, ja oder nein bzw. beim "shim" oder beim "shim-susesigned"?
 
OP
B

BeastXXL

Hacker
@tomm.fa :
Klasse, danke. Zur Info hier die Log-Einträge zu shim:
Code: 
beastxxl@linux-5099:~> su
Passwort:
linux-5099:/home/beastxxl # grep shim /var/log/zypp/history
2019-09-01 14:32:48|install|shim|14-lp150.7.3|x86_64|3767:ruby.ruby2.5|openSUSE-Leap-15.0-1|33377cac9ca6770b48c6e4f4f8dbfbfe90c6348472929bacbd501ecd3f3dff69|
2019-09-07 12:00:34|install|shim|14-lp150.8.5.1|x86_64||repo-update|adb490e4af06f9c119456cc7ffe8fe1d465fb256e06f58d0cb85b813fea55bf2|
2019-09-07 13:31:50|install|shim|14-lp151.1.1|x86_64||repo-oss|e7fd1d0c30b63faf606a5ffe6ebd29af55fdcfd5affab91308f0754bb653ff14|
2020-04-06 14:14:40|install|shim|14-lp151.2.5.1|x86_64||repo-update|b7df790b691a383d71cd371f173be83abab316baa18d9ab47ffed8b4f64e52d2|
2020-08-16 14:52:35|install|shim|15+git47-lp151.2.8.1|x86_64||repo-update|f478a0fc7e901661b599f809876e86db1b66104d928ffdffb128f0748a52a87a|
2020-09-16 08:55:32|install|shim|15+git47-lp151.2.11.1|x86_64||repo-update|2a950802a630ee7fc138b1f1432e20f4a2024e3ba45e7ab5bd3dea2f170eb685|
2020-12-06 09:14:38|install|shim|15+git47-lp152.4.6.1|x86_64||repo-update|d3ba2d14590c764efb9acc5190b521eef1a9ffebaf59c43ff8a7e39bf36fb029|
2021-04-23 20:16:39|install|shim|15.4-lp152.4.8.1|x86_64||repo-update|a5311f07570ee19eddc879f692176c78861b37e7e4d302fb9237b374c15aa22d|
2021-05-11 08:10:09|install|shim|15.4-lp152.4.11.1|x86_64||repo-update|8611808d05e77e0b4e8092a84ed875b25182d36be5966e5631f1df3a5eea2b1b|
2021-05-24 21:09:22|install|shim|15.4-lp152.4.14.1|x86_64||repo-update|43a176d042bb8a48f183a45401a1fa66ed75fa7030d9312f55c41cb839cf89d0|
2021-07-20 09:51:32|install|shim|15.4-lp152.4.17.1|x86_64||repo-update|13776ed2b68698091297f5e0e7156b401b1f7a9940785a1871335266fb524a30|
2021-09-26 10:51:02|install|shim|15.4-2.1|x86_64||repo-oss|5ed00f010784c67aee7948f868e9a47682cc2e3f370b9a186152623100c97fea|
2021-09-26 11:13:58|install|shim|15.4-4.7.1|x86_64||repo-sle-update|bc896445b66cb1879c98d373630dfa1840826ca06f4c1fb1901034be2051b80b|
2023-03-30 18:29:49|install|shim|15.7-150300.4.11.1|x86_64||repo-sle-update|5cdc8679e2d0bff10d065a6a866a9ea714ef07382f1da3a80d5f42e88e60f697|
linux-5099:/home/beastxxl #
 
OP
B

BeastXXL

Hacker
Hallo @susejunky ,

ok, klingt verrückt genug, um zuzutreffen.
Wenn das stimmt, dann müsste meine installierte Version (15.7) die im Text erwähnte "Generation 2" sein und die davor (15.4) dementsprechend "Generation 1", richtig? Kann man das irgendwie überprüfen?

Wenn ich
Code: 
mokutil --set-sbat-policy previous
ausprobieren möchte, muss ich vorher noch was machen?
Im Text steht,
*before* updating to the new shim...Initial policy after reset (empty, only header)
Zum Vergrößern anklicken....
Im Manual steht:
Set the SbatPolicy UEFI Variable to have shim apply either the latest or the previous SBAT revocations. If UEFI Secure Boot is disabled, then delete will reset the SBAT revocations to an empty revocation list. While latest and previous are persistent configuration, delete will be cleared by shim on the next boot whether or not it succeeds. The default behavior is for shim to apply the previous revocations.
Zum Vergrößern anklicken....

Meine Idee war eigentlich:
SecureBoot ausschalten
Unter Linux
Code: 
mokutil --set-sbat-policy delete
ausführen
Neustart
Dann
Code: 
mokutil --set-sbat-policy previous
Neustart, dabei ScureBoot wieder einschalten und zukünftigen Boots keine Probleme mehr haben.

Allerdings...steht in dem von dir verlinkten Text:
As you see, even "previous" adds minimal grub requirement which may block grub from other distributions (all to protect you of course :) ). What is *NOT* possible is to tell shim to leave SbatLevel the hell alone on *my* system.
Zum Vergrößern anklicken....
Es scheint also, egal was ich machen würde, shim scheint sich quer zu stellen und das Problem ist wieder da.

Vermutlich muss ich einfach abwarten, bis einem Entwickler diese Problematik auffällt und behebt. Oder (ganz pragmatisch): downgrade auf 15.4 und für Updates blocken. Ist natürlich nicht die feine Art.

Oder habe ich was falsch verstanden?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben