efibootmgr may create a duplicated boot entry, "breaking" UEFI boot.

Bug #1363719 reported by Krzysztof Klimonda
72
This bug affects 20 people
Affects Status Importance Assigned to Milestone
One Hundred Papercuts
Fix Released
Critical
Unassigned
efibootmgr (Ubuntu)
Fix Released
Critical
Unassigned
Utopic
Fix Released
Critical
Mathieu Trudel-Lapierre
grub2 (Ubuntu)
Utopic
Invalid
Undecided
Unassigned

Bug Description

[Impact]
This bug causes any users with preexisting boot entries in UEFI in a specific pattern to get duplicated entries with a same number, which causes most UEFI BIOSes to reset to default values, thus making Ubuntu unbootable (requires intervention via a different bootable device).
The included patch changes the variable sizes for compared data to a more suitable type, since it otherwise caused undersired behavior when doing comparisons.

[Test Case]
Using an affected system:
1) Try to create a new bootmgr entry: 'efibootmgr -c'
Without the patch, the creation step will add a duplicate entry with the same BootNNNN number.
With the patch, the creation should succeed and create a new entry with a new BootNNNN number.

[Regression Potential]
Possible regressions may be inability to create new boot entries in the boot manager (though unlikely), or setting the wrong boot order, or other issues related to the addition of boot entries in UEFI.

---
Hey,
  the current version of efibootmgr has a small ordering bug that causes, at least on x240, a duplicated boot entry to be added to UEFI, breaking the boot - UEFI resets everything to default values, and you have to boot from usb stick to fix uefi entries. There is an upstream patch that fixes it, and it would be great if we could add it.

Upstream bug report is https://github.com/vathpela/efibootmgr/issues/7

description: updated
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in efibootmgr (Ubuntu):
status: New → Confirmed
tags: added: utopic
Revision history for this message
Patrik Lundquist (patrik-lundquist) wrote :

I consider the bug a show stopper since Ubuntu doesn't have a \EFI\BOOT\BOOTX64.EFI fallback like Fedora.

Revision history for this message
Lukas (bobukas) wrote :

Hi,
Just got bitten by the same bug after upgrading to ubuntu 14.10 (on a lenovo thinkpad x240). My laptop refused to boot after the upgrade to utopic and I suspected an issue with the uefi grub2 installation. Bootrepair does not detect this issue and since it uses efibootmgr it can not fix it.
I ended up using refind [1] to boot my system and eventually found then the above mentioned issue. I fixed my installation by downloading and compiling efibootmgr from the source repo. Hope this helps anyone with the same error.

Please backport the fix mentioned in the bugreport asap. Even for an experienced user, this bug is very hard to track down since the system does not boot at all and there is hardly an error message.

[1] http://www.rodsbooks.com/refind/

Revision history for this message
Joris Claassen (jorisc90) wrote :

I ran into the same bug on my Thinkpad 440s. Installing http://packages.ubuntu.com/nl/trusty/efibootmgr 0.5.4 from trusty in the live CD environment and adding the boot entry using

efibootmgr -c -d /dev/sda -p 1 -l '\EFI\ubuntu\shimx64.efi' -L 'ubuntu'

Works. :-) Hope this helps!

Revision history for this message
Dominik Gierlach (dominik-gierlach) wrote :

I also ran into the issue, t440s as well.
I second Patrik, this is pretty much a showstopper.
Please integrate the upstream bugfix..

Revision history for this message
Patrik Lundquist (patrik-lundquist) wrote :
Revision history for this message
Patrik Lundquist (patrik-lundquist) wrote :

BTW, an alternative to rEFInd and Live CD is booting an Ubuntu Server ISO and selecting Rescue a broken system. Works with LUKS disk encryption too.

Run grub-install after replacing efibootmgr with a working version.

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "Fixes the sorting bug that overwrites EFI boot variables." seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Revision history for this message
Mark Rich (sir-marky) wrote :

I have a Samsung Series 9 (NP900X3D) laptop. Previous versions of Ubuntu worked with UEFI but by both updating over-the-air from 14.04 and by doing a fresh install from the live CD burned to a USB stick (by using existing partition table or by zapping it and creating a new one), the system refused to boot at all with 14.10.

This is very much a bad bug as it's taken me 5 days to get this fixed! Killing boot is a fairly big showstopper!

From the above thread, jorisc90's note from point 4 was the fix for me.
The laptop now boots again.

Revision history for this message
Dominik Gierlach (dominik-gierlach) wrote :

After using 0.9.0 from upstream, I created a patched version of utopic's 0.7.0 package. It's available in my ppa:
ppa:dominik-gierlach/ppa

It seems to work fine for me, but it might kill your kittens. Feel free to test it, though!

Revision history for this message
SergeiS (sergei-redleafsoft) wrote :

