Boot entries keep accumulating / ThinkPad X220 does not wake up from suspend-to-ram #52
Comments
|
Could you try to boot /EFI/BOOT/bootx64.efi and compare "efibootmgr -v" after booting? |
|
I am not sure how to boot this explicitly. In the UEFI boot screen I can select the disk to boot from. Then I see the Fedora GRUB where I can only select the kernels. I think to boot |
|
Some firmware UI provides "Boot From File". Booting from a certain disk is basically equivalent to booting /EFI/BOOT/bootx64.efi anyway. Since the only chance that shim creates the boot options is when it boots from /EFI/BOOT/bootx64.efi and chainloads /EFI/BOOT/fallback.efi, I would like to know if fallback.efi creates the boot options blindly in your case. |
|
My UI does not provide that much. This is what I have in my boot menu:
Booting the HDD (which is an SSD) will just give me the Fedora GRUB:
This BIOS Update entry is from myself. I added in in order to flash the firmware (does not work in UEFI mode) in order to get around this bug perhaps. So this entry is after the bug appeared. In the UEFI setup I found the following which I found quite interesting:
Either way, running --- boot1.txt 2016-05-01 21:39:47.337991862 +0200
+++ boot2.txt 2016-05-01 21:44:06.182270460 +0200
@@ -1,6 +1,6 @@
BootCurrent: 000A
Timeout: 0 seconds
-BootOrder: 004A,000A,0009,0006,0007,0008,000B,000C,000D,000E,000F,0010,0011,0012,0013
+BootOrder: 004C,000A,0009,0006,0007,0008,000B,000C,000D,000E,000F,0010,0011,0012,0013
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)
@@ -76,3 +76,5 @@
Boot0048* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0049* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot004A* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
+Boot004B* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
+Boot004C* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)I saw GRUB twice before taking this diff. I reset the computer with CtrlAltDel as I wanted to get back into the boot menu. Therefore I would say that it adds one boot entry per boot. I am sorry that I cannot boot from a particular file. Perhaps one could modify my GRUB such that it boots the thing you are interested in? |
|
Well, you could try doing something like: And in theory it should try to boot BOOTX64.EFI once. I think what lcp's suspicion is that either the firmware is duplicating entries on boot for no good reason, or it's /always/ booting BOOTX64.EFI erroneously, and we're also wrongly re-creating boot entries instead of using existing ones when that happens. I'm also wondering what "Boot Order Lock" actually does, and if it's interfering with or confusing our code in some way. |
|
I just ran your commands and rebooted by machine exactly once. Now I the output of --- boot10.txt 2016-05-02 17:58:14.293268556 +0200
+++ boot11.txt 2016-05-02 17:59:07.881023069 +0200
@@ -1,7 +1,6 @@
-BootNext: 0050
-BootCurrent: 000A
+BootCurrent: 0050
Timeout: 0 seconds
-BootOrder: 004B,000A,0009,0006,0007,0008,000B,000C,000D,000E,000F,0010,0011,0012,0013
+BootOrder: 004C,000A,0009,0006,0007,0008,000B,000C,000D,000E,000F,0010,0011,0012,0013
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)
@@ -78,4 +77,5 @@
Boot0049* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot004A* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot004B* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
+Boot004C* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0050* setup HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\BOOT\BOOTX64.EFI)Does that help? Is there something more that I could try out? I start to understand a bit. Before running your commands, I had The line with the boot order says So before getting to the thing that actually started the system before ( and the last item in the list. From this I would guess that it actually boots |
|
I have now checked what this “Boot order Lock is about”:
That is particularly unhelpful. I have just disabled that feature now. Perhaps it does something, I am not sure how to test this difference. Either way, after rebooting many times (I tried to figure out which keys are for Setup and Boot Menu to label print it), I obtain the following diff: --- boot11.txt 2016-05-02 17:59:07.881023069 +0200
+++ boot12.txt 2016-05-02 18:11:31.178204346 +0200
@@ -1,6 +1,6 @@
-BootCurrent: 0050
+BootCurrent: 000A
Timeout: 0 seconds
-BootOrder: 004C,000A,0009,0006,0007,0008,000B,000C,000D,000E,000F,0010,0011,0012,0013
+BootOrder: 0053,000A,0009,0006,0007,0008,000B,000C,000D,000E,000F,0010,0011,0012,0013
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)
@@ -78,4 +78,10 @@
Boot004A* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot004B* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot004C* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
+Boot004D* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
+Boot004E* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
+Boot004F* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0050* setup HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\BOOT\BOOTX64.EFI)
+Boot0051* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
+Boot0052* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
+Boot0053* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)I would now just assume that So my current model is:
|
|
I suspect the firmware ignores the efi images other than bootx64.efi so it kept going back to the HDD, i.e. 000A, but I still don't know why fallback.efi kept creating those duplicate boot options. |
|
Hmm, okay. Is there something I can do to help diagnosing this issue any further? In the meantime I will just regularly clean out the superfluous boot entries with a script, that should be fine now. |
|
I found one more piece of information that I should have provided earlier. One one reboot I saw the following:
It is hard to read, it says:
Perhaps that is related to the code |
|
Same issue with a kernel upgrade corrupting NVRAM on my Thinkpad T420 with Fedora 28. Same BootOrder error message, can't save BIOS settings (status 0x9), complete system freezes every few hours, resume from suspend no longer works. Edit: manually deleting the latest boot entry from |
|
Ever since that issue occured on my laptop, I have a little Python script running via cron which cleans up excessive boot entries in the UEFI. So far this has saved me from any further problems with that issue. |
|
Well done for your script @martin-ueding! On my side with an Ubuntu based distrib, I used a More info / details in my gist. |
I have a ThinkPad X220 Tablet which runs Fedora 23 with automatic updates,
Chromium and Spotify Copr. Up until Friday night, 2016-03-19, it worked just
fine.
Friday afternoon the new Kernel 4.4.5 was installed. It was only loaded
on Saturday when I started the machine in the afternoon. I suspended the
laptop to RAM and found that it did not woke up. I only got this strange
light show:
https://www.youtube.com/watch?v=ajoWfCtk7yE
The error (sadly) is 100% reproducible. I then went on and started with the
earlier kernels, 4.4.4 and 4.4.3, which worked fine before Friday. The error is
just the same, it does not wake up.
Then I also started a Kubuntu 15.04 from USB and had a slightly
different error. The machine would start the fan and the power light
would turn on, but the wifi was still off and the screen was black.
Using Arch Linux 2016.03.01 I was able to reproduce the error with
Kernel 4.4.1. Therefore I think it is not about the software any more.
This might be somewhere in the hardware or UEFI firmware.
On the fedora-devel mailinglist I posted the above and got some valuable
feedback. In the meantime I noticed that I could not save anything in the UEFI.
It looks like this:
I tried to do an UEFI firmware upgrade using the boot CD images that Lenovo
provides. They are 16-bit DOS and my boot sequence was locked into
UEFI only.Therefore I had to boot a Windows and do the upgrade there. This did not change
much, I did not get any error message in the UEFI/BIOS but it would just freeze
when trying to save something.
Chris Murphy from the fedora-devel list suggested to look at the output of
efibootmgr -v. Currently it looks like the following:By his suggestion, I deleted a lot of the boot entries. He said that this might
be NVRAM corruption. The first delete that I tried using
efibootmgrfailed asit complained about lack of free memory. So some hard limit has been reached
there. Deleing it via the
efivarsfile system helped, and then I could deletethe remainder with
efibootmgr.He further suggested to delete everything in
EFI/BOOT/and rundnf reinstall shim grub2-efi, which I did as well asgrub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg. After that, the checksum of/boot/efi/EFI/BOOT/BOOTX64.EFIhas not changed, though.After I deleted the boot entries, I could make changes in the UEFI/BIOS screen
again. Also the laptop consistently wakes up from the suspend again.
As a workaround, I wrote a little script that deletes the
Fedoraboot entriesonce there are over fifty.
In case it is of any interest, this is the output of
lsblk:I am not sure whether this is the right place to report this bug. Is this
something which could be fixed withing this project?
The text was updated successfully, but these errors were encountered: