Bug 2268505 - UEFI installs using bootupd do not write an EFI boot manager entry, can make it hard to boot the installed system
Summary: UEFI installs using bootupd do not write an EFI boot manager entry, can make ...
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: rust-bootupd
Version: rawhide
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Colin Walters
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa
Depends On:
Blocks: BetaBlocker, F41BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2024-03-07 20:54 UTC by Adam Williamson
Modified: 2024-06-11 07:40 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2024-03-12 04:03:09 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker FC-1184 0 None None None 2024-05-06 09:35:50 UTC

Description Adam Williamson 2024-03-07 20:54:05 UTC
As discussed in https://pagure.io/workstation-ostree-config/pull-request/453#comment-199664 and https://github.com/rhinstaller/anaconda/pull/5508 , I worked out that UEFI installs using bootupd do not write an EFI boot manager entry. This can make the installed system difficult to boot - it will depend on the system's firmware implementation and configuration (whether it defaults to trying fallback path boot from fixed disks if nothing else works, and whether any other boot entries are configured, for instance).

This does break openQA tests. It's hard to tell openQA "boot from the optical drive on the first boot then the hard disk on the second boot", which might make this work; instead we rely on booting from the optical drive on the first boot, then anaconda writing an EFI boot manager entry and marking it as the highest priority one, so on the second boot, we get the installed system. This works for installs where anaconda directly configures the bootloader, but does not work for ones where it calls bootupd.

Affected images are, I believe:

