Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1235323 - efibootmgr fails when creating or deleting boot items randomly
Summary: efibootmgr fails when creating or deleting boot items randomly
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: efibootmgr
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1236934 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-06-24 14:05 UTC by Petr Schindler
Modified: 2015-10-03 21:16 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-03 21:16:55 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
anaconda's program.log after the installation (74.43 KB, text/plain)
2015-06-24 14:05 UTC, Petr Schindler
no flags Details
output of journalctl -a (838.09 KB, text/plain)
2015-06-24 14:06 UTC, Petr Schindler
no flags Details
anaconda's anaconda.log after the installation (19.38 KB, text/plain)
2015-06-24 14:07 UTC, Petr Schindler
no flags Details
fallback message before grub is shown (138.00 KB, image/jpeg)
2015-06-26 14:43 UTC, Kamil Páral
no flags Details
anaconda error when efibootmgr fails (676.91 KB, image/jpeg)
2015-06-26 14:46 UTC, Kamil Páral
no flags Details

Description Petr Schindler 2015-06-24 14:05:50 UTC
Created attachment 1042765 [details]
anaconda's program.log after the installation

Description of problem:
At the end of the installation of Fedora 22 from netinst I got error message: Failed to set new efi boot target. This is most likely a kernel or firmware bug.

Newly installed system is not bootable after reboot.

Version-Release number of selected component (if applicable):
efibootmgr 0.11.0

How reproducible:
Seems to happen always now on my desktop

Steps to Reproduce:
1. Install fedora with anaconda
2.
3.

Actual results:
Doesn't set new efi boot target

Expected results:
New efi boot target is set.

Additional info:

Comment 1 Petr Schindler 2015-06-24 14:06:42 UTC
Created attachment 1042766 [details]
output of journalctl -a

Comment 2 Petr Schindler 2015-06-24 14:07:15 UTC
Created attachment 1042767 [details]
anaconda's anaconda.log after the installation

Comment 3 Kamil Páral 2015-06-26 14:42:02 UTC
The important part of program.log is this:

15:12:07,032 INFO program: Running... efibootmgr
15:12:07,057 INFO program: BootCurrent: 0012
15:12:07,058 INFO program: Timeout: 2 seconds
15:12:07,058 INFO program: BootOrder: 0011,0012,0004,0005,000E,0003,000D
15:12:07,058 INFO program: Boot0003* UEFI: Built-in EFI Shell
15:12:07,058 INFO program: Boot0004* Hard Drive
15:12:07,058 INFO program: Boot0005* CD/DVD Drive
15:12:07,058 INFO program: Boot000D* UEFI OS
15:12:07,058 INFO program: Boot000E* Unknown Device
15:12:07,059 INFO program: Boot0011* UEFI OS
15:12:07,059 INFO program: Boot0012* UEFI: SanDisk Extreme 0001
15:12:07,059 DEBUG program: Return code: 0
15:12:07,059 INFO program: Running... efibootmgr -c -w -L Fedora -d /dev/md/Volume0_0 -p 1 -l \EFI\fedora\shim.efi
15:12:07,091 INFO program: efibootmgr: Could not add entry to BootOrder: No such file or directory
15:12:07,092 DEBUG program: Return code: 6

