Cannot change EFI variables using efibootmgr (raring regression)

Bug #1167622 reported by Max Bowsher
This bug affects 15 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)

Bug Description

Hardware: Asus Zenbook Prime UX21A

Runing quantal, I can set boot parameters using efibootmgr as expected.

Running raring, any attempt to write EFI vars fails.

dmesg says:
[ 248.382221] efivars: set_variable() failed: status=8000000000000009

strace of efibootmgr says:
write(3, "B\0o\0o\0t\0O\0r\0d\0e\0r\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 2084) = -1 EIO (Input/output error)

Bug 1167567 may be related but not quite the same (I see EIO, not ENOSPC)

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: linux-image-3.8.0-17-generic 3.8.0-17.27
ProcVersionSignature: Ubuntu 3.8.0-17.27-generic 3.8.6
Uname: Linux 3.8.0-17-generic x86_64
ApportVersion: 2.9.2-0ubuntu5
Architecture: amd64
 /dev/snd/controlC0: maxb 2349 F.... pulseaudio
 country GB:
  (2402 - 2482 @ 40), (N/A, 20)
  (5170 - 5250 @ 40), (N/A, 20)
  (5250 - 5330 @ 40), (N/A, 20), DFS
  (5490 - 5710 @ 40), (N/A, 27), DFS
Date: Wed Apr 10 23:59:45 2013
EcryptfsInUse: Yes
HibernationDevice: RESUME=UUID=3bb6077a-27f3-44cd-b71d-fc553dea7f84
MarkForUpload: True
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.8.0-17-generic root=UUID=8d70d748-42b7-47f3-86d2-080fa18ca3ae ro quiet splash
 linux-restricted-modules-3.8.0-17-generic N/A
 linux-backports-modules-3.8.0-17-generic N/A
 linux-firmware 1.104
SourcePackage: linux
UpgradeStatus: Upgraded to raring on 2013-03-16 (24 days ago) 09/06/2012
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: UX21A.215
dmi.board.asset.tag: ATN12345678901234567 UX21A
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: 1.0
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK COMPUTER INC.
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrUX21A.215:bd09/06/2012:svnASUSTeKCOMPUTERINC.:pnUX21A:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX21A:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0: UX21A
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK COMPUTER INC.

Revision history for this message
Max Bowsher (maxb) wrote :
Revision history for this message
Brad Figg (brad-figg) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
Max Bowsher (maxb) wrote :

The bug also occurs with upstream 3.9-rc6 from the kernel-ppa

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

This issue appears to be an upstream bug, since you tested the latest upstream kernel. Would it be possible for you to open an upstream bug report[0]? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug.

Please follow the instructions on the wiki page[0]. The first step is to email the appropriate mailing list. If no response is received, then a bug may be opened on


Changed in linux (Ubuntu):
importance: Undecided → Medium
tags: added: kernel-da-key performing-bisect
Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

I'd like to perform a bisect to figure out what commit caused this regression. It would be very helpful to know the earliest kernel where the issue started happening as well as the latest kernel that did not have this issue.

Can you test the following kernels and report back? We are looking for the first kernel version that exhibits this bug:

v3.6 final:
v3.7 final:

You don't have to test every kernel, just up until the kernel that first has this bug.

One thing to note, you will need to install both the linux-image and linux-image-extra .deb packages.

Thanks in advance!

Revision history for this message
Max Bowsher (maxb) wrote :

Hi. Sorry for taking so long to get back on this one. I failed to see the emails due to some mail rules filing things into folders too aggressively, which I've now fixed.

I've bisected, and come up with a hopefully useful result: the regression occurred between 3.8.2 and 3.8.3 !

Revision history for this message
Max Bowsher (maxb) wrote :

It would appear that 9f677cf27341b7a53915ad0e018912dc022a2a24 is almost certainly the issue (based on examining the efi commits between 3.8.2 and 3.8.3). To quote its commit message:

    efi: be more paranoid about available space when creating variables

    commit 68d929862e29a8b52a7f2f2f86a0600423b093cd upstream.

    UEFI variables are typically stored in flash. For various reasons, avaiable
    space is typically not reclaimed immediately upon the deletion of a
    variable - instead, the system will garbage collect during initialisation
    after a reboot.

    Some systems appear to handle this garbage collection extremely poorly,
    failing if more than 50% of the system flash is in use. This can result in
    the machine refusing to boot. The safest thing to do for the moment is to
    forbid writes if they'd end up using more than half of the storage space.
    We can make this more finegrained later if we come up with a method for
    identifying the broken machines.

    Signed-off-by: Matthew Garrett <email address hidden>
    Cc: Josh Boyer <email address hidden>
    Signed-off-by: Matt Fleming <email address hidden>
    Signed-off-by: Greg Kroah-Hartman <email address hidden>

Which is understandable, but SERIOUSLY vulnerable to false positives.

Revision history for this message
z (steveriley-deactivatedaccount-deactivatedaccount) wrote :
Revision history for this message
z (steveriley-deactivatedaccount-deactivatedaccount) wrote :

Can we get an update on this status? On Kubuntu Forums, we've had a number of folks running into this problem. UEFI installs are not completing or getting broken.

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

This is probably a duplicate of bug 1173423 . The expected fix for this is in commit:

commit 31ff2f20d9003e74991d135f56e503fe776c127c
Author: Matthew Garrett <email address hidden>
Date: Mon Apr 15 13:09:47 2013 -0700

efi: Distinguish between "remaining space" and actually used space

I backported this commit to Raring, but it did not seem to fix the issue in bug 1173423. I requested testing of a Raring kernel with commit 68d9298 reverted. Based on those test results, I will contact upstream to get some feedback.

Would it be possible for you to also test the two test kernels from bug 1173423?

The kernel with commit 31ff2f2 can be downloaded from:

The kernel with commit 68d9298 reverted can be downloaded from:

Revision history for this message
RussianNeuroMancer (russianneuromancer) wrote :

I tested kernel from and that fixes for me bug 1167567.

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

@RussianNeuroMancer, can you also test the patched kernel from:

Revision history for this message
David White (cppege-david-9ei9ny) wrote :

I've tried both. works for me but doesn't.

Doing an strace on efibootmgr in the current Ubuntu kernel ( it seems that the software isn't too savvy on errors. It ignores a "device full" error when trying to create an addition boot entry (caused by the notorious 50% fix) and fails later on trying to right boot order data.

Jonathan Riddell (jr)
tags: added: kubuntu
Revision history for this message
Sebastian Audet (smaudet) wrote :

I think I may have this issue as well, running Kubuntu 13.04, here's my bios id:

dmidecode -s bios-version

uname -r

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 13.04
Release: 13.04
Codename: raring

Symptoms: efibootmgr -c -l 'EFI\package\BOOT.EFI'
and variants of the above command produce the aforementioned dmesg output about errors writing to nvram.

Hope this helps.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers