Cannot add new efi boot entry
Hi,
after update to 3.8, every update of the kernel ends up in an unbootable machine. It is due to the following commit:
commit 68d929862e29a8b52a7f2f2f86a0600423b093cd
Author: Matthew Garrett <[email protected]> Date: Sat Mar 2 19:40:17 2013 -0500
efi: be more paranoid about available space when creating variables
efibootmgr which tries to add an entry and silently fails when writing to /sys/firmware/efi/vars/new_var with -ENOSPC.
There are many entries in there:
# efibootmgr BootCurrent: 000D Timeout: 0 seconds BootOrder: 0018,0000,0001,0002,0003,0007,0008,0009,000A,000B,000C,000D,000E,000F,0010,0011,0012 Boot0000 Setup Boot0001 Boot Menu Boot0002 Diagnostic Splash Screen Boot0003 Lenovo Diagnostics Boot0004 Startup Interrupt Menu Boot0005 ME Configuration Menu Boot0006 Rescue and Recovery Boot0007* USB CD Boot0008* USB FDD Boot0009* ATAPI CD0 Boot000A* ATA HDD0 Boot000B* ATA HDD1 Boot000C* ATA HDD2 Boot000D* USB HDD Boot000E* PCI LAN Boot000F* ATAPI CD1 Boot0010 Other CD Boot0011* ATA HDD3 Boot0012 Other HDD Boot0013* IDER BOOT CDROM Boot0014* IDER BOOT Floppy Boot0015* ATA HDD Boot0016* ATAPI CD: Boot0017* PCI LAN Boot0018* Linux
Remaining size is about 20k, added entry size is hundreds bytes, store size is 64k.
Obviously lowering the limitation from 1/2 to 1/4 fixes the problem for me because it always worked on my setup to store a new entry...
Any ideas how to overcome that? It would be better to blacklist bad machines rather than whitelist good ones, right?
thanks,
Signature · 2 lines
js suse labs
Hi Jiri,
於 日，2013-04-14 於 23:25 +0200，Jiri Slaby 提到：
Quoted 49 lines
Hi,
after update to 3.8, every update of the kernel ends up in an unbootable machine. It is due to the following commit:
commit68d929862e29a8b52a7f2f2f86a0600423b093cdAuthor: Matthew Garrett <matthew.garrett-05XSO3Yj/[email protected]> Date: Sat Mar 2 19:40:17 2013 -0500efi: be more paranoid about available space when creating variables
efibootmgr which tries to add an entry and silently fails when writing to
/sys/firmware/efi/vars/new_varwith-ENOSPC.There are many entries in there:
# efibootmgr BootCurrent: 000D Timeout: 0 seconds BootOrder: 0018,0000,0001,0002,0003,0007,0008,0009,000A,000B,000C,000D,000E,000F,0010,0011,0012 Boot0000 Setup Boot0001 Boot Menu Boot0002 Diagnostic Splash Screen Boot0003 Lenovo Diagnostics Boot0004 Startup Interrupt Menu Boot0005 ME Configuration Menu Boot0006 Rescue and Recovery Boot0007* USB CD Boot0008* USB FDD Boot0009* ATAPI CD0 Boot000A* ATA HDD0 Boot000B* ATA HDD1 Boot000C* ATA HDD2 Boot000D* USB HDD Boot000E* PCI LAN Boot000F* ATAPI CD1 Boot0010 Other CD Boot0011* ATA HDD3 Boot0012 Other HDD Boot0013* IDER BOOT CDROM Boot0014* IDER BOOT Floppy Boot0015* ATA HDD Boot0016* ATAPI CD: Boot0017* PCI LAN Boot0018* LinuxRemaining size is about 20k, added entry size is hundreds bytes, store size is 64k.
Quoted 7 lines
Obviously lowering the limitation from 1/2 to 1/4 fixes the problem for me because it always worked on my setup to store a new entry...
Any ideas how to overcome that? It would be better to blacklist bad machines rather than whitelist good ones, right?
thanks,
I think I just got the same situation on my side with Acer machine. I am trying Matthew's new patchset hope can avoid this situation:
https://lkml.org/lkml/2013/4/15/473
Thanks a lot!
Joey Lee
Quoted 4 lines · joeyli
I think I just got the same situation on my side with Acer machine. I am trying Matthew's new patchset hope can avoid this situation:
Please do let us know whether the patches work for you.
於 二，2013-04-16 於 11:11 +0100，Matt Fleming 提到：
Quoted 9 lines · joeyli
Quoted 4 lines
I think I just got the same situation on my side with Acer machine. I am trying Matthew's new patchset hope can avoid this situation:
Please do let us know whether the patches work for you.
I applied Matthew's patches to v3.9-rc7 then tested...
The active_size checking works to me on my Acer machine for avoid the storage_size/2 issue, I can use efibootmgr to create new boot entry, now.
But, I found there have the following warning:
[ 1.347581] [Firmware Bug]: efi: Inconsistent initial size
Then, I add printk to print the values of var_size and active_size, found the values always 0 after system reboot. I am doing to add more log for locate if this is a BIOS issue.
Thanks a lot!
Joey Lee
Quoted 7 lines · Matt Fleming
Quoted 4 lines · joeyli
I think I just got the same situation on my side with Acer machine. I am trying Matthew's new patchset hope can avoid this situation:
Please do let us know whether the patches work for you.
Hmm, where did efi_query_variable_store in 3/3 come from?
Signature · 2 lines
js suse labs
於 三，2013-04-17 於 16:29 +0200，Jiri Slaby 提到：
Quoted 11 lines · Matt Fleming
Quoted 7 lines · joeyli
Quoted 4 lines
I think I just got the same situation on my side with Acer machine. I am trying Matthew's new patchset hope can avoid this situation:
Please do let us know whether the patches work for you.
Hmm, where did
efi_query_variable_storein 3/3 come from?
Matthew's 3 patches all merged to Matt's efi git tree.
Thanks
Joey Leeg
於 三，2013-04-17 於 22:50 +0800，joeyli 提到：
Quoted 10 lines
於 三，2013-04-17 於 16:29 +0200，Jiri Slaby 提到：
Quoted 9 lines · Matt Fleming
Quoted 7 lines · joeyli
Quoted 4 lines
I think I just got the same situation on my side with Acer machine. I am trying Matthew's new patchset hope can avoid this situation:
Please do let us know whether the patches work for you.
Quoted 7 lines
Quoted 2 lines
Hmm, where did
efi_query_variable_storein 3/3 come from?Matthew's 3 patches all merged to Matt's efi git tree.
Forgot mention, in urgent branch
Quoted 5 lines
Thanks
Joey Leeg
Joey Lee
Quoted 10 lines · Jiri Slaby
Quoted 7 lines · Matt Fleming
Quoted 4 lines · joeyli
I think I just got the same situation on my side with Acer machine. I am trying Matthew's new patchset hope can avoid this situation:
Please do let us know whether the patches work for you.
Hmm, where did
efi_query_variable_storein 3/3 come from?
It's in a patch on the 'urgent' branch at,
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git
Signature · 1 line
Matt Fleming, Intel Open Source Technology Center
Quoted 8 lines · Matt Fleming
Quoted 7 lines · Jiri Slaby
Quoted 6 lines · Matt Fleming
Quoted 4 lines · joeyli
I think I just got the same situation on my side with Acer machine. I am trying Matthew's new patchset hope can avoid this situation:
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
Please do let us know whether the patches work for you.
Hmm, where did
efi_query_variable_storein 3/3 come from?It's in a patch on the 'urgent' branch at,
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git
The 3 patches plus that one work for me.
thanks,
Signature · 2 lines
js suse labs
Quoted 11 lines · Jiri Slaby
Quoted 10 lines · Matt Fleming
Quoted 9 lines · Jiri Slaby
Quoted 7 lines · Matt Fleming
Quoted 4 lines · joeyli
I think I just got the same situation on my side with Acer machine. I am trying Matthew's new patchset hope can avoid this situation:
Please do let us know whether the patches work for you.
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
Hmm, where did
efi_query_variable_storein 3/3 come from?It's in a patch on the 'urgent' branch at,
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.gitThe 3 patches plus that one work for me.
Actually they don't :(:open("/sys/firmware/efi/vars/new_var", O_WRONLY) = 3 write(3, "B\0o\0o\0t\0000\0000\0001\0003\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 2084) = -1 ENOSPC (No space left on device)
close(3) = 0
thanks,
Signature · 2 lines
js suse labs
Quoted 18 lines · Jiri Slaby
Quoted 17 lines · Jiri Slaby
Quoted 15 lines · Matt Fleming
Quoted 10 lines · Jiri Slaby
Quoted 7 lines · Matt Fleming
Quoted 4 lines · joeyli
I think I just got the same situation on my side with Acer machine. I am trying Matthew's new patchset hope can avoid this situation:
Please do let us know whether the patches work for you.
Hmm, where did
efi_query_variable_storein 3/3 come from?It's in a patch on the 'urgent' branch at,
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git
Quoted 8 lines
Quoted 1 line
The 3 patches plus that one work for me.
Actually they don't :(:
open("/sys/firmware/efi/vars/new_var", O_WRONLY)= 3write(3, "B\0o\0o\0t\0000\0000\0001\0003\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 2084)= -1 ENOSPC (No space left on device)
close(3) = 0
Thanks for testing Jiri.
You can disable the EFI storage checks in -rc8 by using the efi_no_storage_paranoia kernel parameter, but it's only recommended to do that if you machine ends up in these kinds of situations where garbage collection isn't be initiated, or your machine ships with > 50% of the variable store in use from the factory.
Matthew, what kind of info do you need from Jiri to improve the storage limit algorithm?
Signature · 1 line
Matt Fleming, Intel Open Source Technology Center
於 一，2013-04-22 於 12:07 +0100，Matt Fleming 提到：
Quoted 28 lines · Jiri Slaby
Quoted 18 lines · Jiri Slaby
Quoted 17 lines · Matt Fleming
Quoted 15 lines · Jiri Slaby
Quoted 10 lines · Matt Fleming
Quoted 7 lines · joeyli
Quoted 4 lines
I think I just got the same situation on my side with Acer machine. I am trying Matthew's new patchset hope can avoid this situation:
Please do let us know whether the patches work for you.
Hmm, where did
efi_query_variable_storein 3/3 come from?It's in a patch on the 'urgent' branch at,
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.gitQuoted 8 lines
Quoted 1 line
The 3 patches plus that one work for me.
Actually they don't :(:
open("/sys/firmware/efi/vars/new_var", O_WRONLY)= 3write(3, "B\0o\0o\0t\0000\0000\0001\0003\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 2084)= -1 ENOSPC (No space left on device)
close(3) = 0
Quoted 6 lines
Thanks for testing Jiri.
You can disable the EFI storage checks in -rc8 by using the
efi_no_storage_paranoiakernel parameter, but it's only recommended to do that if you machine ends up in these kinds of situations where garbage collection isn't be initiated, or your machine ships with > 50%
Does garbage collection only trigger by UEFI BIOS when system reboot? or garbage collection also triggered at run time?
There have a problem is if we delete boot entry when the flash space tight(maybe 99%, just remaining_size < max_size), then we can not create new boot entry unless we reboot system for trigger garbage collection. But we already lost available boot entry.
Quoted 5 lines
of the variable store in use from the factory.
Matthew, what kind of info do you need from Jiri to improve the storage limit algorithm?
Thanks a lot!
Joey Lee
Quoted 2 lines · joeyli
Does garbage collection only trigger by UEFI BIOS when system reboot? or garbage collection also triggered at run time?
That is implementation specific. AFAIK, there are implementations for both schemes.
Signature · 1 line
Matt Fleming, Intel Open Source Technology Center
Quoted 6 lines · Matt Fleming
Quoted 2 lines · joeyli
Does garbage collection only trigger by UEFI BIOS when system reboot? or garbage collection also triggered at run time?
That is implementation specific. AFAIK, there are implementations for both schemes.
Just a point from the abstract level. Is there a way to find out? And what do Windows do?
thanks,
Signature · 2 lines
js suse labs
Quoted 10 lines · Jiri Slaby
Quoted 6 lines · Matt Fleming
Quoted 2 lines · joeyli
Does garbage collection only trigger by UEFI BIOS when system reboot? or garbage collection also triggered at run time?
That is implementation specific. AFAIK, there are implementations for both schemes.
Just a point from the abstract level. Is there a way to find out? And what do Windows do?
Windows kills Samsungs.
Signature · 1 line
Matthew Garrett | [email protected]