I have seen exactly the same issue when installing Fedora 22 Workstation netinst on my fresh new ThinkPad T450s. Unfortunately, I lost the logs, but the error was exactly the same and the return code was 6 as well, I remember it. Afterwards, there was no 'Fedora' boot menu item in UEFI, but the system still booted, I assume it was some kind of fallback from the ESP. There was a short flash of some text before the grub menu was displayed. I was quite lucky to capture it with a camera (but really, it is a fraction of a second long, if that's something you control, please make it stay longer), and it read:

System BootOrder not found. Initializing defaults.
Creating boot entry "Boot0014" with label "Fedora" for file "\EFI\fedora\shim.efi"

After booting that system and running efibootmgr -v, I saw _two_ "Fedora" items (exactly the same), probably with IDs 0013 and 0014. I tried to run the efibootmgr command from anaconda logs to create my own "persistent" Fedora entry, and it passed without problems (id 0015). But after reboot, again there was no item in UEFI, and I saw the same fallback message before grub.

During the next boot, I first deleted those two existing Fedora items from UEFI, and only then created a new one. And finally it persisted and I can now boot the system without seeing that fallback message.

I tried to reinstall the system to test whether this is reproducible (and lost all the logs in the process, because I forgot to back them up), and this time I received a different error message during installation - Fedora item was already present, so it did not fail during creating the item, but during deleting the existing item. This is an excerpt from anaconda's program.log:

13:25:48,967 INFO program: Running... efibootmgr
13:25:48,980 INFO program: BootCurrent: 000C
13:25:48,980 INFO program: Timeout: 0 seconds
13:25:48,980 INFO program: BootOrder: 0013,0007,0008,0009,000A,000B,000C,000D,0012
13:25:48,981 INFO program: Boot0000  Setup
13:25:48,981 INFO program: Boot0001  Boot Menu
13:25:48,981 INFO program: Boot0002  Diagnostic Splash Screen
13:25:48,981 INFO program: Boot0003  Lenovo Diagnostics
13:25:48,981 INFO program: Boot0004  Startup Interrupt Menu
13:25:48,981 INFO program: Boot0005  Rescue and Recovery
13:25:48,981 INFO program: Boot0006  MEBx Hot Key
13:25:48,981 INFO program: Boot0007* USB CD
13:25:48,981 INFO program: Boot0008* USB FDD
13:25:48,981 INFO program: Boot0009* ATA HDD0
13:25:48,982 INFO program: Boot000A* ATA HDD1
13:25:48,982 INFO program: Boot000B* ATA HDD2
13:25:48,982 INFO program: Boot000C* USB HDD
13:25:48,982 INFO program: Boot000D* PCI LAN
13:25:48,982 INFO program: Boot000E* IDER BOOT CDROM
13:25:48,982 INFO program: Boot000F* IDER BOOT Floppy
13:25:48,982 INFO program: Boot0010* ATA HDD
13:25:48,982 INFO program: Boot0011* ATAPI CD
13:25:48,982 INFO program: Boot0012* PCI LAN
13:25:48,982 INFO program: Boot0013* Fedora
13:25:48,983 DEBUG program: Return code: 0
13:25:48,983 INFO program: Running... efibootmgr -b 0013 -B
13:25:48,996 INFO program: efibootmgr: Boot entry 0013 not found
13:25:48,996 INFO program: efibootmgr: Could not delete boot variable: Success
13:25:48,996 DEBUG program: Return code: 15

("error: Success" is a funny message, btw)

If needed, I can provide more logs or try some stuff. But until now, I haven't seen efibootmgr fail when I run it in my booted session - I've only experienced that the changes seemed to have been performed correctly, but did not persist after reboot. All the errors we've seen so far were from an installation environment (all netinst, maybe affects Live as well?). When we tried to execute the same efibootmgr command in the installation environment directly after it failed in anaconda, it succeeded. Maybe just the first attempt fails?

Comment 4 Kamil Páral 2015-06-26 14:43:48 UTC
Created attachment 1043568 [details]
fallback message before grub is shown

Comment 5 Kamil Páral 2015-06-26 14:46:50 UTC
Created attachment 1043569 [details]
anaconda error when efibootmgr fails

Comment 6 Kamil Páral 2015-07-01 11:58:15 UTC
We have seen this again with T420s and F22 Workstation netinst. The efibootmgr command failed in anaconda during installation, but when I switched to VT and ran the same command again, it passed.

Comment 7 Peter Jones 2015-07-16 15:11:55 UTC
Does this get better with this build of efivar installed: https://koji.fedoraproject.org/koji/buildinfo?buildID=668518 ?

Comment 8 Kamil Páral 2015-07-17 07:04:17 UTC
Thanks, we'll be able to test it next week.

Comment 9 Petr Schindler 2015-07-21 06:02:44 UTC
I tried to use that update and it ... works fine :) New EFI entry is created and installed system boots.

