Kernel fails to update EFI vars, rendering system unbootable [P8P67 PRO REV 3.1, BIOS 1904 08/15/2011]

[Phillip Susi]

After an upgrade, my system failed to boot. Fortunately I was able to run the EFI shell and manually launch grub. From there I discovered that the EFI boot catalog contained no entry for GRUB. It appears there has been a regression in kernels later than 3.8.0-7 that causes it to fail to update the EFI variables. After running grub-install, it reports no errors, yet fails to show the efi boot catalog as it does when it works. Manually running efivars shows the ubuntu entry has been removed. Checking dmesg shows:

[ 25.965586] efivars: set_variable() failed: status=8000000000000009
[ 25.981816] efivars: set_variable() failed: status=8000000000000009

This happens on kernels 3.8.0-{15,19,23} but works correctly in -{6,7}.
---
ApportVersion: 2.9.2-0ubuntu8
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: psusi 2310 F.... pulseaudio
 /dev/snd/controlC0: psusi 2310 F.... pulseaudio
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found.
DistroRelease: Ubuntu 13.04
IwConfig:
 eth1 no wireless extensions.

 lo no wireless extensions.
MachineType: System manufacturer System Product Name
MarkForUpload: True
Package: linux (not installed)
ProcFB: 0 radeondrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.8.0-15-generic root=/dev/sda2 ro crashkernel=384M-2G:64M,2G-:128M quiet splash acpi_enforce_resources=lax vt.handoff=7
ProcVersionSignature: Ubuntu 3.8.0-15.25-generic 3.8.4
RelatedPackageVersions:
 linux-restricted-modules-3.8.0-15-generic N/A
 linux-backports-modules-3.8.0-15-generic N/A
 linux-firmware 1.106
RfKill:
 0: hci0: Bluetooth
  Soft blocked: no
  Hard blocked: no
Tags: raring
Uname: Linux 3.8.0-15-generic x86_64
UpgradeStatus: Upgraded to raring on 2013-02-13 (73 days ago)
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
WifiSyslog:

dmi.bios.date: 08/15/2011
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 1904
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: P8P67 PRO REV 3.1
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: Rev 1.xx
dmi.chassis.asset.tag: Asset-1234567890
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1904:bd08/15/2011:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKComputerINC.:rnP8P67PROREV3.1:rvrRev1.xx:cvnChassisManufacture:ct3:cvrChassisVersion:
dmi.product.name: System Product Name
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1173423

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Dave Gilbert (ubuntu-treblig)]

Phillip: Please specify full board/bios version data - this type of thing can be very dependent on exact bios screwup/version.

[Phillip Susi (psusi)]

apport information

[Phillip Susi (psusi)]

apport information

[Phillip Susi (psusi)]

apport information

[Phillip Susi (psusi)]

apport information

[Phillip Susi (psusi)]

apport information

[Phillip Susi (psusi)]

apport information

[Phillip Susi (psusi)]

apport information

[Phillip Susi (psusi)]

apport information

[Phillip Susi (psusi)]

apport information

[Phillip Susi (psusi)]

apport information

[Phillip Susi (psusi)]

apport information

[Phillip Susi (psusi)]

apport information

[Phillip Susi (psusi)]

apport information

[Phillip Susi (psusi)]

It seems this was fixed upstream by:

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

    EFI implementations distinguish between space that is actively used by a
    variable and space that merely hasn't been garbage collected yet. Space
    that hasn't yet been garbage collected isn't available for use and so isn't
    counted in the remaining_space field returned by QueryVariableInfo().

    Combined with commit 68d9298 this can cause problems. Some implementations
    don't garbage collect until the remaining space is smaller than the maximum
    variable size, and as a result check_var_size() will always fail once more
    than 50% of the variable store has been used even if most of that space is
    marked as available for garbage collection. The user is unable to create
    new variables, and deleting variables doesn't increase the remaining space.

    The problem that 68d9298 was attempting to avoid was one where certain
    platforms fail if the actively used space is greater than 50% of the
    available storage space. We should be able to calculate that by simply
    summing the size of each available variable and subtracting that from
    the total storage space. With luck this will fix the problem described in
    https://bugzilla.kernel.org/show_bug.cgi?id=55471 without permitting
    damage to occur to the machines 68d9298 was attempting to fix.

    Signed-off-by: Matthew Garrett <email address hidden>
    Signed-off-by: Matt Fleming <email address hidden>

