Bug 2492140

Summary:	Image builds fail with grub2-2.12-65.fc45 due to scriptlets no longer copying expected EFI files
Product:	[Fedora] Fedora	Reporter:	Adam Williamson <awilliam>
Component:	grub2	Assignee:	Nicolas Frayer <nfrayer>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	bcl, josherna, lkundrak, lsandova, mlewando, nfrayer, ngompa13, pjones, rapneset, sdevlieg
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:	openqa
Fixed In Version:		Doc Type:	---
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2026-06-26 08:51:21 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Adam Williamson 2026-06-24 11:38:08 UTC

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.

Comment 1 Adam Williamson 2026-06-24 11:41:57 UTC

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.

Comment 2 rapneset 2026-06-25 10:24:19 UTC

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.

Comment 3 Brian Lane 2026-06-25 16:45:57 UTC

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.

Comment 4 Leo Sandoval 2026-06-25 18:15:27 UTC

(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

Comment 5 Adam Williamson 2026-06-26 08:51:21 UTC

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

Comment 6 Leo Sandoval 2026-06-26 17:02:16 UTC

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