Bug 2268505

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

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.

+5 in https://pagure.io/fedora-qa/blocker-review/issue/1503 , marking accepted.

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.

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?

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.

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.

Sure, that's fine with me. As long as I'm not required to write it :)

https://github.com/rhinstaller/anaconda/pull/5508#issuecomment-1997003742

https://github.com/ostreedev/ostree/pull/3150#issuecomment-1998631267

Followup in https://bugzilla.redhat.com/show_bug.cgi?id=2270154

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?

Also proposing as an F41 Beta blocker, as now my patch is dropped, this is once again broken for Rawhide IoT installs, I believe.

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.

(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.

ah, thanks.

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.

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?

Also, since the objection to my fix was that it would not respect kickstart options, is bootupd's approach going to respect kickstart options?

(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!

> 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

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".

(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

> 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.

(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`?

So...what's the status of this? There was movement on it - https://github.com/rhinstaller/anaconda/pull/5508 got merged, and some other stuff. Is it expected that we should now be getting UEFI boot manager entries on fresh installs of things using bootupd? Does IoT currently have it enabled, or want to enable it for Beta? If so, I can re-test this.

If IoT doesn't currently have bootupd enabled or want to enable it for Beta this probably wouldn't be a blocker (other Atomic things still aren't release blocking yet).

I can test this out this week anyhow, but it'd be good to be sure what the *intended* situation is.

We've merged the logic on the bootupd side in https://github.com/coreos/bootupd/pull/665. This is not yet in a release.

I had been waiting for https://github.com/coreos/bootupd/pull/669 but maybe we should do a release now and land this PR after.

Once a bootupd package with https://github.com/coreos/bootupd/pull/665 is in Rawhide, we can re-enable it in Atomic Desktops and test again.

IoT still has bootupd enabled AFAIK.

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

Sure, that's fine by me.

(In reply to Colin Walters from comment #28)
> > How about using /etc/system-release if the file exists, else use `NAME` from `/etc/os-release`?
> 
> Sure, that's fine by me.

ACK, thanks Colin for the confirmation, will add it maybe in the next release.

(In reply to Adam Williamson from comment #26)

> If IoT doesn't currently have bootupd enabled or want to enable it for Beta
> this probably wouldn't be a blocker (other Atomic things still aren't
> release blocking yet).
> 
> I can test this out this week anyhow, but it'd be good to be sure what the
> *intended* situation is.

Still enabled in IoT.

(In reply to Timothée Ravier from comment #27)
> Once a bootupd package with https://github.com/coreos/bootupd/pull/665 is in
> Rawhide, 

Joseph built a release that included this, see https://koji.fedoraproject.org/koji/taskinfo?taskID=120298276

Let's give this another try! I've merged https://pagure.io/workstation-ostree-config/pull-request/528.

OK, this specific bug looks fixed with bootupd 0.2.20 in a fresh Silverblue Rawhide VM.

root@fedora:~# efibootmgr 
BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0003,0002,0000
Boot0000* UiApp	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0002* UEFI Misc Device	PciRoot(0x0)/Pci(0x2,0x3)/Pci(0x0,0x0){auto_created_boot_option}
Boot0003* Fedora Linux	HD(1,GPT,cde7ae6f-de16-4da8-a244-7d0b056056dd,0x800,0x12c000)/\EFI\fedora\shimx64.efi

Great. I think we can call it closed, then? I can confirm the same in the current Silverblue. Can't check IoT because of https://bugzilla.redhat.com/show_bug.cgi?id=2297632 .

Thanks Timothée and Adam for the testing.