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,
--
js
suse labs
Hi Jiri,
於 日，2013-04-14 於 23:25 +0200，Jiri Slaby 提到：
> 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,
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
On 16/04/13 10:56, joeyli wrote:
> 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
Please do let us know whether the patches work for you.
於 二，2013-04-16 於 11:11 +0100，Matt Fleming 提到：
> On 16/04/13 10:56, joeyli wrote:
> > 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
>
> 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
On 04/16/2013 12:11 PM, Matt Fleming wrote:
> On 16/04/13 10:56, joeyli wrote:
>> 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
>
> Please do let us know whether the patches work for you.
Hmm, where did efi_query_variable_store in 3/3 come from?
--
js
suse labs
於 三，2013-04-17 於 16:29 +0200，Jiri Slaby 提到：
> On 04/16/2013 12:11 PM, Matt Fleming wrote:
> > On 16/04/13 10:56, joeyli wrote:
> >> 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
> >
> > Please do let us know whether the patches work for you.
>
> Hmm, where did efi_query_variable_store in 3/3 come from?
>
here:
https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/commit/?h=urgent&id=a6e4d5a03e9e3587e88aba687d8f225f4f04c792
Matthew's 3 patches all merged to Matt's efi git tree.
Thanks
Joey Leeg
On 17/04/13 15:29, Jiri Slaby wrote:
> On 04/16/2013 12:11 PM, Matt Fleming wrote:
>> On 16/04/13 10:56, joeyli wrote:
>>> 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
>>
>> Please do let us know whether the patches work for you.
>
> Hmm, where did efi_query_variable_store in 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
--
Matt Fleming, Intel Open Source Technology Center
於 三，2013-04-17 於 22:50 +0800，joeyli 提到：
> 於 三，2013-04-17 於 16:29 +0200，Jiri Slaby 提到：
> > On 04/16/2013 12:11 PM, Matt Fleming wrote:
> > > On 16/04/13 10:56, joeyli wrote:
> > >> 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
> > >
> > > Please do let us know whether the patches work for you.
> >
> > Hmm, where did efi_query_variable_store in 3/3 come from?
> >
>
> here:
> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/commit/?h=urgent&id=a6e4d5a03e9e3587e88aba687d8f225f4f04c792
>
> Matthew's 3 patches all merged to Matt's efi git tree.
Forgot mention, in urgent branch
>
>
> Thanks
> Joey Leeg
>
Joey Lee
On 04/17/2013 04:51 PM, Matt Fleming wrote:
> On 17/04/13 15:29, Jiri Slaby wrote:
>> On 04/16/2013 12:11 PM, Matt Fleming wrote:
>>> On 16/04/13 10:56, joeyli wrote:
>>>> 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
>>>
>>> Please do let us know whether the patches work for you.
>>
>> Hmm, where did efi_query_variable_store in 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,
--
js
suse labs
On 04/18/2013 08:07 PM, Jiri Slaby wrote:
> On 04/17/2013 04:51 PM, Matt Fleming wrote:
>> On 17/04/13 15:29, Jiri Slaby wrote:
>>> On 04/16/2013 12:11 PM, Matt Fleming wrote:
>>>> On 16/04/13 10:56, joeyli wrote:
>>>>> 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
>>>>
>>>> Please do let us know whether the patches work for you.
>>>
>>> Hmm, where did efi_query_variable_store in 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.
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,
--
js
suse labs
On 20/04/13 08:40, Jiri Slaby wrote:
> On 04/18/2013 08:07 PM, Jiri Slaby wrote:
>> On 04/17/2013 04:51 PM, Matt Fleming wrote:
>>> On 17/04/13 15:29, Jiri Slaby wrote:
>>>> On 04/16/2013 12:11 PM, Matt Fleming wrote:
>>>>> On 16/04/13 10:56, joeyli wrote:
>>>>>> 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
>>>>>
>>>>> Please do let us know whether the patches work for you.
>>>>
>>>> Hmm, where did efi_query_variable_store in 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.
>
> 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 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?
--
Matt Fleming, Intel Open Source Technology Center
於 一，2013-04-22 於 12:07 +0100，Matt Fleming 提到：
> On 20/04/13 08:40, Jiri Slaby wrote:
> > On 04/18/2013 08:07 PM, Jiri Slaby wrote:
> >> On 04/17/2013 04:51 PM, Matt Fleming wrote:
> >>> On 17/04/13 15:29, Jiri Slaby wrote:
> >>>> On 04/16/2013 12:11 PM, Matt Fleming wrote:
> >>>>> On 16/04/13 10:56, joeyli wrote:
> >>>>>> 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
> >>>>>
> >>>>> Please do let us know whether the patches work for you.
> >>>>
> >>>> Hmm, where did efi_query_variable_store in 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.
> >
> > 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 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%
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.
> 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
On 22/04/13 12:31, joeyli wrote:
> 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.
--
Matt Fleming, Intel Open Source Technology Center
On 04/22/2013 02:20 PM, Matt Fleming wrote:
> On 22/04/13 12:31, joeyli wrote:
>> 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,
--
js
suse labs
On Mon, 2013-04-22 at 14:25 +0200, Jiri Slaby wrote:
> On 04/22/2013 02:20 PM, Matt Fleming wrote:
> > On 22/04/13 12:31, joeyli wrote:
> >> 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.
--
Matthew Garrett | [email protected]
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?