Bug 55471
Summary: | efivars.c: fail for write boot entry | ||
---|---|---|---|
Product: | Platform Specific/Hardware | Reporter: | Mike (icerider) |
Component: | x86-64 | Assignee: | platform_x86_64 (platform_x86_64) |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | alan, jirislaby, joseph.salisbury, mike, o.shirochenkov, petr.pisar, phill, spiderx, the.ridikulus.rat |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 3.8.3,3.8.4 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Attachments: | Attempt to calculate the actual available space rather than relying on the firmware |
Description
Mike
2013-03-20 06:51:01 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 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. |