http://bugzilla.opensuse.org/show_bug.cgi?id=1092000 Jiri Srain changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |glin@suse.com Assignee|jsrain@suse.com |mchang@suse.com -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1092000 http://bugzilla.opensuse.org/show_bug.cgi?id=1092000#c3 --- Comment #3 from Kukuh Syafaat --- Actually i reinstalled my ThinkPad with 42.3 so that i can work with my computer again. But before that, i tried to install with 15.0 beta and updated with the current updates and kernel, the problem was same.

Could you try to enter the firmware UI to load \EFI\opensuse\shim.efi or \EFI\opensuse\grub.efi directly?

It was the computer restarted quickly, so that i can't do anything

If you can boot into the system, please execute "efibootmgr -v" and paste the output.

efibootmgr nowadays BootCurrent: 0009 Timeout: 0 seconds BootOrder: 001A,0013,0014,000D,0000,0001,0002,0003,0007,0008,0009,000A,000B,000C Boot0000 Setup FvFile(721c8b66-426c-4e86-8e99-3457c46ab0b9) Boot0001 Boot Menu FvFile(126a762d-5758-4fca-8531-201a7f57f850) Boot0002 Diagnostic Splash Screen FvFile(a7d8d9a6-6ab0-4aeb-ad9d-163e59a7a380) Boot0003 Lenovo Diagnostics FvFile(3f7e615b-0d45-4f80-88dc-26b234958560) Boot0004 Startup Interrupt Menu FvFile(f46ee6f4-4785-43a3-923d-7f786c3c8479) Boot0005 Rescue and Recovery FvFile(665d3f60-ad3e-4cad-8e26-db46eee9f1b5) Boot0006 MEBx Hot Key FvFile(ac6fd56a-3d41-4efd-a1b9-870293811a28) Boot0007* USB CD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,86701296aa5a7848b66cd49dd3ba6a55) Boot0008* USB FDD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,6ff015a28830b543a8b8641009461e49) Boot0009* ATA HDD0 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f600) Boot000A* ATA HDD1 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f601) Boot000B* ATA HDD2 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f602) Boot000C* USB HDD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,33e821aaaf33bc4789bd419f88c50803) Boot000D* PCI LAN VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,78a84aaf2b2afc4ea79cf5cc8f3d3803) Boot000E* IDER BOOT CDROM PciRoot(0x0)/Pci(0x16,0x2)/Ata(0,1,0) Boot000F* IDER BOOT Floppy PciRoot(0x0)/Pci(0x16,0x2)/Ata(0,0,0) Boot0010* ATA HDD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f6) Boot0011* ATAPI CD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a354) Boot0012* PCI LAN VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,78a84aaf2b2afc4ea79cf5cc8f3d3803) Boot0013* Xecure HD(1,GPT,b4729dfe-7dfe-439e-867c-715f77a69a1f,0x800,0x31801)/File(\EFI\Xecure\grubx64.efi) Boot0014* Windows Boot Manager HD(1,GPT,b4729dfe-7dfe-439e-867c-715f77a69a1f,0x800,0x31801)/File(\EFI\Microsoft\Boot\bootmgfw.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.}...R................ Boot0015* opensuse-secureboot HD(1,GPT,b4729dfe-7dfe-439e-867c-715f77a69a1f,0x800,0x31801)/File(\EFI\opensuse\shim.efi) Boot0016* openSUSE-alt HD(1,GPT,b4729dfe-7dfe-439e-867c-715f77a69a1f,0x800,0x31801)/File(\EFI\opensuse\grubx64.efi) Boot0017* opensuse-secureboot HD(1,GPT,87b755f6-2333-4805-b15c-da561cc06948,0x800,0x32000)/File(\EFI\opensuse\shim.efi) Boot0018* opensuse-secureboot HD(1,GPT,9ae5bbd1-b55f-40d5-a536-d67efbd3ca14,0x800,0xfa000)/File(\EFI\opensuse\shim.efi) Boot0019* opensuse-secureboot HD(1,GPT,17230b2b-7144-484e-888d-00f397062559,0x800,0xfa000)/File(\EFI\opensuse\shim.efi) Boot001A* opensuse-secureboot HD(1,GPT,17230b2b-7144-484e-888d-00f397062559,0x800,0xfa000)/File(\EFI\opensuse\shim.efi) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1092000 http://bugzilla.opensuse.org/show_bug.cgi?id=1092000#c5 --- Comment #5 from Kukuh Syafaat --- * The opensuse-secureboot original one when error happened was Boot0015* opensuse-secureboot HD(1,GPT,b4729dfe-7dfe-439e-867c-715f77a69a1f,0x800,0x31801)/File(\EFI\opensuse\shim.efi) * Then i tried to make another boot with opensuse-alt Boot0016* openSUSE-alt HD(1,GPT,b4729dfe-7dfe-439e-867c-715f77a69a1f,0x800,0x31801)/File(\EFI\opensuse\grubx64.efi) * The rest of all below was created because i tried to reinstall tumbleweed, leap 15.0 beta and leap 42.3 with formatted whole disk and created new partition Boot0017* opensuse-secureboot HD(1,GPT,87b755f6-2333-4805-b15c-da561cc06948,0x800,0x32000)/File(\EFI\opensuse\shim.efi) Boot0018* opensuse-secureboot HD(1,GPT,9ae5bbd1-b55f-40d5-a536-d67efbd3ca14,0x800,0xfa000)/File(\EFI\opensuse\shim.efi) Boot0019* opensuse-secureboot HD(1,GPT,17230b2b-7144-484e-888d-00f397062559,0x800,0xfa000)/File(\EFI\opensuse\shim.efi) Boot001A* opensuse-secureboot HD(1,GPT,17230b2b-7144-484e-888d-00f397062559,0x800,0xfa000)/File(\EFI\opensuse\shim.efi)

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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1092000 http://bugzilla.opensuse.org/show_bug.cgi?id=1092000#c6 --- Comment #6 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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1092000 Ludwig Nussel changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P1 - Urgent Component|Bootloader |Bootloader Version|Current |Leap 15.0 Product|openSUSE Tumbleweed |openSUSE Distribution Target Milestone|--- |Leap 15.0 Flags| |SHIP_STOPPER+ -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1092000 http://bugzilla.opensuse.org/show_bug.cgi?id=1092000#c8 --- Comment #8 from Gary Ching-Pang Lin --- I'll remove the reset for TPM first. Although it breaks TPM measurement, it's better than being trapped in the infinite reset loop. Will write a proper fix later. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1092000 http://bugzilla.opensuse.org/show_bug.cgi?id=1092000#c18 Neil Rickert changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nwr10cst-oslnx@yahoo.com --- Comment #18 from Neil Rickert --- I just happened to notice this bug report. So I'll toss in a comment that might be relevant. I have a Lenovo Thinkserver. It handles boot-order in a strange way. I can set the boot order in software (with "efibootmgr"). But, after booting, the boot order reverts to what it previously was. I can also set the boot order by going into firmware settings (or BIOS settings) and changing it there. And that way of changing it works (is remembered across boots). If "fallback.efi" were to change the boot order then reset the system, the boot order would revert at the reset. There's another oddity. If I remove a boot entry with "efibootmgr -B", then that boot entry is restored on the next boot. If I really want to remove a boot entry, I can use "efibootmgr -B" to remove it, and then also delete the efi binary that it calls. In that case, the firmware does not restore the boot entry. However, if the efi binary is later put back there, then the firmware will again restore that entry -- even months after it had been removed. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1092000 http://bugzilla.opensuse.org/show_bug.cgi?id=1092000#c20 Andreas Stieger changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |astieger@suse.com --- Comment #20 from Andreas Stieger --- Maintainer, if you want this released into Leap 15.0, please review this submission: https://build.opensuse.org/request/show/613974 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1092000 http://bugzilla.opensuse.org/show_bug.cgi?id=1092000#c22 --- Comment #22 from Gary Ching-Pang Lin --- (In reply to Neil Rickert from comment #21)

Responding to comment #19

The suggested changes to "fallback.efi" look good to me.

...

It's probably restored by fallback.efi which restores the boot option according to /boot/efi/EFI/opensuse/boot.csv.

Actually, no. It is the firmware (BIOS) doing it.

Here's a recent example:

I removed the unwanted boot entries with "efibootmgr -B" and I deleted the efi binaries so that removal would stick.

After that, "efibootmgr -v" showed device entries, a "ubuntu" entry, an "opensuse-secureboot" entry, a "mageia" entry and a "solus" entry (that last put there manually).

On a recent Tumbleweed update, there was a grub2-efi update and booting was reinstalled. After that update, but before reboot, I did:

efibootmgr -v | grep opensuse

That showed only the one entry (for "opensuse-secureboot"). I then rebooted.

After boot, the same command showed an additional entry for "opensuse", apparently because the grub2-efi update had put back a file "/EFI/opensuse/grub2x64.efi". That cannot have come from "fallback" because the entry is not in "boot.csv"

Urh, right, it's clearly done by the firmware. I guess they are doing their own auto-generation stuff, but it's confusing sometimes. -- You are receiving this mail because: You are on the CC list for the bug.