See https://github.com/fedora-silverblue/issue-tracker/issues/530

Build succeeded.
https://fedora.softwarefactory-project.io/zuul/buildset/30d9715477b441e4900999fce1fd5fc5

• validate : SUCCESS in 2m 09s

No, I don't think your diagnosis is right.

Build succeeded.
https://fedora.softwarefactory-project.io/zuul/buildset/70bba6754d39432d8e62be632b7d70f8

• validate : SUCCESS in 2m 44s

Waiting for https://bodhi.fedoraproject.org/updates/FEDORA-2024-2bea026091 to land in rawhide.

See: https://github.com/fedora-silverblue/issue-tracker/issues/530

Build succeeded.
https://fedora.softwarefactory-project.io/zuul/buildset/70d510067dd443e89813bef2927eb4a7

• validate : SUCCESS in 2m 19s

I can hack openQA to run a test on that update with this change applied, probably...

https://openqa.stg.fedoraproject.org/tests/3531903 and dependencies should do that, if I got it right. I'll keep an eye on it.

So, results from this: the build and install tests pass. However, the rebase test fails. Rebasing down to the current Rawhide ostree works, but then doing rpm-ostree rollback to 'rollback' to the newer ostree built by the test fails, reporting that grub2-mkconfig failed - see https://openqa.stg.fedoraproject.org/tests/3531906#step/rpmostree_rebase/18 .

Not sure if that's considered bad enough to block this, or if it's fixable.

Yes, that is to be expected as systems installed using the bootupd mode in Anaconda won't have the config needed. This is what I fixed in https://github.com/ostreedev/ostree/pull/3150.

Older installations updating should not have this issue as the file would have been placed there by Anaconda.

New installations won't be able to rollback to previous ones but that's not something we support.

OK. I may have to fiddle with the openQA tests a bit to deal with that, but that's my problem, not yours. :) I see no reason not to go ahead and finally merge this now, if you don't!

Let's do it!

So, argh. I think this actually broke stuff. But I only just put the pieces together. :(

In openQA update tests (which we used to validate this) we only test BIOS boot of the installed system. We don't test UEFI boot. That's an oversight I should probably fix.

It looks like UEFI boot of an installed Silverblue has been failing in openQA compose tests (where we do test UEFI boot) ever since this merged - note how the last pass is Fedora-Rawhide-20240130.n.1 and the first fail is Fedora-Rawhide-20240207.n.0 .

I noticed this a couple of times but never got to looking into it till now. It also seems to be affecting IoT, which also uses bootupd.

I think what's happening is that bootupd does not write a "Fedora" entry to the UEFI boot manager list - that's a screenshot from an IoT install test hacked up to show the output of efibootmgr after install is complete - so boot will only work via the EFI fallback path, which is meant to be an emergency backup if something goes wrong, not the intended path. In openQA, it doesn't work because the firmware is not configured to try booting the system from hard disk via the fallback path; the system will only boot if the correct EFI boot manager entry is created.

Thanks for the investigation Adam. PR in https://github.com/rhinstaller/anaconda/pull/5508