Comment # 6 on bug 1092000 from Gary Ching-Pang Lin

(In reply to Kukuh Syafaat from comment #5)
> 
> > For shim 0.9, fallback.efi will try to load the "restored" boot entry first. But shim 14 changes the behavior and resets the system directly. It should be fine since the boot entry is created, and the firmware should follow it to load shim.efi.
> 
> I believe it's a shim problem with spesific hardware, for this case,
> ThinkPad X1 carbon 2015. But i can't reproduce this error again because i
> still use my computer for dailiy use.

Actually, fallback.efi will still boot the "restored" boot entry IF there is no
tpm protocol. The reason is to make the result of tpm measurement consistent.
For a properly implemented UEFI firmware, it should always follow the
BootOrder.

--
Could you help me to check the firmware further? I would need you to get into
the firmware UI and do some operations.

If you have the problem to get into the firmware UI, this command should make
the system show the firmware UI during the next boot:

echo -ne "\x07\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00" >
OsIndications-8be4df61-93ca-11d2-aa0d-00e098032b8c

Once you get into the firmware UI, please try to find the option like "Boot
from file" and see if the firmware can boot \EFI\opensuse\shim.efi

If it can, then check the UI and see if there is any option to create a new
boot entry from the UI and try to create a boot entry for
\EFI\opensuse\shim.efi. After booting into OS, type "efibootmgr -v" and paste
the output. I would like to know what kind of boot entry is acceptable to the
firmware.

--
If the firmware is so stubborn and only boots \EFI\boot\bootx64.efi, the last
resort would be to copy the files in \EFI\opensuse to \EFI\boot and remove
fallback.efi.