Comment 10 Kamil Páral 2015-07-21 07:16:28 UTC
I reproduced this with F23 boot.iso from 20150717. I propose this as an Alpha or Beta blocker using this criterion:
 A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility. 
https://fedoraproject.org/wiki/Fedora_23_Alpha_Release_Criteria#Expected_installed_system_boot_behavior

The tricky part here is that although anaconda complains that uefi installation failed (you need to choose "yes" to continue), the system still might boot OK, due to uefi fallback paths. So this might not be considered strictly Alpha blocker. I don't know how often that will work, though. Also, the error seems to occur in 100% cases on our machines.

Comment 11 Chris Murphy 2015-07-22 16:20:13 UTC
*** Bug 1236934 has been marked as a duplicate of this bug. ***

Comment 12 Adam Williamson 2015-07-27 16:44:25 UTC
Discussed at 2015-07-27 blocker review meeting: http://meetbot-raw.fedoraproject.org/fedora-blocker-review/2015-07-27/f23-blocker-review.2015-07-27-16.00.log.txt . Accepted as a Beta blocker: it does violate an Alpha criterion (cited in #c10), but only sometimes, as sometimes the installed system will boot thanks to the fallback path implementation (whether this succeeds or fails will be down to details of system configuration and firmware implementation of the fallback mechanism). Additionally, there is a relatively simple workaround (switch to a console and re-run the efibootmgr commands that the installer attempted) which can be documented for Alpha testers.

Comment 13 Adam Williamson 2015-07-27 17:19:08 UTC
Proposing as an Alpha freeze exception, it'd obviously be good to fix this for Alpha if possible.

Comment 14 Petr Schindler 2015-07-28 14:39:18 UTC
I tried Server-DVD-TC3 with efivar-0.21-1.fc23. I tested this on two workstations where it usually fails. On both machines it works fine with updated efivars - both boot to installed system.

Comment 15 Petr Schindler 2015-08-03 17:04:54 UTC
Discussed at today's blocker review meeting [1].

This bug was accepted as Alpha Freeze Exception - We would consider a fix for this during Alpha freeze.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2015-08-03/

Comment 16 Adam Williamson 2015-08-04 07:43:17 UTC
The rebuilt efivar made it in before Bodhi activation, so the fix should actually be in stable. Marking ON_QA so we can test with RC1.

Comment 17 Kamil Páral 2015-08-10 07:02:58 UTC
Since Alpha RCs, I have seen no issues. This seems to be fixed. Petr, can you please confirm? If you do, then close this bug, thanks.

Comment 18 Adam Williamson 2015-08-26 06:30:20 UTC
It's been 2 weeks, I'm just gonna close this. Re-open if the bug is somehow still present.

Comment 19 Kamil Páral 2015-09-17 11:00:13 UTC
This has been fixed in F23, but not in F22. The new F22 build was never posted to Bodhi. This is still affecting all F22 netinst installations. Please fix, thanks.

Comment 20 Adam Williamson 2015-09-17 15:05:22 UTC
Dropping blocker metadata, since it's fixed for 23.

Comment 21 Fedora Update System 2015-09-17 16:10:59 UTC
efivar-0.21-2.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-16114

Comment 22 Fedora Update System 2015-09-18 16:24:09 UTC
efivar-0.21-2.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update efivar'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-16114

Comment 23 Kamil Páral 2015-09-29 12:35:28 UTC
Please note that upgradepath is currently broken for this package.

Comment 24 Fedora Update System 2015-10-03 21:16:52 UTC
efivar-0.21-2.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.