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

Bug 1826864

Summary: libefivar fails to parse the emmc path if just a disk is specified, breaking anaconda bootloader install on eMMC-s
Product: [Fedora] Fedora Reporter: Hans de Goede <hdegoede>
Component: efivarAssignee: Peter Jones <pjones>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 32CC: awilliam, bcotton, kparal, mboddu, pbrobinson, pjones, red8012, robatino, sgallagh
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: AcceptedBlocker
Fixed In Version: efivar-37-7.fc32 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-23 18:02:56 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1269538, 1705305    

Description Hans de Goede 2020-04-22 16:33:40 UTC
I noticed this week that installing F32 on devices with an eMMC fails with the following error:

"The following error occurred while installing the boot loader. The system will not be bootable. Would you like to ignore this and continue with the installation?"

At first I though this was a kernel bug, specifically the bug fixed by this commit:

But when I tested the 1.5 release-candidate F32 compose, which has kernel 5.6.6, unfortunately the fixed kernel did not resolve the bootloader install error.

After some more debugging I have come to the conclusion that this is a bug in libefivar's parse_emmc() function. Anaconda calls efibootmgr like this:

efibootmgr -c -d /dev/mmcblk2 -p 1 -l '\EFI\fedora\shimia32.efi' -L Fedora

Which fails, but if, as a workaround instead I manually call it like this:

efibootmgr -c -d /dev/mmcblk2p1 -l '\EFI\fedora\shimia32.efi' -L Fedora

Then it works fine.

Note I'm pretty sure I know how to fix this and I'm working on a fix now.

Comment 1 Hans de Goede 2020-04-22 16:43:16 UTC
I'm sorry to do this so late in the cycle, but still:

Proposing as a Fedora 32 Final blocker bug:

"When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces. "

This bug blocks the installer from (successfully) completing the installation on any systems with an eMMC disk.

I'm not sure if this is a valid release blocker, most devices do not use an eMMC, otherwise we might have found this sooner, still there are many, many devices which do actually use an eMMC.

Devices with an eMMC are typically cheap x86 laptops and tablets using Bay Trail, Cherry Trail, Apollo Lake or Gemini Lake CPUs. There are some quite popular models such as: Asus T100TA / T100HA, Lenovo Ideapad Miix 310 / 320 and many others.

Note that a comment has been added to bug 1804862 about a user hitting that bug where the user is really hitting this bug, so we are already getting bug reports about this.

Selecting Yes on the (poorly worded) error dialog allows the installation to continue and there are some workarounds to then still get a working install:

1. On systems where Fedora is the only OS installed, the fallback boot.efi we install is often enough to automatically fix the problem at the first boot. Note that during my testing I have encountered systems where this is not the case even if Fedora is the sole OS, because the BIOS does not use the fallback boot.efi automatically.

2. In cases where the fallback boot.efi does not help, the user can manually add the EFI boot entry by calling efibootmgr with a slightly different syntax which works around the issue.

I'm working on a fix right now and I hope to have this ready later tonight (CET). The fix will be pretty straightforward and the fix involves a code-path which is only called when an eMMC is used, so the chances of the fix causing regressions elsewhere are very close to 0.

Comment 2 Adam Williamson 2020-04-22 16:56:12 UTC
do you know if this worked on F31?

Comment 3 Ben Cotton 2020-04-22 17:24:12 UTC
According to it is a regression from F31.

Comment 4 Hans de Goede 2020-04-22 17:27:53 UTC
Yes I'm pretty sure this is a regression from F31. As a hobby project I do a lot of HW enablement for x86 based tablets and these all have eMMCs, so if this was an issue with F31 I would have noticed when doing a fresh install on one of those. Unfortunately until this week I had only tested Fedora 32 through (dnf based) upgrades, and not fresh installs, otherwise I would have caught this sooner :|  I guess that is a lesson for next cycle for me.

Comment 5 Peter Robinson 2020-04-22 17:28:57 UTC
(In reply to Adam Williamson from comment #2)
> do you know if this worked on F31?

Yes, it did. Likely a problem also for IoT

Comment 6 Hans de Goede 2020-04-22 17:32:12 UTC
Oh right, this is also going to be an issue for IoT gateways, and I completely forgot about things like ComputeSticks and x86 bases topset boxes, ALL of these will also be impacted by this.

So earlier I wrote: "I'm not sure if this is a valid release blocker", I take that back, from my pov this really is a release blocker (sorry).

I'll try to get a fix posted upstream ASAP.

Comment 7 Stephen Gallagher 2020-04-22 17:42:22 UTC
As much as I hate to say this the day before a slipped Go/No-Go, I concur. +1 blocker.

Comment 8 Hans de Goede 2020-04-22 17:45:18 UTC
Ok, so another reason why I did not catch this is likely because the problem got introduced by an update to the efivar pkg from Feb. 24.

Comment 9 Ben Cotton 2020-04-22 17:58:32 UTC
+1 blocker

Comment 10 Hans de Goede 2020-04-22 17:59:18 UTC
Fix written, scratch pkg build done and tested, upstream pullreq here:

I will ping pjones asking for a review.

Comment 11 Hans de Goede 2020-04-22 18:31:32 UTC
The fix has been merged upstream and I've done a rawhide + f32 builds with the fix added.

I've also double-checked that things (efibootmgr from the cmdline) are fixed with official build. I will go and create an update for the official build in bodhi now.

Comment 12 Fedora Update System 2020-04-22 18:33:51 UTC
FEDORA-2020-db93ac7419 has been submitted as an update to Fedora 32.

Comment 13 Hans de Goede 2020-04-22 18:35:44 UTC
If the decision is made to do a new compose for this, then I can verify that the compose is fixed on affected hardware.

Comment 14 Adam Williamson 2020-04-22 18:37:07 UTC
given the range of hw affected, I have to be +1 blocker too, this is the kind of hardware people do want to be able to put Fedora on, after all.

That's +3 or +4 counting Hans, so setting accepted.

Comment 15 Kamil Páral 2020-04-23 12:22:38 UTC
Can somebody affected please test this with RC1.6? Hans?

Comment 16 Yu-Ann Chen 2020-04-23 13:39:27 UTC
Just tested RC-1.6 on a Lenovo S130. The issue is fixed. Thanks Hans.

Comment 17 Hans de Goede 2020-04-23 13:43:25 UTC
And I just tested this on an Asus T200TA and I too can confirm that with the 1.6 F32 compose the "The following error occurred while installing the boot loader..." problem is gone. The install finishes normally and the system also successfully boots into the installed system afterwards.

Comment 18 Fedora Update System 2020-04-23 18:02:56 UTC
FEDORA-2020-db93ac7419 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.