Cannot change EFI variables using efibootmgr (raring regression)

This change was made by a bot.

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

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 bugzilla.kernel.org.

[0] https://wiki.ubuntu.com/Bugs/Upstream/kernel

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: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6-quantal/
v3.7 final: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.7-raring/
v3.8-rc1: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8-rc1-raring/

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!

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 !

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.

Looks like a fix is coming soon.

http://thread.gmane.org/gmane.linux.kernel.efi/1081

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.

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:
http://people.canonical.com/~jsalisbury/lp1173423/

The kernel with commit 68d9298 reverted can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1173423/

I tested kernel from http://kernel.ubuntu.com/~jsalisbury/lp1173423/ and that fixes for me bug 1167567.

@RussianNeuroMancer, can you also test the patched kernel from:
http://people.canonical.com/~jsalisbury/lp1173423/

I've tried both. http://kernel.ubuntu.com/~jsalisbury/lp1173423/ works for me but http://people.canonical.com/~jsalisbury/lp1173423/ doesn't.

Doing an strace on efibootmgr in the current Ubuntu kernel (3.8.0.22) 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.

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

dmidecode -s bios-version
7ACN24WW

uname -r
3.8.0-19-generic

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.