Thank you, Wonko, I agree to the moving of my posts, which applies to this one too, but the objections I want to answer are still at their old places.
Windows Update adds a key entry into the UEFI BIOS DBx blacklist which prevents the shim from being loaded if secure boot is enabled. The DBx list can be easily cleared by going into the UEFI BIOS Setup menu however.
Yes. Obviously this happened during my Experiments on GPT/UEFI with grub4dos, grub2, grub4EFI
. After installation of Windows 10/11 and openSUSE Tumbleweed, with bootmgfw.efi
being chainloaded by Shim and "Grub2EFI", the command msinfo32
told me I was running "BIOS mode: UEFI" in, five lines below, "Secure Boot State: On". This changed to "Off" after installation of Windows updates (and experiments with Chenall's Universal MBR in legacy mode), but it could easily be set back to "On" when I re-established the default platform key
including the certificate for Windows 8 in the firmware setup.
IMHO Gerolf is using for his tests a very old Lenovo laptop from 2013 and wimb is using a more modern Asus MB, the very different versions in the UEFI firmware, (based on very different versions of UEFI specs available at the time when each of them were builded), could explain the difference in the findings.
SB was included in the specs in 2013 perhaps the laptop firmware made in a hurry by Lenovo is more permissive. bad implemented or the SB option in it is fake
No. Because now I get the same error
as Wimb did:
I have installed openSUSE Tumbleweed on GPT partition and can boot openSUSE Linux in UEFI Secure mode.
However, chainload of UEFI Grub4dos (Grub4EFI) fails in UEFI Secure mode with the message: bad shim signature
So indeed the secure boot chain is broken as expected already by alacran
Yes. Now, when I chainload "Grub4EFI" from "Grub2EFI" in UEFI Secure Boot mode, I get:
error: ../../grub-core/kern/efi/sb.c:150:bad shim signature
So I have to reboot, enter the firmware setup and select "Reset to Setup Mode
" in the Secure Boot options to clear the current platform key.
Then I can boot from "Grub2EFI" to "Grub4EFI" to BootMGFW, but Windows 11 (and the firmware setup main page) will say: "Secure Boot State: Off". Nevertheless, the firmware, on the Security page, says: "Secure Boot enabled", and openSUSE's YaST reports "GRUB2 for EFI" as bootloader with "Secure Boot Support".
Slowly I get a better understanding what Secure Boot means. It doesn't require me to reinstall; on my test machine, Windows 11 starts up in UEFI mode, with or without Secure Boot, as well as in BIOS mode. It doesn't require me to give up modern Linux, or legacy software down to FreeDOS. I can have it all on my machine. But at boot time, I have to be "physically present" as an advanced user who knows how to switch the firmware settings, just because hopefully no malware can do this. This little procedure is a bit uncomfortable. Most people won't like to do it, and then forget how to do it. That's all about Microsoft's nasty little trick. Nothing criminal.