Since RHEL 9, /boot/efi/EFI/redhat/grub.cfg should looks like this

search --no-floppy --root-dev-only --fs-uuid --set=dev 3bb92e00-8b56-4abe-a894-23de2bea8406
set prefix=($dev)/grub2
export $prefix
configfile $prefix/grub.cfg 

Problems that arise from this change are that for years customers, and engineers, know that `grub2-mkconfig` will rewrite your grub.cfg file back to the correct state. If there's a typo or mistake or a missing kernel, just use grub2-mkconfig and rewrite the file. This results in a weird state in r9 UEFI because

• The default kernel is "saved" which comes from grubenv
• we no longer have /boot/efi/EFI/redhat/grubenv
• if this file is missing, then grub default to the 0 index
• customers then open cases because their systems don't default to the new kernels and from their perspective everything is setup correctly

In order to fix this broken state, you must remove /boot/efi/EFI/redhat/grub.cfg and reinstall grub2-common. Whats really strange about this is that this package doesn't own that file. This packages checks if you have grub2-efi-x64 installed, and then runs grub2-mkconfig, and then rewrites that with a cat

[root@r9 ~]# rpm -q grub2-common --scripts 
<snip>
if test ! -f ${EFI_HOME}/grub.cfg; then
    # there's no config in ESP, create one
    grub2-mkconfig -o ${EFI_HOME}/grub.cfg
    cp -a ${EFI_HOME}/grub.cfg ${EFI_HOME}/grub.cfg.rpmsave
    cp -a ${EFI_HOME}/grub.cfg ${GRUB_HOME}/
fi

if grep -q "configfile" ${EFI_HOME}/grub.cfg && grep -q "root-dev-only" ${EFI_HOME}/grub.cfg; then
    exit 0 # already unified, nothing to do
fi

# create a stub grub2 config in EFI
BOOT_UUID=$(grub2-probe --target=fs_uuid ${GRUB_HOME})
GRUB_DIR=$(grub2-mkrelpath ${GRUB_HOME})

cat << EOF > ${EFI_HOME}/grub.cfg.stb
search --no-floppy --root-dev-only --fs-uuid --set=dev ${BOOT_UUID}
set prefix=(\$dev)${GRUB_DIR}
export \$prefix
configfile \$prefix/grub.cfg
EOF

if test -f ${EFI_HOME}/grubenv; then
    cp -a ${EFI_HOME}/grubenv ${EFI_HOME}/grubenv.rpmsave
    mv --force ${EFI_HOME}/grubenv ${GRUB_HOME}/grubenv
fi

We can even see it generates the grubenv then moves it. So it's intentionally preventing anyone who ran grub2-mkconfig against /boot/efi/EFI/redhat/grub.cfg (safe to use for years) unable to use grubenv variables which breaks the way our grub is configured to work. 

The fix boils down to a strong familiarity with a very new and somewhat strange process to put the files back in place. I haven't thought of a title for a KCS that would capture the right people as people in this scenario don't know why they're in it. KCS Issue: "your grub2 efi grub.cfg doesn't look like this stub file" doesn't have a good ring to it.

Request

How can we safeguard the use of grub2-mkconfig against /boot/efi/EFI/redhat/grub.cfg?

Can we make /boot/efi/EFI/redhat/grub.cfg a file provided by grub2-efi-x64 (instead of a ghost file) so that if I reinstall the package that owns it, the file gets replaced?

Why does grub2-common not claim ownership of that file as well?

If this was an actual file, provided by grub2-efi-x64, then rpm -V would also work as well because right now we expect it say a very specific thing, but have nothing to verify or guarantee that. 

[root@r9 ~]# echo test > /boot/efi/EFI/redhat/grub.cfg
[root@r9 ~]# rpm -V grub2-efi-x64
[root@r9 ~]# rpm -V grub2-efi-x64 -v
.........  c /boot/efi/EFI/redhat/grub.cfg

___

If this is a long term change, then we need to safeguard it from misuse