Fedora Account System
Red Hat Associate
Red Hat Customer
In https://src.fedoraproject.org/rpms/grub2/c/56915301905ba74f6452cfb5f43cde6a3cf87518?branch=rawhide , the grub2-efi %posttrans was changed to only copy EFI files if /boot/efi is mounted: # On image mode, bootupd takes care of installing bootloader updates to the ESP if [[ ! -e "/run/ostree-booted" ]]; then - cp -d --preserve=all %{grub_efi_dir}/* %{efi_esp_dir} || : + # Check if /boot/efi is actually mounted before cp + if ! mountpoint -q ${ESP_PATH}; then + : # no ESP mounted, nothing to do + else + cp -a ${EFI_DIR}/. ${EFI_ESP_DIR} || : + fi +fi This breaks image builds. e.g. Kiwi image builds fail with: [ ERROR ]: 03:24:30 | KiwiBootLoaderGrubSecureBootError: Signed grub2 efi loader not found whereas before we saw: [ INFO ]: 03:57:29 | --> Using grub image: /builddir/result/image/build/image-root/boot/efi/EFI/fedora/gcdx64.efi lorax builds are also affected, I suspect image-builder likely would be as well. I confirmed that I can get a successful image build by simply removing the mountpoint check: # On image mode, bootupd takes care of installing bootloader updates to the ESP if [[ ! -e "/run/ostree-booted" ]]; then cp -a ${EFI_DIR}/. ${EFI_ESP_DIR} || : fi but this probably isn't a "correct" fix. I'm not really sure what the most correct fix *would* be. CCing some image build type folks for ideas.
Note the update failed tests and was correctly gated so this isn't a "live" issue in Rawhide right now, but we do need to figure out what the right thing to do is here so lsandoval can move forward.
Would the issue would be that it's not an actual mount point on these builds? Can we just do: diff --git a/grub2.spec b/grub2.spec index 8665d22..fd39f72 100644 --- a/grub2.spec +++ b/grub2.spec @@ -436,10 +436,8 @@ fi # On image mode, bootupd takes care of installing bootloader updates to the ESP if [[ ! -e "/run/ostree-booted" ]]; then - # Check if /boot/efi is actually mounted before cp - if ! mountpoint -q ${ESP_PATH}; then - : # no ESP mounted, nothing to do - else + # Check if /boot/efi actually exists before cp + if [ -d "${EFI_ESP_DIR}" ]; then cp -a ${EFI_DIR}/. ${EFI_ESP_DIR} || : fi fi Though - the cp call does already swallow any errors anyway so seems like removing the check altogether is valid.
Checking for a mountpoint is wrong and as adam noted will break things like lorax and some of the image-builder types that install to a chroot. Packagers need to remember that their packages aren't always being installed on a running system, sometime they are being used inside a chroot-ish environment.
(In reply to Brian Lane from comment #3) > Checking for a mountpoint is wrong and as adam noted will break things like > lorax and some of the image-builder types that install to a chroot. > > Packagers need to remember that their packages aren't always being installed > on a running system, sometime they are being used inside a chroot-ish > environment. Lesson learnt. We basically uncovered something already wrong but unnoticed because this mount point check was in other place, not impacting .efi files installation. PR on the way https://src.fedoraproject.org/rpms/grub2/pull-request/236
https://bodhi.fedoraproject.org/updates/FEDORA-2026-c920f500a3 passes tests and went out, so I guess we're good here. Thanks. Please edit a fixed build into the F44 update too, or create a new F44 update (which will automatically obsolete the old one).
(In reply to Adam Williamson from comment #5) > https://bodhi.fedoraproject.org/updates/FEDORA-2026-c920f500a3 passes tests > and went out, so I guess we're good here. Thanks. Please edit a fixed build > into the F44 update too, or create a new F44 update (which will > automatically obsolete the old one). I have done the edit part on F44. Thanks Adam, Brian, Rolv!