Uh, sorry - openQA hits that error during install of Silverblue on UEFI. BIOS install works.

@hhei you did lots of testing for this change but apparently there is something else needed from CoreOS. Can you please help debug this one?

It's not just CoreOS - I expect we'd hit this problem on any UEFI immutable (aka Atomic, aka image mode) case that uses bootupd. openQA hits it installing Silverblue, as I mentioned above. I don't recall if IoT adopted bootupd yet, but if it did, I'd expect it to be affected too.

@lsandova and I at least traced it back to the get_efi_vendor function in src/efi.rs - that's where the error comes from. That function is looking for a shim file and taking the name of the directory it finds it in as the "vendor" name - but in this case it's not finding a shim file and bailing out. We can't tell which invocation of it (there are two in efi.rs and one in bootupd.rs) we're hitting. We think it's looking in usr/lib/bootupd/updates/EFI within the 'sysroot' it's passed - that's "the payload directory for an available update for a component", where the "component" is the EFI one. But we've no idea how that's supposed to get populated.

The big change in grub here is https://src.fedoraproject.org/rpms/grub2/c/e02b6e88c71642ecc063ae7aefbd09b9be80d50e?branch=rawhide , which - AIUI - basically makes grub put EFI stuff in grub_efi_dir (which is under libdir) instead of efi_esp_dir (which is /boot/efi/EFI/fedora , i.e. it's directly on the ESP). There's then a %posttrans script for the -efi subpackages which copies the whole of grub_efi_dir to efi_esp_dir, but this is not done on atomic/image mode, it's skipped if /run/ostree-booted exists, with the comment "On image mode, bootupd takes care of installing bootloader updates to the ESP".

So if bootupd is expecting the ESP to be populated here - if the usr/lib/bootupd/updates/EFI thing is populated from it, or whatever - each time get_efi_vendor is called, that expectation may have just broken. We may be in a bit of a catch-22 here, where we're expecting bootupd to do the work of populating the ESP, but bootupd fails if the ESP isn't populated?

Yes, seems I missed some testing, will checking now.

Find the root cause: I used the updated grub2 & shim ( the scratch build based on https://src.fedoraproject.org/rpms/shim/pull-request/5 ) in my testing, but if we only have the updated grub2, then shim files will be missed when doing generate-update-metadata as will copy files from usr/lib/efi (but not find shim files), see https://jenkins-coreos-ci.apps.ocp.fedoraproject.org/job/test-override/166

shim-x64-15.8-3.x86_64 (fedora-coreos-pool)
...
+ /usr/bin/bootupctl backend generate-update-metadata
Generated update layout for BIOS: grub2-tools-1:2.12-41.fc44.x86_64
Generated update layout for EFI: grub2-1:2.12-41.fc44

In this case, maybe should add checking in bootupd, if shim or grub2 is not ready, then fall back to copy files from legacy usr/lib/ostree-boot.

If the fix is going to be in bootupd, then we can re-run the tests on this when the fixed bootupd is stable, and if the fix works, this will pass and go through.

@hhei thanks for the analysis and the proposed fix.

@adamwill I have launched a shim build so both packages, shim and grub, would have the same upgrade logic and with the change that @hhei is proposing, testing would go fine this time.

@dustymabe @adamwill I just need to do a minor change on shim (see https://bodhi.fedoraproject.org/updates/FEDORA-2025-6a839fa19e#comment-4280011) before you can re-run all tests. I let you know once shim fix is merged.

now that the new shim is in this passes CoreOS tests

Now that shim landed we need this one as well for Bootable Containers systems: https://github.com/fedora-silverblue/issue-tracker/issues/671. I'm testing it.

Let's push this one now that the shim update landed.

I am OK to ship this.