This patch needs backported to the Ubuntu kernel.

[Joseph Salisbury (jsalisbury)]

I'll backport commit 31ff2f2, build a test kernel and post a link to it shortly.

[Joseph Salisbury (jsalisbury)]

I backported commit 31ff2f2 and built a Raring test kernel. This backport also required upstream commits: 6b59e36, 0635eb8 and cc5a080c.

The test kernel can be downloaded from:
http://people.canonical.com/~jsalisbury/lp1173423

Can you test that kernel and report back if it has the bug or not?

Thanks in advance!

[Phillip Susi (psusi)]

Unfortunately, that did not fix it.

[Joseph Salisbury (jsalisbury)]

Thanks for the update, Philip. It might be best to perform a "Reverse" bisect to identify the upstream commit that fixes this.

Can you first test the latest upstream 3.8.12 kernel[0] exhibits this bug?

If 3.8.12 still exhibits this bug, please test the 3.9 final kernel [1] to confirm it resolves this bug.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8.12-raring/
[1] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.9-saucy/

[Phillip Susi (psusi)]

Works on the v3.9 build.

[Joseph Salisbury (jsalisbury)]

Does the 3.8.12 kernel still exhibit this bug?

[Phillip Susi (psusi)]

Yes, 3.8.12 exhibits the bug. Before I found the upstream bug report, I had bisected the cause of the bug back to the commit it mentioned. Reverting that commit fixed it.

[Joseph Salisbury (jsalisbury)]

So you reverted a commit in 3.8 that fixes this bug? Can you post the SHA1 for that commit?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Phillip Susi (psusi)]

The commit titled efi: be more paranoid about available space when creating variables.

[Joseph Salisbury (jsalisbury)]

Thanks for the info.

I created a Raring test kernel with the following commit reverted:
68d9298 - efi: be more paranoid about available space when creating variables

It would be helpful if you can test this kernel to confirm it fixes this bug. That will rule out other changes that are causing this issue.

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1173423/

I'll take a closer look at my backport again to see why it may not have fixed this bug.

[Joseph Salisbury (jsalisbury)]

bug 1167622 appears to be a duplicate

[Phillip Susi (psusi)]

linux-image-3.8.0-20-generic_3.8.0-20.31~lp1173423v2Commit68d9298Reverted works.

[z (steveriley-deactivatedaccount-deactivatedaccount)]

A quick test on 3.9.3 (Saucy kernel on Raring) shows the problem hasn't been fixed there, either. When trying to add a variable, the following appears in /var/log/syslog:

efivars: set_variable() failed: status=8000000000000009

[Joseph Salisbury (jsalisbury)]

@Steve Riley, Did you test the upstream 3.9.3 kernel[0]? Comment #21 reports that this bug is fixed in 3.9. Can you confirm that, Philip?

This may be the reason why my backport of 31ff2f2 did not fix the bug.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.9.3-saucy/

[z (steveriley-deactivatedaccount-deactivatedaccount)]

Yes, my test was with that exact kernel.

Earlier today I installed 3.9.4-saucy. And the problem still exists. Here are my steps.

1. I use rEFInd, not GRUB, to boot. I made a copy of the rEFInd boot loader, just to be sure that efibootmgr isn't throwing the error in case you're trying to create a second NVRAM variable that duplicates an existing one.

cp /boot/efi/EFI/refind/refind_x64.efi /boot/efi/EFI/refind/Zrefind_x64.efi

2. Add a new NVRAM variable. On my ThinkPad T520, the EFI system partition is /dev/sda1.

efibootmgr -c -d /dev/sda -p 1 -l '\EFI\refind\Zrefind_x64.efi' -L 'Z rEFInd Boot Manager'

3. Observe the following entry while tailing /var/log/syslog:

May 31 10:18:50 t520 kernel: [ 2245.867115] efivars: set_variable() failed: status=8000000000000009

4. Double-check the NVRAM contents. As you can see, I have only the one entry for the original rEFInd boot loader. Attempting to add the "Zrefind_x64.efi" loader indeed failed.

