Below is an in‐depth explanation addressing your questions.

What Is /boot/efi/EFI/BOOT/fbx64.efi?

This file is an EFI executable that serves as a fallback bootloader. In UEFI systems, the firmware will always look in a standard location on the EFI System Partition (ESP) for a bootloader—typically in the folder /EFI/BOOT/ with the file name BOOTX64.EFI. However, many distributions (especially when using Secure Boot) install additional or alternate EFI binaries (for example, a signed shim and/or GRUB2 binary) to support various boot scenarios. In your case, the file named fbx64.efi is likely a fallback or helper binary generated by one of the bootloader packages (such as the shim-x64 or grub2-efi-x64 packages) so that if the UEFI boot manager can’t find a valid boot entry, it will fall back to this executable.

For more background on how UEFI booting works along with fallback bootloaders, see the Rocky Linux Boot Documentation and the GNU GRUB manual on UEFI boot.

Why Might This File Cause a Kernel Upgrade to Fail?

During a kernel upgrade on a UEFI system, the upgrade process does more than just replace kernel images. It also:

  1. Regenerates the initramfs
    The new initramfs is built using post-install scripts that sometimes re-read and reconfigure boot parameters.

  2. Re-runs Bootloader Configuration Updates
    Packages like grub2-efi-x64 and shim-x64 include post-install scripts that update EFI boot entries and copy updated EFI binaries to the ESP. This process typically involves creating—or even regenerating—a fallback bootloader file.

If there’s an unexpected or stale fallback file (in this case, fbx64.efi) present, the update process may encounter one or more of the following problems:

  • File Mismatch or Corruption:
    If the regenerated file doesn’t match what the post-install scripts expect (for example, if an old version or differently signed binary remains), this may cause the bootloader update step to fail.

  • Permission or Overwrite Issues:
    Although a FAT32 ESP doesn’t really support Unix permissions, the way the file shows (-rwx------) reflects the mount options or how the updater writes the file. If the update scripts find the file “locked” or in an unexpected state, they could error out.

  • Bootloader Chain Interference:
    With Secure Boot enabled, it is crucial that the chain of trust is preserved. A fallback file that isn’t updated correctly might be “picked up” by the firmware but fail the signature check, rendering the system unbootable.

Your observation that deleting the file before reboot “works around” the issue supports the notion that this fallback file, when present and left over from an earlier generation, interferes with a smooth bootloader update.

For a discussion on similar issues with shim and GRUB updates on Rocky‑ or CentOS‑based systems, see this GitHub issue on Rocky Tools .

Are Your Initial Thoughts Accurate?

Yes, your reasoning is on target. Although kernel upgrades themselves (i.e., the kernel image and modules) don’t change dramatically, the upgrade transaction often bundles updates to related bootloader components such as:

  • GRUB2 EFI:
    Even if the kernel version differences are minor, a GRUB2 update can retrigger bootloader reinstallation/rehook procedures.

  • Shim Updates:
    With Secure Boot enabled, any update to the shim (the first-stage bootloader that “bridges” between the firmware and signed binaries) might trigger a re-copy to the ESP.

When these post-install scripts run, they may check for existing files in the /boot/efi/EFI/BOOT/ directory and decide either to overwrite them or fail if something is “amiss.” If the update logic doesn’t correctly handle the preexisting fbx64.efi, then you may see an error preventing a complete update. Logs (such as /var/log/dnf.log or the kernel install logs) often reveal messages that point at the EFI binary update step as the error source.

To verify which script is handling this, inspect the scripts embedded in the RPMs; e.g., run:

rpm -q --scripts grub2-efi-x64
rpm -q --scripts shim-x64

This can help you pinpoint where (and why) the file is being regenerated .

Package Differences and Verifying the Regeneration Process

From your RPM query outputs, the versions of kernel, shim, and GRUB-related packages are consistent between healthy and problematic systems. This suggests that the root of the problem isn’t a version mismatch but rather how an existing fallback file is handled by the bootloader’s post-installation scripts.

To further verify the regeneration behaviour, you can:

  • Check Logs:
    Look in the /var/log/dnf.log (or /var/log/yum.log) for lines related to “EFIx64” or similar terms that indicate file operations on /boot/efi/EFI/BOOT/.

  • Review Post-Install Scripts:
    As mentioned above, see if either the shim-x64 or grub2-efi-x64 package scripts reference copying or renaming a file to fbx64.efi.

  • EFI Boot Manager Entries:
    Use tools like efibootmgr -v (as you already did) to review which files the EFI firmware is set to load. Notice that your boot entries point to /EFI/BOOT/BOOTX64.EFI as the primary loader and do not reference fbx64.efi. This discrepancy can be an indication that the fallback file is not meant to be the primary boot loader, and its presence might confuse update scripts.

For more on EFI boot entry management, consult the man page for efibootmgr.

In Summary

  • Role: /boot/efi/EFI/BOOT/fbx64.efi is a fallback UEFI bootloader binary (likely a copy or alternate version of the signed bootloader) meant to be used by the firmware if other boot entries fail.
  • Issue: During kernel upgrades, scripts for regenerating the initramfs and updating the EFI bootloader (via GRUB2 and shim updates) may encounter an incompatible or stale fallback file. Mismanagement of this file (for example, if it isn’t overwritten correctly or its presence violates expected conditions) can cause the upgrade process to abort, leaving the system unbootable.
  • Verification: Inspect RPM post-install scripts with rpm -q --scripts, examine system logs for EFI update messages, and review EFI boot entries via efibootmgr -v to verify how and why the file is being regenerated.
  • References:

By narrowing down the update process (and checking the post-install scripts for GRUB and shim), you should be able to determine if the file is being regenerated as part of a fallback mechanism and why its state might be preventing a smooth upgrade.

I hope this detailed explanation helps clarify the situation. If you’d like to dive further into specific log details or explore modifications in post-install behaviour, we can discuss additional troubleshooting steps.

Updated: