Bug 1826864 - libefivar fails to parse the emmc path if just a disk is specified, breaking anaconda bootloader install on eMMC-s
Summary: libefivar fails to parse the emmc path if just a disk is specified, breaking ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: efivar
Version: 32
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: IoT F32FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2020-04-22 16:33 UTC by Hans de Goede
Modified: 2020-04-23 18:02 UTC (History)
9 users (show)

Fixed In Version: efivar-37-7.fc32
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-23 18:02:56 UTC
Type: Bug


Attachments (Terms of Use)

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: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.6.y&id=b5887920dbe9777858fe02cf56e75a1142a40d09

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. "
https://fedoraproject.org/wiki/Basic_Release_Criteria#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 https://bugzilla.redhat.com/show_bug.cgi?id=1804862#c17 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: https://github.com/rhboot/efivar/pull/150

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. https://bodhi.fedoraproject.org/updates/FEDORA-2020-db93ac7419

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?
https://dl.fedoraproject.org/pub/alt/stage/32_RC-1.6/
Thanks.

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.


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