Build succeeded.
https://fedora.softwarefactory-project.io/zuul/buildset/9a689df1cd4a4f5688e5400c10807eb8

• build-images : SUCCESS in 44m 14s

I have an idea of what might be going on.
If you look at /etc/grub.d/00_header

You'll see this is the code that's used if $GRUB_FONT is not defined in /etc/default/grub (that variable is not defined anywhere on the system)
**in fact if you look at the grub manual https://www.gnu.org/software/grub/manual/grub/grub.html -- GRUB_FONT is never mentioned once.

    for dir in "${pkgdatadir}" "`echo '/boot/grub2' | sed "s,//*,/,g"`" /usr/share/grub ; do
        for basename in unicode unifont ascii; do
            path="${dir}/${basename}.pf2"
            if is_path_readable_by_grub "${path}" > /dev/null ; then
                font_path="${path}"
            else
                continue
            fi
            break 2

So what this doing is looping through three different directories looking for fonts
as soon as it finds any font {unicode, unifont, ascii}, it'll break out of the loop
BTW..."${pkgdatadir}" == /usr/share/grub

So basically it's looping through these three entries: /usr/share/grub /boot/grub2 /usr/share/grub
First off /boot/grub2 does not equate to /usr/share/grub as /usr/share/grub contains fonts
So /boot/grub2/fonts would need to be used instead of /boot/grub2

Also, why wouldn't we want to see if there are any fonts in /boot/grub2/fonts before checking the root filesystem???
As grub wouldn't need to load the root filesystem in order to load the font(s) it needs-- as it could just load them from the /boot partition

I "think" what needs to be done is to change this logic to

for dir in "echo '/boot/grub2/fonts' | sed "s,//*,/,g"" "${pkgdatadir}" /usr/share/grub ; do

and that's just keeping everything the same, just switching the order
I mean, I really don't see why we can't just do

for dir in /boot/grub2/fonts "${pkgdatadir}" /usr/share/grub ; do

I'm fairly certain this should solve this issue -- although I'm not sure why there seems to be an issue(delay??) in loading the unicode font from the root filesystem.
But, even if this there is a more correct solution -- I still think /boot/grub2/fonts should be checked before the root filesystem.
I mean isn't that why grub2-efi-aa64 contains /boot/grub2/fonts/unicode.pf2 in the first place?
If you look through /etc/grub.d/00_header -- the unicode font is the only font that's ever loaded.

I'll won't know for sure whether this will work until I get home in a few hours...I'll keep you posted

Making the above changes didn't work -- they resulted in a grub.cfg that contains this

if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root 14b45e2d-a1e6-4594-9e2b-30bbaf935621
font="/grub2/fonts/unicode.pf2"
fi

**the x$feature_default_font_path logic does not work right and results in a 5 second boot delay

The logic in /etc/grub.d/00_header is pretty bizarre, if it finds a font
and it's readable by grub -- then just set feature_default_font_path?!
I don't get it -- why not just load the font from where you found it!?

    for basename in unicode unifont ascii; do
    path="${dir}/${basename}.pf2"
    if is_path_readable_by_grub "${path}" > /dev/null ; then
        font_path="${path}"
    else
        continue
    fi
    break 2
    done
done
if [ -n "${font_path}" ] ; then
cat << EOF

if [ x\$feature_default_font_path = xy ] ; then
font=unicode
else
EOF

But this logic shows that you can manually specify a font path via GRUB_FONT which this PR did.
That sounds like a perfectly reasonable way to approach this.

if [ "x$gfxterm" = x1 ]; then
if [ -n "$GRUB_FONT" ] ; then
# Make the font accessible
prepare_grub_to_access_device ${grub_probe} --target=device "${GRUB_FONT}"

I've renamed both
/boot/grub2/fonts/unicode.pf2
/usr/share/grub/unicode.pf2

but still it loads the unicode font (after a 5 second delay)
** so when the config specifies
font=unicode

Where exactly is grub loading that from?? It's loading it from somewhere...