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.
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.
do you know if this worked on F31?
According to https://bugzilla.redhat.com/show_bug.cgi?id=1804862#c17 it is a regression from F31.
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.
(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
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.
As much as I hate to say this the day before a slipped Go/No-Go, I concur. +1 blocker.
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.
+1 blocker
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.
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.
FEDORA-2020-db93ac7419 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-db93ac7419
If the decision is made to do a new compose for this, then I can verify that the compose is fixed on affected hardware.
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.
Can somebody affected please test this with RC1.6? Hans? https://dl.fedoraproject.org/pub/alt/stage/32_RC-1.6/ Thanks.
Just tested RC-1.6 on a Lenovo S130. The issue is fixed. Thanks Hans.
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.
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.