root@t520:~# efibootmgr -v
BootCurrent: 0019
Timeout: 0 seconds
BootOrder: 0019,0006,000C,0007,000A,0008,000D,000E,000F,000B,0009,0011,0012,0010,0013
Boot0000 Setup
Boot0001 Boot Menu
Boot0002 Diagnostic Splash Screen
Boot0003 Startup Interrupt Menu
Boot0004 ME Configuration Menu
Boot0005 Rescue and Recovery
Boot0006* USB CD 030a2400d23878bc820f604d8316c068ee79d25b86701296aa5a7848b66cd49dd3ba6a55
Boot0007* USB FDD 030a2400d23878bc820f604d8316c068ee79d25b6ff015a28830b543a8b8641009461e49
Boot0008* ATAPI CD0 030a2500d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471856a35401
Boot0009 ATA HDD2 030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f602
Boot000A* ATA HDD0 030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f600
Boot000B ATA HDD1 030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f601
Boot000C* USB HDD 030a2400d23878bc820f604d8316c068ee79d25b33e821aaaf33bc4789bd419f88c50803
Boot000D* PCI LAN 030a2400d23878bc820f604d8316c068ee79d25b78a84aaf2b2afc4ea79cf5cc8f3d3803
Boot000E ATAPI CD1 030a2500d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471856a35403
Boot000F ATAPI CD2 030a2500d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471856a35404
Boot0010 Other CD 030a2500d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471856a35406
Boot0011 ATA HDD3 030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f603
Boot0012 ATA HDD4 030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f604
Boot0013 Other HDD 030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f606
Boot0014* IDER BOOT CDROM ACPI(a0341d0,0)PCI(16,2)ATAPI(0,1,0)
Boot0015* IDER BOOT Floppy ACPI(a0341d0,0)PCI(16,2)ATAPI(0,0,0)
Boot0016* ATA HDD 030a2400d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f6
Boot0017* ATAPI CD: 030a2400d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471856a354
Boot0018* PCI LAN 030a2400d23878bc820f604d8316c068ee79d25b78a84aaf2b2afc4ea79cf5cc8f3d3803
Boot0019* rEFInd Boot Manager HD(1,28,100000,35a3de7a-7015-4855-b882-1c8e9432b8fe)File(\EFI\refind\refind_x64.efi)
...

[Joseph Salisbury (jsalisbury)]

The first 3.9 build is still available at:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.9-saucy/

Would it be possible to see if the bug also exists there for you, Steve?

Thanks for all the help.

[z (steveriley-deactivatedaccount-deactivatedaccount)]

Sure, I'll try that now.

Happy to help.

[z (steveriley-deactivatedaccount-deactivatedaccount)]

Alas, 3.9.0-saucy also fails. I followed the same steps as before, and got the same error in syslog.

For completeness, I also installed the 3.8.0-20 kernel you posted that reverts commit 68d9298 (http://kernel.ubuntu.com/~jsalisbury/lp1173423/). This one works! Adding the NVRAM variable succeeded.

It appears, then, this newer commit (31ff2f2) that tries to be a bit smarter about determining free space still isn't quite smart enough ;)

[Joseph Salisbury (jsalisbury)]

Thanks for testing, Steve. I'll send a message upstream requesting feedback regarding this bug.

For completeness, would it be possible for you to test the latest mainline kernel:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10-rc3-saucy/

[z (steveriley-deactivatedaccount-deactivatedaccount)]

Apologies for the delay, work intruded ;)

Same test as before, and another failure. But the status in the error message is different:

May 31 16:40:31 t520 kernel: [ 38.749919] efivars: set_variable() failed: status=-28

Haven't seen that one before...

[Joseph Salisbury (jsalisbury)]

Message sent upstream:
http://lkml.indiana.edu/hypermail/linux/kernel/1305.3/04045.html

[Joseph Salisbury (jsalisbury)]

This bug should be fixed by the following commit:

commit f8b8404337de4e2466e2e1139ea68b1f8295974f
Author: Matthew Garrett <email address hidden>
Date: Sat Jun 1 16:06:20 2013 -0400

    Modify UEFI anti-bricking code

This commit was released in v3.10-rc7, so the latest Saucy release should be fixed. Can folks affected by this test Saucy with the latest updates to confirm.

Raring will also be receiving this fix shortly. I'll post a comment when it is in the -proposed repo.

[z (steveriley-deactivatedaccount-deactivatedaccount)]

Works here with kernel 3.10-saucy from Ubuntu mainline, installed on Raring.

