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.
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
Created attachment 96151 [details] Attempt to calculate the actual available space rather than relying on the firmware Can you give this patch a go?
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.
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.
I see that too. suse bug reference: https://bugzilla.novell.com/show_bug.cgi?id=815170
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
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").
Same thing on Asus P8P67 Pro.
3.9.0 contains patches from the comment #7 and it did not help on Asus F2A85-M.
(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?
(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.
(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.
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.
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.