[Bug 1185232] something has gone seriously wrong: shim_init() - system does not boot anymore after installing today's updates
https://bugzilla.suse.com/show_bug.cgi?id=1185232
https://bugzilla.suse.com/show_bug.cgi?id=1185232#c54
--- Comment #54 from Gary Ching-Pang Lin
(In reply to Gary Ching-Pang Lin from comment #51)
Could you try this to dump Boot2* and Boot3*?
# for opt in /sys/firmware/efi/efivars/Boot[23]*; do echo $opt; hexdump -C $opt; done
Boot0000 is created by openSUSE. I'm interesting in the boot options created by the firmware. Maybe they contain some OptionalData that shim 15.4 doesn't like.
linux:~ # ls-l /sys/firmware/efi/efivars/Boot* -rw-r--r-- 1 root root 146 Jun 1 10:36 /sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
--->8---
linux:~ # for opt in /sys/firmware/efi/efivars/Boot[23]*; do echo $opt; hexdump -C $opt; done /sys/firmware/efi/efivars/Boot2001-8be4df61-93ca-11d2-aa0d-00e098032b8c 00000000 07 00 00 00 01 00 00 00 04 00 45 00 46 00 49 00 |..........E.F.I.| 00000010 20 00 55 00 53 00 42 00 20 00 44 00 65 00 76 00 | .U.S.B. .D.e.v.| 00000020 69 00 63 00 65 00 00 00 7f ff 04 00 52 43 |i.c.e.......RC| 0000002e
The boot option looks a bit odd since the device path only contains the EndNode (7f ff 04 00), but it seems that shim could handle this case. I need to investigate this further. (In reply to Ren� Neumaier from comment #53)
Created attachment 849874 [details] Verification failed - 0x1A - security violation
Thanks for your patience.
(In reply to Gary Ching-Pang Lin from comment #48)
Could you try comment#27 and see if you can reproduce this bug? It'd be helpful to have a reliable system to reproduce the bug and verify the possible fix.
I followed your tutorial from comment#27. But I felt a bit lost with point 4 (reproduce error / collecting of information). Which information or logfile would be helpful? I was able to boot the "debug shim" but I got the following error: Verification failed: (0x1A) Security Violation After pressing 'enter' I got the messages from the attached screenshot. As I chooses continue, the system seems to boot with the "debug shim".
Did you copy grub.efi to the debug folder? I expected shim failed early as comment#0 so the steps doesn't copy grub.efi to the debug folder. If you did, it's understandable because Leap 15.3 uses grub.efi from SLE15-SP3 directly, so shim-opensuse.efi couldn't verify it with the built-in openSUSE CA. Anyway it seems your case is different from comment#0.
After setup and before reboot: localhost:/boot/efi/EFI/debug # efibootmgr BootNext: 0001 BootCurrent: 0000 Timeout: 0 seconds BootOrder: 0000,2001,2002,2003,3007,300E,300F,3010,3012 Boot0000* opensuse-secureboot Boot0001* shim debug Boot2001* EFI USB Device Boot2002* EFI DVD/CDROM Boot2003* EFI Network Boot3007* Drive0 NVMe: Boot300E* NETWORK: Boot300F* USB HDD: Boot3010* USB CD/DVD: Boot3012* Thunderbolt HDD:
With "debug shim": localhost:/var/log # efibootmgr BootCurrent: 0001 Timeout: 0 seconds BootOrder: 0000,2001,2002,2003,3007,300E,300F,3010,3012 Boot0000* opensuse-secureboot Boot0001* shim debug Boot2001* EFI USB Device Boot2002* EFI DVD/CDROM Boot2003* EFI Network Boot3007* Drive0 NVMe: Boot300E* NETWORK: Boot300F* USB HDD: Boot3010* USB CD/DVD: Boot3012* Thunderbolt HDD:
I felt I have a quite knowledge gap here (I am a bit unfamiliar with secureboot). But the message "MokManager.efi - Not Found" made me skeptical and led to the following command:
localhost:/var/log # mokutil --sb-state SecureBoot disabled Platform is in Setup Mode
No difference rather I boot with Boot0000 - opensuse-secureboot (as regular) or with Boot0001 - shim debug. That means SecureBoot doesn't work regardless of my BIOS setting? Because in the BIOS/UEFI system it is truly activated.
Actually I'm surprised that the debug shim showed "Verification failed" since it only happened when Secure Boot is on. However, the debug shim.efi is not signed by UEFI CA, the firmware is supposed to reject it when Secure Boot is on. What's more interesting is that mokutil found your system in Setup Mode which means no key enrolled for Secure Boot in the firmware, and this basically means Secure Boot is off. You can check the system status with the following commands: # hexdump -C /sys/firmware/efi/efivars/SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c # hexdump -C /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c For a Secure Boot enabled UEFI firmware, SetupMode should be "06 00 00 00 00" and SecureBoot should be "06 00 00 00 01". -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@suse.com