Bug 55471 - efivars.c: fail for write boot entry
Summary: efivars.c: fail for write boot entry
Status: CLOSED CODE_FIX
Alias: None
Product: Platform Specific/Hardware
Classification: Unclassified
Component: x86-64 (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: platform_x86_64@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-20 06:51 UTC by Mike
Modified: 2013-11-13 21:33 UTC (History)
9 users (show)

See Also:
Kernel Version: 3.8.3,3.8.4
Tree: Mainline
Regression: Yes


Attachments
Attempt to calculate the actual available space rather than relying on the firmware (2.73 KB, patch)
2013-03-25 17:52 UTC, Matthew Garrett
Details | Diff

Description Mike 2013-03-20 06:51:01 UTC
I have motherboard ASUS F1A75-V PRO. After update kernel to 3.8.3 i cannot add UEFI boot entry. dmesg display.

efivars: set_variable() failed: status=8000000000000009

By commit "68d929862e29a8b52a7f2f2f86a0600423b093cd efi: be more paranoid about available space when creating variables" was added code

if (!storage_size || size > remaining_size || size > max_size ||
       (remaining_size - size) < (storage_size / 2))
            return EFI_OUT_OF_RESOURCES;

Function "query_variable_info" sets "max_size" as zero.
storage_size is 65536.
remaining_size is 47066.

In kernel 3.8.2 UEFI boot entry added correctly.
Comment 1 Oleg Shirochenkov 2013-03-25 12:39:56 UTC
Same issue has been reported in Gentoo Bug 462705 – sys-boot/efibootmgr with kernel >3.8.2 - `efibootmgr -o x,y,z' does not set boot order - https://bugs.gentoo.org/show_bug.cgi?id=462705
Comment 2 Matthew Garrett 2013-03-25 17:52:17 UTC
Created attachment 96151 [details]
Attempt to calculate the actual available space rather than relying on the firmware

Can you give this patch a go?
Comment 3 Oleg Shirochenkov 2013-03-25 19:19:31 UTC
Dear Matthew, thank you.
Please, treat this as UAT sign-off.
With your patch I'm able to boot 3.8.4 and make write actions to EFI variables.
Requesting to include it in 3.8.5.
Comment 4 Mike 2013-03-26 08:01:18 UTC
The patch has not helped. Variable "max_size" is zero.

Condition "size > max_size" provides EFI_OUT_OF_RESOURCES. 

efibootmgr -c

dmesg output:

[  169.877879] efivars: maxsize=0
[  169.877885] efivars: active_available=58354
[  169.877888] efivars: size=112
[  169.877890] efivars: storeage_size=65536
[  170.210621] efivars: maxsize=0
[  170.210622] efivars: active_available=58354
[  170.210623] efivars: size=26
[  170.210624] efivars: storeage_size=65536
[  170.210647] efivars: set_variable() failed: status=8000000000000009

As I understand 'max_size=0' returned by the humpbacked asus firmware, because Asrock motherboard FM2A75M has max_size above zero.
Comment 5 Jiri Slaby 2013-04-15 06:57:12 UTC
I see that too. suse bug reference:
https://bugzilla.novell.com/show_bug.cgi?id=815170
Comment 6 Michael Shigorin 2013-04-16 12:45:56 UTC
I second that; the funny thing is that we only got down to bisecting yesterday
and came to the same conclusion (thanks raorn@ for this fix hint).

Links to the yesterday's patchset by mjg@:
http://lkml.org/lkml/2013/4/15/307
http://lkml.org/lkml/2013/4/15/306

ALT Linux bug reference (in Russian; "3.8.2->3.8.3 broke efibootmgr"):
https://bugzilla.altlinux.org/show_bug.cgi?id=28827
Comment 7 Michael Shigorin 2013-04-16 13:25:01 UTC
Ahem, there was V6 posted a bit later yesterday, overlooked that:
http://lkml.org/lkml/2013/4/15/471
http://lkml.org/lkml/2013/4/15/472
http://lkml.org/lkml/2013/4/15/476

PS: vsu@ suggested CONFIG_EFI_VARS=y as module is reportedly broken
("efivars: firmware bug workarounds should be in platform code").
Comment 8 Phillip Susi 2013-04-28 20:08:32 UTC
Same thing on Asus P8P67 Pro.
Comment 9 Petr Pisar 2013-05-08 08:28:44 UTC
3.9.0 contains patches from the comment #7 and it did not help on Asus F2A85-M.
Comment 10 Jiri Slaby 2013-05-08 08:46:28 UTC
(In reply to comment #9)
> 3.9.0 contains patches from the comment #7 and it did not help on Asus
> F2A85-M.

For me too, but efi_no_storage_paranoia=1 does, right?
Comment 11 Petr Pisar 2013-05-08 10:37:30 UTC
(In reply to comment #10)
> For me too, but efi_no_storage_paranoia=1 does, right?

I don't know because I've upgraded firmware from revision 
5202 to 6004 which probably garbage-collected the variables and then I cannot reproduce it without the efi_no_storage_paranoia.
Comment 12 Petr Pisar 2013-05-15 17:59:18 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > 3.9.0 contains patches from the comment #7 and it did not help on Asus
> F2A85-M.
> 
> For me too, but efi_no_storage_paranoia=1 does, right?

Yes. I run into the problem again, and efi_no_storage_paranoia=1 enables to add a variable.
Comment 13 Joseph Salisbury 2013-07-18 15:25:11 UTC
This bug should be fixed by the following commit:

commit f8b8404337de4e2466e2e1139ea68b1f8295974f
Author: Matthew Garrett <matthew.garrett@nebula.com>
Date: Sat Jun 1 16:06:20 2013 -0400

    Modify UEFI anti-bricking code

This commit was released in v3.10-rc7 and has been sent for inclusion in the stable tree.
Comment 14 Petr Pisar 2013-07-28 19:30:02 UTC
Thank you. I can confirm I was able to edit boot variables with my AMI/Asus firmware three times without any hickup without the efi_no_storage_paranoia=1 argument since 3.10.0.

Note You need to log in before you can comment on or make changes to this bug.