* Fedora IoT images built with osbuild (all F40+ images, and I think the F39 ones that IoT team wants us to switch to testing, per https://github.com/fedora-iot/iot-distro/issues/32 )
* All Fedora Atomic Desktop images since https://pagure.io/workstation-ostree-config/pull-request/453 (current F40+ images)

Proposing as a Beta blocker as a conditional violation of "A system installed without a graphical package set must boot to a state where it is possible to log in through at least one of the default virtual consoles." for the IoT case, where the system is not configured for fallback path boot. We may decide this isn't likely enough in 'typical' IoT cases to make this a blocker, but I wanted to discuss it. If we don't make it a blocker I would say we should at least make it an FE for the Atomic Desktop cases, which can be installed to any kind of system and might well be installed in a dual-boot configuration (where this bug will make it rather harder to boot Fedora).

Comment 1 Fedora Update System 2024-03-07 23:25:09 UTC
FEDORA-2024-2aca68bad6 (anaconda-40.22.2-2.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-2aca68bad6

Comment 2 Fedora Update System 2024-03-08 03:02:56 UTC
FEDORA-2024-2aca68bad6 has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-2aca68bad6`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-2aca68bad6

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 3 Adam Williamson 2024-03-11 15:57:41 UTC
+5 in https://pagure.io/fedora-qa/blocker-review/issue/1503 , marking accepted.

Comment 4 Fedora Update System 2024-03-12 04:03:09 UTC
FEDORA-2024-2aca68bad6 (anaconda-40.22.2-2.fc40) has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 5 Jiri Konecny 2024-03-12 13:24:45 UTC
This is fixed thank to the patch which we would like to replace by a correct solution. Adam, what are the intentions on Fedora40? Should we continue with your "DO NOT MERGE" patch / PR to Anaconda or should we rather backport the solution raised from the PR? Also do you want to file a new bug on this or re-open this one?

Comment 6 Adam Williamson 2024-03-12 15:08:43 UTC
Yeah, I'm not really sure, to be honest. What do you think? I'm OK with switching it out for the 'proper' fix between Beta and Final if it's not too late.

Comment 7 Timothée Ravier 2024-03-12 16:22:18 UTC
Well, I'd say that the fix from the patch isn't really great. It should get us through the Beta but I'd prefer to have a better fix for the final release.

Comment 8 Adam Williamson 2024-03-12 16:45:05 UTC
Sure, that's fine with me. As long as I'm not required to write it :)

Comment 11 Timothée Ravier 2024-03-18 18:53:21 UTC
Followup in https://bugzilla.redhat.com/show_bug.cgi?id=2270154

Comment 12 Adam Williamson 2024-03-25 23:37:15 UTC
What is the plan for Rawhide here? This is still broken on Rawhide, and now the anaconda package has been bumped to 41.6, it dropped my backport of my (rejected) patch to address it. So this is now broken on all Rawhide atomic desktop images, and it is causing openQA tests to fail.

I will have to put in some kind of ugly workaround, but could we perhaps also do the reversion on Rawhide at least until there is some kind of plan for a better fix?

Comment 13 Adam Williamson 2024-03-26 00:02:40 UTC
Also proposing as an F41 Beta blocker, as now my patch is dropped, this is once again broken for Rawhide IoT installs, I believe.

Comment 14 Adam Williamson 2024-04-09 15:11:42 UTC
ping: geoffrey, peter, paul - what do you think about this?

the situation is that unpatched anaconda does not create an EFI boot manager entry when installing with bootupd. So the installed system will only boot to Fedora if it is configured to boot the drive Fedora was installed to using UEFI fallback path behaviour. If the firmware happens not to be configured that way, or if any other boot path takes priority, the installed system will not boot to Fedora.

I sent a PR for this - https://github.com/rhinstaller/anaconda/pull/5508 - but it was rejected over concerns that it's not configurable via kickstart and it doesn't behave exactly the same as anaconda's own EFI boot manager entry creation.

right now the patch is being carried downstream for F40, but that's awkward due to anaconda team's use of packit, and the patch is not in rawhide.

what do you guys think about this? are you concerned about the unpatched behaviour?

The Atomic Desktop builds reverted bootupd (again) because of this, I don't know if you want to do that, or something else.

Comment 15 Paul Whalen 2024-04-10 15:44:32 UTC
(In reply to Adam Williamson from comment #14)
> ping: geoffrey, peter, paul - what do you think about this?

> The Atomic Desktop builds reverted bootupd (again) because of this, I don't
> know if you want to do that, or something else.

We followed their lead and reverted as well with the intention of re-enabling after the GA isos were created.

Comment 16 Adam Williamson 2024-04-10 15:50:13 UTC
ah, thanks.

Comment 17 Jiri Konecny 2024-05-06 09:27:41 UTC
Hi, we discussed this some time ago during the planning session and the Anaconda team don't have resources to work on this soon, so we decided to rather not commit on fixing this rather than providing fix for this late and break everything on the last minute.

I already contacted Timethee, so people are aware of this. There is already tracker for fixing this in the bootupd which to my understanding is the target solution right now: https://github.com/coreos/bootupd/issues/630.


Based on what I wrote above I think it give more sense to switch this bug to bootupd. Feel free to return it back if you need something from us.

Comment 18 Adam Williamson 2024-05-06 15:44:36 UTC
The only thing that concerns me about that is that we then have two mechanisms and possible interactions between them which may not be defined. e.g. right now, as I found, anaconda calls its entry "Fedora" and uses one strategy to look for existing entries it made before, bootupd calls its entry "fedora" and uses a different strategy. Is there going to be some kind of discussion to try and keep the two approaches aligned?

Comment 19 Adam Williamson 2024-05-06 15:45:00 UTC
Also, since the objection to my fix was that it would not respect kickstart options, is bootupd's approach going to respect kickstart options?

Comment 20 HuijingHei 2024-06-04 12:23:42 UTC
(In reply to Adam Williamson from comment #18)
> The only thing that concerns me about that is that we then have two
> mechanisms and possible interactions between them which may not be defined.
> e.g. right now, as I found, anaconda calls its entry "Fedora" and uses one
> strategy to look for existing entries it made before, bootupd calls its
> entry "fedora" and uses a different strategy. Is there going to be some kind
> of discussion to try and keep the two approaches aligned?

Could you help to provide some pointer where anaconda get its entry "Fedora"? bootupd use entry `fedora` from directory name that contains `shimx64.efi` like `\EFI\fedora\shimx64.efi`. Thanks!

Comment 21 HuijingHei 2024-06-04 14:01:20 UTC
> provide some pointer where anaconda get its entry "Fedora"?

Seems anaconda get its entry "Fedora" from `ANACONDA_PRODUCTNAME=$(sed -r -e 's/ *release.*//' /etc/system-release)`, see https://github.com/rhinstaller/anaconda/blob/f52880c8ac0f0b19d5e4b7887c80aedec1d4bfa7/data/liveinst/liveinst#L46, maybe in the future can align it to bootupd

Comment 22 Adam Williamson 2024-06-04 15:05:41 UTC
It seems to me like it would be more logical to change things so bootupd uses "Fedora", since that is the pre-existing behaviour and every existing Fedora UEFI install will be using "Fedora".

Comment 23 HuijingHei 2024-06-10 10:10:40 UTC
(In reply to Adam Williamson from comment #22)
> It seems to me like it would be more logical to change things so bootupd
> uses "Fedora", since that is the pre-existing behaviour and every existing
> Fedora UEFI install will be using "Fedora".

Make the change for bootupd, but using the entry name as `NAME` from `/etc/os-release`, see https://github.com/coreos/bootupd/pull/665#issuecomment-2152186214 and https://github.com/coreos/bootupd/pull/665#issuecomment-2152277788, which is slightly different from Anaconda (from /etc/system-release), bootupd will use "Fedora Linux" for fedora, and "CentOS Stream" for centos

Comment 24 Colin Walters 2024-06-10 13:08:41 UTC
> It seems to me like it would be more logical to change things so bootupd uses "Fedora", since that is the pre-existing behaviour and every existing Fedora UEFI install will be using "Fedora".

The arguments for os-release:

- /etc/system-release is (AFAIK) Fedora-derivative specific, whereas the os-release is a cross-distribution standard (not that bootupd is used many other places yet, but maybe)
- CentOS Stream still uses "CentOS" in /etc/system-release and no one cared or maybe noticed, but "CentOS Stream" is arguably more correct?

That said, I'm also fine to make it a build-time option to match what Anaconda does.

Comment 25 HuijingHei 2024-06-11 07:37:00 UTC
(In reply to Colin Walters from comment #24)
> That said, I'm also fine to make it a build-time option to match what
> Anaconda does.

How about using /etc/system-release if the file exists, else use `NAME` from `/etc/os-release`?


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