I was about to post another bug report but found this one. Again, if the bug was fixed, it would have saved me about 3 hours on a weekend to get to the bottom of this. I don't know if 14.10 is going to have new iso files made or if it is possible to have efibootmgr automatically updated before installation process begins, but if it is, please consider updating the package, as it just plain brakes installation on UEFI systems and the nature of the problem is too complicated for anybody but an expert to resolve on its own.

POSSIBLE WORKAROUND:

After 14.10 Live cd boots, connect to internet and perform the following:

wget http://launchpadlibrarian.net/144695214/efibootmgr_0.5.4-7_amd64.deb
sudo dpkg -i efibootmgr_0.5.4-7_amd64.deb
efibootmgr -V # should report 0.5.4

proceed with installation

after installation, verify that the downgraded package stayed in place
efibootmgr -V # should still report 0.5.4

Changed in efibootmgr (Ubuntu):
importance: Undecided → Critical
Changed in hundredpapercuts:
status: New → Won't Fix
status: Won't Fix → Confirmed
importance: Undecided → Critical
Revision history for this message
Moritz Heiber (mheiber) wrote :

This is a really serious issue for anybody running/upgrading/installing Utopic under UEFI.

Another way of working around this limitation is to install the package from Vivid.

Boot the system from a live CD and use wget to get ahold of the packages from Vivid:

# Needed for the newer version to work correctly
wget http://mirrors.kernel.org/ubuntu/pool/main/e/efivar/libefivar0_0.15-2_amd64.deb

wget http://mirrors.kernel.org/ubuntu/pool/main/e/efibootmgr/efibootmgr_0.11.0-1_amd64.deb

dpkg -i libefivar0_0.15-2_amd64.deb efibootmgr_0.11.0-1_amd64.deb

Then run 'grub-update' (to make sure we have all the kernels accounted for) and then 'grub-install /dev/sdX' (replace X with the number of the harddrive you're using).

After that booting in UEFI mode should be working again.

PLEASE FIX THIS ASAP!

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Targetting to utopic for the SRU process.

This looks like it really is "just" an efibootmgr bug, so I'll mark the grub2 task Invalid.

Changed in grub2 (Ubuntu):
status: New → Invalid
Changed in efibootmgr (Ubuntu):
status: Confirmed → Triaged
Changed in grub2 (Ubuntu Utopic):
status: New → Invalid
Changed in efibootmgr (Ubuntu Utopic):
status: New → Triaged
importance: Undecided → Critical
Changed in efibootmgr (Ubuntu):
status: Triaged → Fix Released
Changed in efibootmgr (Ubuntu Utopic):
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
Changed in efibootmgr (Ubuntu Utopic):
status: Triaged → In Progress
description: updated
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Uploaded efibootmgr 0.7.0-2ubuntu0.14.10.1 to utopic-proposed, so as soon as it can be reviewed and accepted by the SRU team we will be able to start testing/verifying the fix.

Changed in efibootmgr (Ubuntu Utopic):
importance: Critical → High
Revision history for this message
Chris J Arges (arges) wrote : Please test proposed package

Hello Krzysztof, or anyone else affected,

Accepted efibootmgr into utopic-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/efibootmgr/0.7.0-2ubuntu0.14.10.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in efibootmgr (Ubuntu Utopic):
status: In Progress → Fix Committed
tags: added: verification-needed
Changed in hundredpapercuts:
status: Confirmed → Fix Released
status: Fix Released → Fix Committed
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Has anyone had a chance to test this if they were seeing the issue?

Revision history for this message
Chris Emerson (chris-ulp) wrote :

Hi,

I've just installed the proposed efibootmgr package (0.7.0-2ubuntu0.14.10.1), and run "sudo update-grub" and "sudo grub-install /dev/sda" (as above), and then the system rebooted fine.

Is that enough to check efibootmgr, or do I need to do something else too?

Chris

Revision history for this message
Patrik Lundquist (patrik-lundquist) wrote :

That's enough.

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

We got report that the fix was verified successfully; replacing verification-needed with the verification-done tag.

tags: added: verification-done
removed: verification-needed
no longer affects: grub2 (Ubuntu)
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package efibootmgr - 0.7.0-2ubuntu0.14.10.1

---------------
efibootmgr (0.7.0-2ubuntu0.14.10.1) utopic-proposed; urgency=medium

  * debian/control: update maintainer.
  * debian/patches/git_fix_compare_sizes_895b702a.patch: fix data size in
    compare function, avoids using a duplicate boot var for newly created
    entries in the boot manager. (LP: #1363719)
 -- Mathieu Trudel-Lapierre <email address hidden> Wed, 18 Feb 2015 09:03:10 -0500

Changed in efibootmgr (Ubuntu Utopic):
status: Fix Committed → Fix Released
Revision history for this message
Brian Murray (brian-murray) wrote : Update Released

The verification of the Stable Release Update for efibootmgr has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Changed in efibootmgr (Ubuntu Utopic):
importance: High → Critical
Mörgæs (moergaes)
Changed in hundredpapercuts:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.