[Bug 1092000] New: Tumbleweed can't boot after 20180427 update
http://bugzilla.opensuse.org/show_bug.cgi?id=1092000 Bug ID: 1092000 Summary: Tumbleweed can't boot after 20180427 update Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: jsrain@suse.com Reporter: syafaatkukuh@gmail.com QA Contact: jsrain@suse.com Found By: --- Blocker: --- Created attachment 769101 --> http://bugzilla.opensuse.org/attachment.cgi?id=769101&action=edit This message only appears about 1-2 seconds * Hardware: Lenovo ThinkPad X1 Carbon 2015 i7-5600U * OS: openSUSE Tumbleweed * Partition: * EFI (sda1) * swap (sda2, encrypted) * root (sda3, encrypted) * Secure boot off * Story: After running 20180427 update and restart the computer, it showing the message like on the attachment below for 1-2 seconds then computer restart, again and again, just like bootloop. At first, i thought it was EFI problem. After i checked http://mirrors.ustc.edu.cn/opensuse/tumbleweed/iso/Changes.20180427.txt that it was update on shim, probably this was the caused. Through chroot, i tried to reinstall shim and based on https://en.opensuse.org/openSUSE:UEFI, tried to follow "Booting the Machine that supports only one signature with vendor provided Keys" part. But the result was same. I have no idea about this error. Just backup my data and installing 42.3 for a while. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1092000 Jiri Srain <jsrain@suse.com> 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#c2 Gary Ching-Pang Lin <glin@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |syafaatkukuh@gmail.com Flags| |needinfo?(syafaatkukuh@gmai | |l.com) --- Comment #2 from Gary Ching-Pang Lin <glin@suse.com> --- It seems the firmware kept loading \EFI\boot\bootx64.efi (shim.efi) due to the missing BootOrder. Could you try to enter the firmware UI to load \EFI\opensuse\shim.efi or \EFI\opensuse\grub.efi directly? If you can boot into the system, please execute "efibootmgr -v" and paste the output. Maybe we can find some clues from that. -- 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 <syafaatkukuh@gmail.com> --- 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#c4 --- Comment #4 from Gary Ching-Pang Lin <glin@suse.com> --- BootCurrent and BootOrder look weird to me. According to BootOrder, the firmware should boot the Boot001A to load shim.efi directly. However, BootCurrent shows the system actually booted from HDD0, i.e. \EFI\boot\bootx64.efi, and it loaded fallback.efi to "restore" the boot entry. 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. Somehow the firmware skipped the entries before 0009 in BootOrder, so it kept loading bootx64.efi -> 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 http://bugzilla.opensuse.org/show_bug.cgi?id=1092000#c5 --- Comment #5 from Kukuh Syafaat <syafaatkukuh@gmail.com> --- * 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 Gary Ching-Pang Lin <glin@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|mchang@suse.com |glin@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#c6 --- Comment #6 from Gary Ching-Pang Lin <glin@suse.com> --- (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 http://bugzilla.opensuse.org/show_bug.cgi?id=1092000#c7 --- Comment #7 from Gary Ching-Pang Lin <glin@suse.com> --- BTW, there was a weird lenovo firmware bug found in 2012: https://mjg59.dreamwidth.org/20187.html The buggy firmware only accepts the boot entry with the special prefix, "Windows Boot Manager" or "Red Hat Enterprise Linux". I'm not sure if they still apply the same logic to your machine. -- 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 <lnussel@suse.com> 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 Gary Ching-Pang Lin <glin@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Tumbleweed can't boot after |System trapped in an |20180427 update |infinite reset loop after | |updating shim -- 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 <glin@suse.com> --- 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#c11 --- Comment #11 from Kukuh Syafaat <syafaatkukuh@gmail.com> ---
Looks bad
Will write a proper fix later.
Thanks Gary -- 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 <nwr10cst-oslnx@yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nwr10cst-oslnx@yahoo.com --- Comment #18 from Neil Rickert <nwr10cst-oslnx@yahoo.com> --- 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#c19 --- Comment #19 from Gary Ching-Pang Lin <glin@suse.com> --- (In reply to Neil Rickert from comment #18)
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).
It sounds like the firmware just ignores any change to BootOrder from others.
If "fallback.efi" were to change the boot order then reset the system, the boot order would revert at the reset.
I've updated the behavior of fallback.efi. Once you got the newly released shim, fallback.efi will show you a countdown menu to interrupt the system reset and offer 3 options: "System reset", "Continue boot", and "Always continue boot". The last two are basically the same except "Always continue boot" writes a NV variable, FB_NO_REBOOT, to make fallback.efi never reset. The variable will show in /sys/firmware/efi/efivars/ so the user can remove the variable to make the menu show up again.
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. It's probably restored by fallback.efi which restores the boot option according to /boot/efi/EFI/opensuse/boot.csv.
-- 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 <astieger@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |astieger@suse.com --- Comment #20 from Andreas Stieger <astieger@suse.com> --- 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#c21 --- Comment #21 from Neil Rickert <nwr10cst-oslnx@yahoo.com> --- 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" -- 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 <glin@suse.com> --- (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.
http://bugzilla.opensuse.org/show_bug.cgi?id=1092000 http://bugzilla.opensuse.org/show_bug.cgi?id=1092000#c23 Gary Ching-Pang Lin <glin@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #23 from Gary Ching-Pang Lin <glin@suse.com> --- The patch was submitted, so close this bug. Feel free to reopen it if you encounter the problem again. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com