Answer currently above is pretty good, but does not stress adequately root cause of your issue.
From reading of your information dump, you probably only have linux formatted /boot partition, but that is not enough for UEFI machine to boot.
Your disk does not match UEFI prescribed layout for bootable disks.
As was already mentioned above, with UEFI, we are entering a new world of how bootloaders are setup, and requisites are completely different from old BIOS method. UEFI uses completely new partition table format and understands filesystems now(!).
This is simplest set of essential requirements for your disk to be recognized by UEFI firmware as UEFI bootable and booted from:
- disk must be partitioned with GPT partitioning scheme
- somewhere on the disk, in the GPT partition table, there must be one and exactly one partition present, and it must be marked as
EFI System Partition, so called ESP; in automated streamlined setups like redhat anaconda, this is often GPT partition 1 of size ~512 MB. - this partition must be formatted to a filesystem, whose driver is present inside UEFI firmware (i.e. has been "installed" into the UEFI installation inside of the motherboard chip - this holds even in VM emulated UEFI chip)
- only UEFI filesystem driver that is always mandatory to be installed (by UEFI spec) in any UEFI install is FAT32, ie it's the safest(/only) bet for ESP to be formatted with
- on given ESP partition a special UEFI EXE at
\EFI\BOOT\BOOTx64.EFI (in case of 64bit system) must exist and must be valid runnable bootloader exe - if this file is not found there are several other paths that will be inspected, but all of them can be overridden by EFIVAR with custom bootloader exe path; this is what
efibootmgr is used as editor for.
It seems in your setup you have only one partition, sda1, with xfs filesystem, mounted into /boot.
Your UEFI, naturally, does not have XFS driver installed, thus it is unable to read this partition (and even if it had XFS driver, unless the partition is also of type ESP, it would still not boot from it).
This is my best guess because you forgot to add fdisk -l.
In moden UEFI linux installs ESP is not /boot, and it mounts deeper within /boot, like /boot/efi!
Fix is relatively simple: you need to ensure your partition table is of GPT type (which according to your grub line it already is) and add new partition of ESP type, then format it to FAT32, and ensure your /boot is not marked as ESP. /boot should be marked as normal Linux filesystem type.
In GPT scheme partition types are UUIDs (but do not confuse them (partition types UUIDs) with partition identifying UUIDs!) so ESP is EFI System (C12A7328-F81F-11D2-BA4B-00A0C93EC93B) type exaclty, while Linux filesystem is one of many: for example Linux root (x86-64) (4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709). There is probably one explicit Linux type for /boot even.
Now, UEFI only cares for ESP, and as long as it can find it, it will run any UEFI exe it can find there - this "magic" exe is, what used to be called "bootloader" before: it is a program, that is supposed to load your actual OS.
Given "installing" bootloader is now as simple as copying exe onto FAT32 fomratted ESP, the process of bootloader intall got "simpler" for the user. Because UEFI exe is well known format derived from windows PE exe, it is also much easier to write bootloaders now, too. Thus there is also much bigger choice of bootloaders to chose from now.
For few examples:
- refind
- systemd-boot
- gummiboot
- syslinux
- linux(!!!)
- and ... grub
Yes you read right, modern linux kernel, compiled with EFI stub (which most of them are) is fully functional UEFI bootloader. Actually it can boot directly into itself from ESP without need of any intermediatory crap. So you could easily boot directly to linux right from UEFI already.
Unfortunately of all the bootloaders I mentioned here, grub is the probably shittiest possible. Because of this undeniable quality, it is the go to choice on 95% linux distributions on the market (this behavior is often the case in linux ecosystem).
The reasons for this choice are often very finicky, it's probably due to useless kernel selection menu at boot start that grub provides and due to the time distributions spent polishing their scripts for integrating new kernel installs appearing in this menu into the package manager.
So now, even after you prepare ESP and format it correctly and you could just boot straigth to linux from it correctly, right away, you have now second big linux booting problem, known as "the grub problem".
GRUB predates UEFI and it solves many booting issues old BIOS had the same way as UEFI does. By now you should realize UEFI is basically its own, Windows 98 level OS, only it is preinstalled directly into the motherboard. It is also very complex.
Same way, GRUB is it's own special mini-OS pre-installed into traditional /boot partition (it has it's own filesystem drivers just like UEFI, it's own shell like UEFI, and other stupid things, just like UEFI, only nobody knows/remembers how to use and handle them). You could just ditch it, but as you want your automagic kernel updating to work in conjunction with kernel package updates (through yum/dnf) you need to fix it now.
So in your case this how your boot chain must look like UEFI(OS)->GRUB(OS)->LINUX(OS).
Thus after you fix your UEFI preconditions listed above, you must now fix your GRUB preconditions. GRUB must properly installed into the ESP, so that UEFI can boot into it, and then it must be configured to boot your Linux instead.
Now, where to mount ESP in your in-linux / tree for this to work is highly distro dependant, so that is beyond me, but I guess /boot/efi is default for redhat family.
So, you need to rm -rf that directory in /boot that is it empty, and then mount you frshly formated empty ESP with vfat driver there (/boot/efi). Once you have that done, you need to chroot into the install, and force local grub to regenerate it's installation in UEFI mode into /boot/efi aka "/dev/sda/esp".
This is highly distro specific and also depending on the grub version and can be anything between:
grub-install /dev/sdX update-grub
to
grub-install --target=x86_64-efi /dev/sdbX grub-install --recheck /dev/sdX
From within chroot.
If you did right, you should now see GRUB install files appear in originally empty ESP partition and new EFIVAR should/could appear pointing to something like \EFI\redhat\shimx64.efi into ESP (by UUID).
I suggest to remove all stale boot efivars with efbootmgr before grub regeneration/reinstall so you can verify entry added.
Once you are done you should now see grub kernel boot menu after reboot.
Suggested good night readings related to the issue:
https://en.wikipedia.org/wiki/GUID_Partition_Table
https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface
http://www.rodsbooks.com/efi-bootloaders/