BEFORE:

root@t520:~# efibootmgr
BootCurrent: 0019
Timeout: 0 seconds
BootOrder: 0019,0006,000C,0007,000A,0008,000D,000E,000F,000B,0009,0011,0012,0010,0013
Boot0000 Setup
Boot0001 Boot Menu
Boot0002 Diagnostic Splash Screen
Boot0003 Startup Interrupt Menu
Boot0004 ME Configuration Menu
Boot0005 Rescue and Recovery
Boot0006* USB CD
Boot0007* USB FDD
Boot0008* ATAPI CD0
Boot0009 ATA HDD2
Boot000A* ATA HDD0
Boot000B ATA HDD1
Boot000C* USB HDD
Boot000D* PCI LAN
Boot000E ATAPI CD1
Boot000F ATAPI CD2
Boot0010 Other CD
Boot0011 ATA HDD3
Boot0012 ATA HDD4
Boot0013 Other HDD
Boot0014* IDER BOOT CDROM
Boot0015* IDER BOOT Floppy
Boot0016* ATA HDD
Boot0017* ATAPI CD:
Boot0018* PCI LAN
Boot0019* rEFInd Boot Manager

BOOTED KERNEL:

root@t520:~# uname -a
Linux t520 3.10.0-031000-generic #201306301935 SMP Sun Jun 30 23:36:16 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

ADD NVRAM ENTRY AND PRINT:

root@t520:~# efibootmgr -c -d /dev/sda -p 1 -l '\EFI\refind\Zrefind_x64.efi' -L 'Z rEFInd Boot Manager'
BootCurrent: 0019
Timeout: 0 seconds
BootOrder: 001A,0019,0006,000C,0007,000A,0008,000D,000E,000F,000B,0009,0011,0012,0010,0013
Boot0000 Setup
Boot0001 Boot Menu
Boot0002 Diagnostic Splash Screen
Boot0003 Startup Interrupt Menu
Boot0004 ME Configuration Menu
Boot0005 Rescue and Recovery
Boot0006* USB CD
Boot0007* USB FDD
Boot0008* ATAPI CD0
Boot0009 ATA HDD2
Boot000A* ATA HDD0
Boot000B ATA HDD1
Boot000C* USB HDD
Boot000D* PCI LAN
Boot000E ATAPI CD1
Boot000F ATAPI CD2
Boot0010 Other CD
Boot0011 ATA HDD3
Boot0012 ATA HDD4
Boot0013 Other HDD
Boot0014* IDER BOOT CDROM
Boot0015* IDER BOOT Floppy
Boot0016* ATA HDD
Boot0017* ATAPI CD:
Boot0018* PCI LAN
Boot0019* rEFInd Boot Manager
Boot001A* Z rEFInd Boot Manager

Nice job. Thanks!

[max thom stahl (0ax)]

The newest saucy daily build crashes on the step "grub-installer: Running chroot /target grub-install --force" for me. Is there a way I can recover the installation from this point?

[Phillip Susi (psusi)]

That would be unrelated to this bug max. The installer should automatically file a new bug report.

[max thom stahl (0ax)]

This still doesn't work for me. After installing grub starts after a restart, but freezes on a blank console screen with "GRUB" in the upper left corner, with a flashing cursor after it.

[z (steveriley-deactivatedaccount-deactivatedaccount)]

Max, Phillip already explained that we can't help you here with your problem. This bug specifically regards a flaw in how the kernel was writing NVRAM variables for UEFI boot loaders. It is unrelated to GRUB. You will need to file a new bug for the problem you're having.

[z (steveriley-deactivatedaccount-deactivatedaccount)]

Joseph, have these patches landed in Raring yet?

[z (steveriley-deactivatedaccount-deactivatedaccount)]

My apologies... I just now noticed the "in progress" status at the top of the bug report.

[Joseph Salisbury (jsalisbury)]

The fix is in Raring as of 3.8.0-28.41 as the following commit:

commit f3e699d7a97df0aa7656196b73609744fa94d3f1
Author: Richard Weinberger <email address hidden>
Date: Wed Apr 10 10:59:34 2013 +0200

    Modify UEFI anti-bricking code

git describe --contains f3e699d
Ubuntu-3.8.0-28.41~10

It would be great if you could test -proposed and confirm this bug is resolved.

[z (steveriley-deactivatedaccount-deactivatedaccount)]

