In the past, before fallback cared about TPMs, it would always chain-load the entry it had created, but to better support TPMs it now reboots the system if a TPM is present. Due to some firmware implementations overriding any changes made outside of the firmware, the system may end-up in a reboot loop of BOOTX64.EFI, as already reported by @lcp on #128.

This problem is currently addressed by commit a5db51a, which presents a screen warning the user the system is about to reboot, with a countdown, allowing them to tell the system to keep booting instead. While this solution works (and thanks @lcp for implementing it!), it has a few shortcomings:

1. It makes an otherwise glitch-free boot process not smooth anymore;
2. The message presented is not accessible / potentially scary for non-technical users: if they press a key to interrupt the boot process, the meaning of each option is not really clear for users not familiar with how shim / fallback work;
3. The whole experience is made a bit worse by the fact that after selecting "Continue boot" / "Always continue boot", the screen will remain frozen until something else draw on the framebuffer. If GRUB is configured to be quiet for a glitch-free boot, this may last several seconds until the kernel has started and loaded the manufacturer logo from BGRT, which gives the impression that the whole boot process froze.
4. This Boot Option Restoration screen overwrites all the debug information printed before it is displayed, essentially neutering FALLBACK_VERBOSE or SHIM_VERBOSE and making it impossible to enable debug without rebuilding fallback.

Some of these may be seen as non-issues for distributions that use a traditional installer, like Fedora and OpenSuse, where the correct boot entry is created before first boot by the installer and the fallback path is only taken if the boot entry got invalidated somehow (ESP UUID has changed, firmware was factory-reset etc). But for distributions that are distributed as "ready-to-dd" disk image, like Endless OS, fallback is responsible for creating the boot entry on first boot, and then update it on the second boot after the ESP UUID changes during the first-boot re-partitioning process (since we don't want the partitions on every installation to have the same UUIDs). This means users will see this message on the first and second boots in such scenarios.