Different Linux distributions use GRUB2 with UEFI in different ways: Debian/Ubuntu seems to set up a mini
grub.cfg within the EFI System Partition (ESP for short) that just points GRUB2 to the actual configuration file in
/boot i.e. on a different filesystem. RedHat seems to put the actual GRUB configuration into ESP.
The contents of the actual
grubx64.efi file can also vary between distributions, because it is produced using
grub-mkimage. It includes:
- the GRUB core image
- a number of GRUB modules: at minimum, the modules needed to access the filesystem where other GRUB modules are stored (typically
/boot/grub/x86_64-efi on Debian), but on UEFI systems, it is possible to include all the modules into the
- information on the initial GRUB root filesystem and
prefix (i.e. where GRUB looks for the GRUB module directory and configuration file). On UEFI GRUB, this is typically
/EFI/<name of distribution> to refer to the directory on the ESP GRUB is installed into.
- optionally, an embedded GRUB configuration file
- optionally, a memdisk image file
- optionally, a public key/certificate file for checking signatures on GRUB modules and other files (for implementing a Secure Boot-like check on systems with no Secure Boot functionality available)
The modularity of GRUB is the result of its origin on PCs with MBR-style boot, which required the GRUB to fit in the unused space between the MBR and the beginning of the first partition. Depending on partitioning, that space can be quite small. In UEFI the size limitations are far less strict, but the module mechanism is still available if needed.
Secure Boot will prevent GRUB from loading executable code from files that are not properly signed and using the Windows PE32 binary format. GRUB modules use Unix-style ELF binary format instead, so when Secure Boot is in use, all the needed modules need to be packed into the main
grubx64.efi file so that there will be no need to load separate executable modules. The Linux kernel can have a built-in EFI stub that makes it effectively a PE32 binary file, so it won't have this problem when properly signed.
The Secure Boot shim bootloader
shimx64.efi is signed by Microsoft, so it will be acceptable by default by basically all Secure Boot implementations, and on load, it will add one or two more public keys to the Secure Boot allowed list: the distribution's key, and optionally the MOK key generated for the system owner. This will allow the use of Linux and customized kernels, even if the system vendor will not include Linux distributions' public keys to their Secure Boot implementation and the firmware won't allow the user to edit the firmware-based list of allowed Secure Boot keys.
(The shim must not accept entirely unsigned binaries for execution, for then it would become a "Secure Boot circumvention device" and Microsoft and any other Secure Boot signers should refuse to sign it.)
Some Secure Boot systems will stop the boot process and display a warning message if you're trying to use a bootloader that has no valid Secure Boot signature. Others will just ignore the invalid bootloader and proceed to the next boot option. If your system has Secure Boot enabled and has no other valid boot sources, this might be the cause of the cycling you're seeing: you might be trying to load a version of GRUB that is intended for UEFI with Secure Boot disabled.
Without knowing the name and version of the Linux distribution you're using, and the make and model of your system or motherboard, it will be hard to give any more detailed answers.