About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
On a UEFI server, boot diagnosis should separate three layers: how firmware selects a loader, whether that loader exists on the EFI system partition (ESP), and whether Secure Boot policy accepts the boot chain. Selection may use a stored boot entry or a supported fallback path. Firmware variables are outside an ordinary disk image; the ESP and boot-component metadata are on disk. Boot entries live in the firmware's non-volatile variables, which the efibootmgr manual describes as the UEFI Boot Manager configuration. Secure Boot revocations also live in firmware variables, and shim can refuse a boot loader that the revocation data marks as vulnerable.
So when a restored or re-disked server stops at a firmware menu, a "no bootable device" message or a Secure Boot violation, the files may be perfectly intact. The fault may involve firmware state that the backup never held, or boot files whose signatures or generations are no longer accepted.
Why it matters
Bare-metal recovery plans often focus on the filesystem: restore the root, /boot and data, fix the identifiers in /etc/fstab, and rebuild the initramfs. Those steps are necessary, but on UEFI they are not enough. Three cases come up repeatedly:
- A replacement server or motherboard has its own firmware variables. Entries the old server held, including the one that started the Linux loader, do not exist on the new one.
- A newly partitioned replacement disk can get new partition identifiers. An existing firmware entry that names the old ESP by its identifier no longer matches anything. (our reading of the HD() path below)
- Rescue or installation media may be older than the server's Secure Boot revocation state. When recovery is urgent, the media you reach for may be the one that will not start.
Each case needs a different decision. Identifying the failing layer can avoid unnecessary writes to the ESP and preserve evidence about the original failure.
How it works
Boot entries live in firmware
The efibootmgr manual describes the tool as "a userspace application used to modify the UEFI Boot Manager", one that can "create and destroy boot entries, change the boot order, change the next running boot option, and more". It notes that the tool needs kernel access to EFI non-volatile variables. Its example output shows the variables involved:
Boot####entries, each with a label, an active flag and a device path.BootOrder, where "the boot manager tries to boot the first active entry in this list. If unsuccessful, it tries the next entry, and so on."BootNext, a one-time override that "supersedes BootOrder for one boot only, and is deleted by the boot manager after first use".BootCurrent, the entry used for the current boot.
By default, the manual says, efibootmgr creates entries with "a hard disk based HD() abbreviated path". Its example entry reads HD(Part1,Sig00112233). In UEFI device paths, the HD() node identifies a partition by its number and a signature, which on GPT disks is the partition's unique GUID. Repartitioning can create a new partition GUID, while an image restore may preserve the old one. Compare the actual restored identifier and device path with the entry before deciding it is stale. (our reading, consistent with the manual's example; the UEFI specification itself was not opened for this article)
Because these variables are in firmware, an ordinary disk image or filesystem backup does not capture them. Configuration management may record and recreate entries explicitly, but copying files alone does not do so. They have to be recreated on the hardware you restore to, either by your distribution's boot loader installation step or by efibootmgr directly.
The EFI system partition and the fallback path
The ESP is a small FAT-formatted partition holding loader files. The shim fallback notes show the layout an installed system normally has on x86-64:
\EFI\BOOT\BOOTX64.EFI, a copy of shim, plusfallback.efi, at the removable-media path.\EFI\<distribution>\shim.efi,grubx64.efi,grub.cfgand aBOOT.CSVfile, in the distribution's own directory.
Normally a boot entry starts \EFI\<distribution>\shim.efi directly, and fallback is not involved. The same document explains what happens when entries are lost: "if the boot variables are missing or corrupted, the firmware will eventually try to boot the hard disk as removable media". It then starts \EFI\BOOT\BOOTX64.EFI, which finds fallback.efi and runs it. Fallback "will look for every directory in \EFI\ with a BOOT${ARCH}.CSV in it, or BOOT.CSV if that's not found", and "create new boot variables from what it finds. Then it'll try to boot one of them."
This mechanism is your friend in a recovery. If the ESP was restored completely, with the removable-media path, fallback.efi and the distribution's BOOT.CSV, a new server with no boot entries may repair itself on first boot. If the backup skipped the ESP, or restored only the distribution directory, there is nothing at the fallback path for the firmware to find.
Two practical cautions follow. Many file-level backups and some restore tools handle a FAT partition mounted under /boot/efi differently from Linux filesystems, or leave it out entirely; check that yours captures it. And on servers with mirrored system disks, there may be a separate ESP on each disk, because firmware reads the ESP as a plain FAT partition and does not assemble Linux RAID. (Some installations mirror the ESP with RAID metadata stored at the end of the device so that firmware still sees a FAT filesystem; that has its own caveats and is outside this article.) Keep every copy in step and give each its own firmware entry. (our reading and recommendation)
Shim and Secure Boot
Shim is "a trivial EFI application that, when run, attempts to open and execute another application." It first tries the standard UEFI loading calls; if those fail "because Secure Boot is enabled and the binary is not signed with an appropriate key", shim validates the binary against its built-in certificate and runs it only "if the binary or signing key are not forbidden". Shim also provides a protocol so that the second-stage loader, normally GRUB, can validate the kernel the same way.
That gives Secure Boot failures on Linux three possible sources:
- The firmware rejects shim itself, for example because its hash or signing certificate is in the firmware's revocation database (
dbx). - Shim rejects GRUB or another second stage, because its signature or SBAT metadata fails shim's checks.
- GRUB or shim rejects the kernel, for example a locally built kernel without a trusted signature.
What SBAT is and why old media stop working
SBAT.md, in the shim repository, explains the problem SBAT solves. Revoking boot code by image hash is inefficient: after the "BootHole" incident (CVE-2020-10713), "3 certificates and 150 image hashes were added to the UEFI Secure Boot revocation database dbx", consuming "10kB of the 32kB, or roughly one third, of revocation storage typically available". SBAT instead records generation numbers. Each boot component carries a .sbat section with its generation; a firmware variable named SbatLevel records the minimum acceptable generation, and a component below it is refused.
SbatLevel_Variable.txt is, in its own words, "the single source for SbatLevel revocations". At review on 13 November 2026 it lists a series of revocation payloads that raise the minimum GRUB generation step by step, from grub,2 for vulnerabilities disclosed in 2022 to grub,7 in an entry dated September 2026. It also notes that on systems running shim, "shim will manage these revocations", and that systems that never run shim, "primarily Windows", can apply SBAT revocations themselves by setting the variable.
The consequence for recovery is direct. Once a server's firmware holds a raised SbatLevel, older shim or GRUB builds that carry a lower generation are refused, wherever they come from. That includes an older installation ISO, a vendor rescue image built years ago, or a backup tool's boot media that has not been rebuilt. A server whose installed system is current may boot normally, then refuse the rescue USB stick you use when its disk fails.
The mokutil manual documents the related controls. --list-sbat-revocations lists the revocations "active in the Secure Boot Advanced Targeting (SBAT) store". --set-sbat-policy chooses between latest and automatic (the previous generation) enforcement. It also states: "If UEFI Secure Boot is disabled, shim automatically deletes the SBAT revocations." That means switching Secure Boot off and on is not a neutral act: booting shim with Secure Boot disabled can change revocation state as well as bypass signature checking.
What to choose and why
Capture what the backup cannot hold
Record, outside the server, the output of efibootmgr with verbose detail, the ESP's partition layout, and whether Secure Boot is enabled. Note which shim and GRUB versions are installed and the current SBAT revocation list from mokutil --list-sbat-revocations. These take seconds to collect during normal operation and save guesswork later.
Check explicitly that your file-level backup includes the whole ESP, not only the distribution's directory. Image-level backups of the system disk normally carry it, but confirm that a restore to a different-sized disk recreates it with the right partition type.
Keep rescue media current
Treat recovery boot media as software with a support life. Rebuild or redownload it when your distribution publishes new signed shim and GRUB packages, and test that it starts on a Secure Boot-enabled server of each model you run. An ISO that worked at commissioning may be refused after a later revocation update.
When a restored server stops at the firmware
Work through the layers in order, changing one thing at a time:
- Is Secure Boot refusing something? Firmware messages about a security violation, or shim messages about SBAT data, point to layer three. Do not start reinstalling GRUB.
- Are there boot entries at all? Most firmware setup screens list them, and from a rescue environment
efibootmgrshowsBootOrderand each entry's device path. Missing entries, or entries pointing at a partition that no longer exists, are layer one. - Is the ESP present and complete? Check that the partition exists with the EFI system partition type, that the distribution's directory contains shim and GRUB, and that the removable-media path holds a loader.
For missing entries, the least invasive repair is often to choose the restored disk from the firmware's one-time boot menu, let fallback recreate entries if it is present, or use the distribution's supported boot loader installation procedure from a rescue environment. Manual entry creation changes firmware state and needs an exact disk, partition and loader path. Prefer the distribution-supported procedure with a recorded rollback plan. Deleting an entry removes the stored record, although a correctly documented entry can usually be recreated.
Secure Boot is a decision, not a workaround
Turning Secure Boot off may let an old rescue image start, but it changes the server's security state, and the documented shim behaviour can clear SBAT revocations when shim runs with Secure Boot disabled. If you must do it to recover, record that you did, and plan the step to re-enable it once current signed components are installed. Use current, signed media where you can rather than lowering protection.
Mirrored boot disks
On servers whose root is on software RAID 1, make sure there is an ESP on each disk with identical contents and a firmware entry for each. When one disk is replaced, recreate its ESP and entry as part of the disk replacement, not later. Otherwise the server boots only until the remaining original disk fails.
Risks and limits
- Firmware differs. How firmware behaves with no boot entries, whether it tries the removable-media path on internal disks, and how it presents Secure Boot errors vary by vendor. Read your server vendor's documentation.
- Revocation state normally moves forward. SBAT.md describes protections against downgrading revocations; the documented exception involving shim booted with Secure Boot disabled is discussed above. Plan on moving media forward, not on rolling the server back.
- Not every distribution uses shim and GRUB. Some systems use systemd-boot, which bootctl manages, or unified kernel images. The firmware-entry and ESP points still apply; the shim-specific detail may not.
- Commands are documented, not tested. Nothing in this article was run. Boot entry changes and boot loader reinstalls write to firmware or the ESP; rehearse them on a non-production server of the same model.
- x86-64 names. File names such as
BOOTX64.EFIandgrubx64.efiare architecture-specific.
Sources
- efibootmgr(8) manual source, rhboot/efibootmgr main branch: https://raw.githubusercontent.com/rhboot/efibootmgr/main/src/efibootmgr.8.in
- shim README: https://raw.githubusercontent.com/rhboot/shim/main/README.md
- shim README.fallback: https://raw.githubusercontent.com/rhboot/shim/main/README.fallback
- shim SBAT.md: https://raw.githubusercontent.com/rhboot/shim/main/SBAT.md
- shim SbatLevel_Variable.txt: https://raw.githubusercontent.com/rhboot/shim/main/SbatLevel_Variable.txt
- mokutil(1) manual source: https://raw.githubusercontent.com/lcp/mokutil/master/man/mokutil.1
- bootctl(1), systemd 262: https://man7.org/linux/man-pages/man1/bootctl.1.html
This article was originally published on .