Per your request. Following same testing procedure as in my posts #32 and #40.

======================

BEFORE:

root@t520:~# efibootmgr -v
BootCurrent: 0019
Timeout: 0 seconds
BootOrder: 0019,0006,000C,0007,000A,0008,000D,000E,000F,000B,0009,0011,0012,0010,0013
Boot0000 Setup
Boot0001 Boot Menu
Boot0002 Diagnostic Splash Screen
Boot0003 Startup Interrupt Menu
Boot0004 ME Configuration Menu
Boot0005 Rescue and Recovery
Boot0006* USB CD 030a2400d23878bc820f604d8316c068ee79d25b86701296aa5a7848b66cd49dd3ba6a55
Boot0007* USB FDD 030a2400d23878bc820f604d8316c068ee79d25b6ff015a28830b543a8b8641009461e49
Boot0008* ATAPI CD0 030a2500d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471856a35401
Boot0009 ATA HDD2 030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f602
Boot000A* ATA HDD0 030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f600
Boot000B ATA HDD1 030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f601
Boot000C* USB HDD 030a2400d23878bc820f604d8316c068ee79d25b33e821aaaf33bc4789bd419f88c50803
Boot000D* PCI LAN 030a2400d23878bc820f604d8316c068ee79d25b78a84aaf2b2afc4ea79cf5cc8f3d3803
Boot000E ATAPI CD1 030a2500d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471856a35403
Boot000F ATAPI CD2 030a2500d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471856a35404
Boot0010 Other CD 030a2500d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471856a35406
Boot0011 ATA HDD3 030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f603
Boot0012 ATA HDD4 030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f604
Boot0013 Other HDD 030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f606
Boot0014* IDER BOOT CDROM ACPI(a0341d0,0)PCI(16,2)ATAPI(0,1,0)
Boot0015* IDER BOOT Floppy ACPI(a0341d0,0)PCI(16,2)ATAPI(0,0,0)
Boot0016* ATA HDD 030a2400d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f6
Boot0017* ATAPI CD: 030a2400d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471856a354
Boot0018* PCI LAN 030a2400d23878bc820f604d8316c068ee79d25b78a84aaf2b2afc4ea79cf5cc8f3d3803
Boot0019* rEFInd Boot Manager HD(1,28,100000,35a3de7a-7015-4855-b882-1c8e9432b8fe)File(\EFI\refind\refind_x64.efi)

======================

BOOTED KERNEL:

root@t520:~# uname -a
Linux t520 3.8.0-28-generic #41-Ubuntu SMP Fri Jul 26 16:26:01 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

root@t520:~# apt-cache policy linux-image-3.8.0-28-generic
linux-image-3.8.0-28-generic:
  Installed: 3.8.0-28.41
  Candidate: 3.8.0-28.41
  Version table:
 *** 3.8.0-28.41 0
        500 http://mirror.anl.gov/ubuntu/ raring-proposed/main amd64 Packages
        100 /var/lib/dpkg/status

======================

ADD NVRAM ENTRY AND PRINT:

root@t520:~# efibootmgr -c -d /dev/sda -p 1 -l '\EFI\refind\Zrefind_x64.efi' -L 'Z rEFInd Boot Manager'
BootCurrent: 0019
Timeout: 0 seconds
BootOrder: 001A,0019,0006,000C,0007,000A,0008,000D,000E,000F,000B,0009,0011,0012,0010,0013
Boot0000 Setup
Boot0001 Boot Menu
Boot0002 Diagnostic Splash Screen
Boot0003 Startup Interrupt Menu
Boot...

[Stefanauss (stefanauss)]

Installed the new kernel from -proposed, I finally managed to alter EFI vars. I tried bootorder, bootnext, disabling entry. It works!

[Numérigraphe (numerigraphe)]

Hi, I seem to have hit this same bug with linux-image-generic-lts-raring 3.8.0-30.44~precise1 in Precise.
Was this fix applied in the 3.8 kernel in the Raring stack in 12.04.3LTS ?

[Joseph Salisbury (jsalisbury)]

Yes, this bug should be fixed by the following commit in Raring:

f3e699d - Modify UEFI anti-bricking code

[Sebastian Audet (smaudet)]

Repost, didn't see the duplicate status on:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1167622

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.

Is this fix supposed to be live or not?