Debian 13: UEFI entry vanished — restore boot with efibootmgr in minutes

What actually broke when the UEFI entry vanished

UEFI booting is a three-legged stool:

1. Firmware NVRAM entries (Boot#### variables) that point to an EFI executable on a disk.
2. The EFI System Partition (ESP), a FAT32 partition that holds .efi binaries and configs.
3. A bootloader chain (often shimx64.efi → grubx64.efi → your kernel).

When you lose a boot entry, you usually lost only leg #1. The files on disk still exist. The firmware just “forgot” where Debian lives, or decided not to care anymore.

Why does this happen? Common causes include:

• Firmware resets after power loss, battery issues, or a BIOS/UEFI update.
• NVRAM storage is full or corrupted (yes, that’s a thing).
• Another OS installer “helpfully” rewrites BootOrder.
• Some platforms silently delete entries that point to disks that were temporarily absent (USB/NVMe hot swap, RAID controller drama).
• Secure Boot toggles changing the preferred path (shim vs direct GRUB) and making your entry look “wrong” to the firmware.

The good news: this is fixable quickly and safely. The bad news: you have to be precise, because UEFI will happily let you create a perfect boot entry pointing to the wrong disk, which is basically the same as doing nothing but with more confidence.

Interesting facts and a little history (because it matters)

• UEFI replaced BIOS not just for prettier menus, but to standardize booting beyond the 2 TB/MBR constraints and provide a programmable pre-boot environment.
• The EFI System Partition is FAT on purpose: firmware vendors needed something universally readable without shipping a filesystem zoo.
• UEFI boot entries live in NVRAM, which is typically backed by SPI flash on the motherboard, not on your disk. That’s why reinstalling GRUB doesn’t always fix a missing entry.
• There is a standardized “fallback” path: \EFI\BOOT\BOOTX64.EFI on x86_64. If firmware can’t find entries, it may try this. Some vendors rely on it more than they admit.
• Secure Boot doesn’t “secure Linux”; it secures which binaries can run in pre-boot. The OS can still be misconfigured or compromised after boot. It’s a chain-of-trust tool, not a magic charm.
• efibootmgr speaks to NVRAM via efivarfs (usually mounted at /sys/firmware/efi/efivars). If you booted in legacy mode, it can’t manage UEFI variables, because they’re not available.
• Some firmware has tiny NVRAM quotas, and vendors sometimes store crash logs or diagnostics in the same pool. Your boot entries can lose a cage match against “helpful telemetry.”
• GRUB’s UEFI executable isn’t the config. The config is typically /boot/grub/grub.cfg on your Linux filesystem, while the EFI binary on the ESP is just the loader stub.
• Debian’s signed boot chain commonly uses shimx64.efi to satisfy Secure Boot while allowing GRUB to load, with Debian-controlled signing keys rather than requiring you to build your own chain.

Fast diagnosis playbook: find the bottleneck in 5 minutes

First: are you actually booted in UEFI mode?

If you’re in a rescue environment (live ISO, PXE rescue, remote hands with a crash cart), confirm whether the kernel sees UEFI variables. If not, stop and reboot the rescue media in UEFI mode. Nothing else will stick.

Second: do you have an ESP and does it contain Debian loaders?

Find the ESP, mount it, and look for \EFI\debian\. If the files are missing, the issue is on disk: reinstall grub-efi-amd64 (and possibly shim-signed) and regenerate.

Third: is NVRAM writable and not full?

If efibootmgr fails to create entries, your firmware may be blocking writes, the variables filesystem may not be mounted, Secure Boot may be restricting variable updates (less common), or NVRAM may be full/corrupted. In that case, switch tactics: use the fallback path EFI/BOOT/BOOTX64.EFI, or clean up NVRAM entries if you can.

Fourth: validate BootOrder and the actual device path

Even when you create an entry, it might point to the wrong disk/partition if you guessed. Confirm the disk and partition numbers. Then set BootOrder deliberately. “Let the firmware sort it out” is how you end up watching a server boot Windows again.

Practical tasks: commands, outputs, decisions (the working playbook)

These are the tasks I actually run. Each has three parts: the command, what output means, and the decision you make. Run them from a Debian rescue shell if the system won’t boot. You can do it from an installed system too, but the missing-entry scenario usually means you can’t.

Task 1: Confirm UEFI mode is available

cr0x@server:~$ ls -ld /sys/firmware/efi
drwxr-xr-x 5 root root 0 Dec 28 09:14 /sys/firmware/efi

Meaning: If the directory exists, you are booted in UEFI mode. If it’s missing, you’re in legacy/CSM mode.

Decision: If missing, reboot the rescue media and pick the UEFI boot option in the firmware menu. Do not proceed with efibootmgr until this is present.

Task 2: Confirm efivarfs is mounted (NVRAM access)

cr0x@server:~$ mount | grep -E 'efivars|efi'
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)

Meaning: efivarfs is the kernel interface to UEFI variables.

Decision: If not mounted, mount it (Task 3) or fix why your rescue kernel doesn’t support it.

Task 3: Mount efivarfs if needed

cr0x@server:~$ sudo mount -t efivarfs efivarfs /sys/firmware/efi/efivars
cr0x@server:~$ mount | grep efivars
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)

Meaning: Without this, efibootmgr may show “EFI variables are not supported” or fail to write.

Decision: If mount fails, you may be in legacy mode or running a kernel without EFI variable support.

Task 4: Inspect current BootOrder and entries

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0007
Timeout: 1 seconds
BootOrder: 0007,0001,0002
Boot0001* UEFI: Built-in EFI Shell	HD(1,GPT,8f2c0f9f-6c7f-4f84-9b8c-9f5f3b2f0b0a,0x800,0x32000)/File(\EFI\tools\Shell.efi)
Boot0002* UEFI PXEv4 (MAC:001122334455)	PciRoot(0x0)/Pci(0x1,0x1)/MAC(001122334455,0)
Boot0007* debian	HD(1,GPT,2a1f4c8e-3d1c-4c2c-b7a1-1d6b1c7f2a5f,0x800,0x200000)/File(\EFI\debian\shimx64.efi)

Meaning: You can see whether a “debian” entry exists, and what file path it points at.

Decision: If the Debian entry is missing, you’ll recreate it. If it exists but points to a non-existent file, fix the ESP contents or correct the path.

Task 5: Find the EFI System Partition

cr0x@server:~$ lsblk -o NAME,SIZE,FSTYPE,PARTTYPE,PARTLABEL,MOUNTPOINTS
NAME        SIZE FSTYPE PARTTYPE                             PARTLABEL     MOUNTPOINTS
nvme0n1   953.9G
├─nvme0n1p1   512M vfat   c12a7328-f81f-11d2-ba4b-00a0c93ec93b EFI System
├─nvme0n1p2     2G ext4   0fc63daf-8483-4772-8e79-3d69d8477de4 boot
└─nvme0n1p3 951.4G crypto_LUKS 0fc63daf-8483-4772-8e79-3d69d8477de4 root

Meaning: ESP is typically vfat with GPT type c12a7328-f81f-11d2-ba4b-00a0c93ec93b.

Decision: Note the device (here /dev/nvme0n1p1). If you don’t see an ESP, you might be in legacy boot, or the disk layout is wrong (or you’re on weird vendor hardware).

Task 6: Mount the ESP and inspect contents

cr0x@server:~$ sudo mkdir -p /mnt/esp
cr0x@server:~$ sudo mount -t vfat /dev/nvme0n1p1 /mnt/esp
cr0x@server:~$ sudo find /mnt/esp/EFI -maxdepth 2 -type f -name '*.efi' | sort
/mnt/esp/EFI/BOOT/BOOTX64.EFI
/mnt/esp/EFI/debian/grubx64.efi
/mnt/esp/EFI/debian/shimx64.efi

Meaning: If you see Debian’s EFI binaries, the disk side is fine and the NVRAM entry is the likely problem.

Decision: If /mnt/esp/EFI/debian/ is missing or empty, you need to reinstall GRUB/shim to the ESP.

Task 7: Verify the loader file the firmware entry points to

cr0x@server:~$ sudo test -f /mnt/esp/EFI/debian/shimx64.efi && echo "shim present"
shim present
cr0x@server:~$ sudo test -f /mnt/esp/EFI/debian/grubx64.efi && echo "grub present"
grub present

Meaning: Confirms the exact file exists. This avoids the classic “entry points to grubx64.efi but only shim exists” mismatch.

Decision: If missing, reinstall packages and rerun grub-install (Task 10–11).

Task 8: Check if the ESP filesystem is unhappy

cr0x@server:~$ sudo umount /mnt/esp
cr0x@server:~$ sudo fsck.vfat -n /dev/nvme0n1p1
fsck.fat 4.2 (2021-01-31)
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "mkfs.fat"
Media byte 0xf8 (hard disk)
...
/dev/nvme0n1p1: 12 files, 1024/130560 clusters

Meaning: The -n run is read-only. You’re checking for obvious corruption without modifying anything.

Decision: If it reports errors, schedule a proper repair (remove -n) and expect to reinstall boot files afterward if they were damaged.

Task 9: Check kernel logs for EFI variable write failures

cr0x@server:~$ dmesg | grep -i -E 'efivars|efi:|secure|nvram' | tail -n 20
[    0.214321] efi: EFI v2.80 by American Megatrends
[    0.214322] efi: ESRT=0xb7f3c000 ACPI=0x9b5f4000 ACPI 2.0=0x9b5f4000 SMBIOS=0xb7f2e000
[    1.902114] efivars: Registered efivars operations

Meaning: You want to see normal EFI initialization. If you see “efivars: write error” or “no space left on device,” that’s your culprit.

Decision: If there are write errors, plan for fallback path boot or cleanup of NVRAM entries (Task 14–15).

Task 10: Prepare a chroot (when repairing from rescue)

cr0x@server:~$ sudo cryptsetup open /dev/nvme0n1p3 cryptroot
Enter passphrase for /dev/nvme0n1p3:
cr0x@server:~$ sudo vgchange -ay
  2 logical volume(s) in volume group "vg0" now active
cr0x@server:~$ sudo mount /dev/vg0/root /mnt
cr0x@server:~$ sudo mount /dev/nvme0n1p2 /mnt/boot
cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/boot/efi

Meaning: Your installed system’s root, /boot, and ESP are mounted in the standard places for Debian.

Decision: If /boot/efi isn’t mounted in the chroot, grub-install can write to the wrong place and you’ll “fix” nothing.

Task 11: Bind-mount system directories and chroot

cr0x@server:~$ for d in /dev /dev/pts /proc /sys /run; do sudo mount --bind $d /mnt$d; done
cr0x@server:~$ sudo chroot /mnt /bin/bash
root@server:/# mount | grep -E '/boot/efi|efivars'
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
/sys/firmware/efi/efivars on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)

Meaning: The chroot sees the real ESP and efivars. Good. You’re operating on the real system state.

Decision: If efivars isn’t visible in chroot, bind-mount /sys correctly and confirm you booted the rescue environment in UEFI mode.

Task 12: Reinstall Debian’s UEFI boot packages (signed chain)

cr0x@server:/# apt-get update
Hit:1 cdrom://Debian GNU/Linux 13.0.0 _Trixie_ - Official amd64 NETINST 20251201-10:22  trixie InRelease
Reading package lists... Done
cr0x@server:/# apt-get install --reinstall grub-efi-amd64 shim-signed
Reading package lists... Done
Building dependency tree... Done
0 upgraded, 0 newly installed, 2 reinstalled, 0 to remove and 0 not upgraded.
Setting up shim-signed (1.60+15.8-1) ...
Setting up grub-efi-amd64 (2.12-2) ...

Meaning: You’re restoring known-good EFI binaries and scripts. Debian packaging usually also triggers appropriate postinst steps.

Decision: If Secure Boot is disabled and you don’t want shim, you can skip it. But in mixed fleets, reinstalling shim avoids surprises later.

Joke #1: UEFI NVRAM is like a tiny closet—everything fits until you need one more coat, and then nothing fits and everyone blames the coat.

Task 13: Run grub-install explicitly (when packages weren’t enough)

cr0x@server:/# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=debian --recheck
Installing for x86_64-efi platform.
Installation finished. No error reported.

Meaning: This writes the loader to the ESP under /boot/efi/EFI/debian/, and may also create an NVRAM entry.

Decision: If it errors with “cannot find EFI directory,” your ESP isn’t mounted where you think it is. Stop and fix mounts.

Task 14: Regenerate GRUB config (sanity, not superstition)

cr0x@server:/# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.12.0-1-amd64
Found initrd image: /boot/initrd.img-6.12.0-1-amd64
done

Meaning: This validates that your installed system sees kernels and can generate a coherent menu.

Decision: If it can’t find kernels, you’re solving the wrong problem: you may have a broken /boot mount or missing kernel packages.

Task 15: Create (or recreate) the UEFI boot entry with efibootmgr

cr0x@server:/# efibootmgr -c -d /dev/nvme0n1 -p 1 -L "debian" -l '\EFI\debian\shimx64.efi'
BootCurrent: 0007
BootOrder: 0007,0001,0002
Boot0008* debian	HD(1,GPT,2a1f4c8e-3d1c-4c2c-b7a1-1d6b1c7f2a5f,0x800,0x200000)/File(\EFI\debian\shimx64.efi)

Meaning: This writes a new Boot#### variable pointing at the loader. Note the disk (-d) and partition number (-p) are the whole game.

Decision: If it succeeds, set BootOrder to prefer it (Task 16). If it fails with “No space left on device,” go to NVRAM cleanup or fallback boot (later sections).

Task 16: Put Debian first in BootOrder (be bossy)

cr0x@server:/# efibootmgr
BootCurrent: 0007
BootOrder: 0007,0001,0002,0008
Boot0008* debian	HD(1,GPT,2a1f4c8e-3d1c-4c2c-b7a1-1d6b1c7f2a5f,0x800,0x200000)/File(\EFI\debian\shimx64.efi)
cr0x@server:/# efibootmgr -o 0008,0007,0001,0002
BootOrder: 0008,0007,0001,0002

Meaning: You explicitly order boot targets. Otherwise firmware may keep booting PXE or a shell first.

Decision: Always set BootOrder deliberately in servers. Human-friendly boot menus are not a reliability strategy.

Task 17: One-time boot into the new entry (safe test)

cr0x@server:/# efibootmgr -n 0008
BootNext: 0008

Meaning: BootNext sets a one-time boot. It’s a low-risk way to test without permanently rearranging everything.

Decision: Use BootNext when you’re on remote hands and want the system to return to a known default if your change fails.

Task 18: Verify the fallback loader exists (insurance)

cr0x@server:/# ls -l /boot/efi/EFI/BOOT/BOOTX64.EFI
-rwx------ 1 root root 1249280 Dec 28 09:26 /boot/efi/EFI/BOOT/BOOTX64.EFI

Meaning: Some platforms will boot this automatically when NVRAM entries are missing. Others won’t. But having it is still useful when you’re improvising.

Decision: If it’s missing, consider creating it (fallback section) after you restore the main entry.

Task 19: Exit chroot cleanly and reboot

cr0x@server:/# exit
cr0x@server:~$ sudo umount -R /mnt
cr0x@server:~$ sudo reboot

Meaning: You’re flushing writes and removing mounts to avoid dirty state. Especially important if you ran filesystem checks or touched the ESP.

Decision: If reboot lands in firmware again, don’t panic—go back to Task 4 and confirm the entry still exists. If it vanished again, you likely have firmware/NVRAM issues or write-protection.

Recreate the Debian UEFI entry with efibootmgr (the surgical fix)

The command that matters most is:

• -c create a new entry
• -d the disk device (not a partition)
• -p the partition number of the ESP on that disk
• -L label shown in firmware menus
• -l loader path inside the ESP, using backslashes and an absolute path from the ESP root

Two patterns I use:

Pattern A: Secure Boot compatible (shim)

cr0x@server:~$ sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -L "debian" -l '\EFI\debian\shimx64.efi'
Boot0009* debian	HD(1,GPT,2a1f4c8e-3d1c-4c2c-b7a1-1d6b1c7f2a5f,0x800,0x200000)/File(\EFI\debian\shimx64.efi)

Use when: Secure Boot is enabled, or you don’t control the fleet policy and want a boot entry that works regardless.

Pattern B: Direct GRUB (no shim)

cr0x@server:~$ sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -L "debian (grub)" -l '\EFI\debian\grubx64.efi'
Boot0010* debian (grub)	HD(1,GPT,2a1f4c8e-3d1c-4c2c-b7a1-1d6b1c7f2a5f,0x800,0x200000)/File(\EFI\debian\grubx64.efi)

Use when: Secure Boot is off and you want the simplest chain. It can also be useful for debugging shim-related failures.

When efibootmgr “works” but boot still fails

UEFI entries can be misleadingly correct. The firmware stores a device path that includes a GPT partition GUID. If you cloned disks, restored images, or swapped hardware, the GUID can change. Sometimes firmware entries continue to point at the old GUID and become dead.

In practice: if your entry shows an HD() device path with a GUID that doesn’t match the current ESP’s PARTUUID, recreate it using efibootmgr rather than trying to edit it.

One quote worth keeping on the wall (paraphrased idea)

Paraphrased idea: Gene Kranz emphasized that in failure response you stay calm, work the problem, and avoid panic-driven improvisation.

Use the fallback path: BOOTX64.EFI (when NVRAM is hostile)

Sometimes NVRAM won’t keep entries. You create one, reboot, and it disappears like a guilty commit. Or efibootmgr returns “No space left on device.” Or the platform blocks variable writes unless you use vendor tooling.

This is where the UEFI fallback path earns its keep: \EFI\BOOT\BOOTX64.EFI for x86_64. Many firmwares will boot it when entries are missing, or you can manually select the disk’s “UEFI: device” option and it will pick up the fallback.

Make Debian bootable via fallback

If you already have Debian’s shim on the ESP, copy it into the fallback location. Prefer shim when Secure Boot might be on.

cr0x@server:~$ sudo mount -t vfat /dev/nvme0n1p1 /mnt/esp
cr0x@server:~$ sudo mkdir -p /mnt/esp/EFI/BOOT
cr0x@server:~$ sudo cp -a /mnt/esp/EFI/debian/shimx64.efi /mnt/esp/EFI/BOOT/BOOTX64.EFI
cr0x@server:~$ sudo sync
cr0x@server:~$ sudo ls -l /mnt/esp/EFI/BOOT/BOOTX64.EFI
-rwx------ 1 root root 1249280 Dec 28 10:11 /mnt/esp/EFI/BOOT/BOOTX64.EFI

Meaning: You now have a bootable fallback loader even if NVRAM is wiped.

Decision: Use this when you suspect firmware is deleting entries, when NVRAM is full, or when you’re in a remote site and want the simplest “boots even if forgetful” safety net.

What about configuration when using fallback?

Shim/GRUB still needs to find GRUB config and the Linux filesystem. Debian’s GRUB typically embeds logic to find /boot/grub. If you have exotic layouts (mdadm, LUKS, multiple ESPs), test. Don’t assume.

Joke #2: The UEFI fallback path is like leaving a spare key under the doormat—except the doormat is standardized by a committee.

Secure Boot reality: shim, signed GRUB, and avoiding self-inflicted pain

Secure Boot changes the failure modes. With Secure Boot enabled:

• Firmware will only execute EFI binaries signed by trusted keys.
• Debian typically uses shimx64.efi signed in a way firmware accepts (via common trust anchors), then shim validates GRUB.
• If you point a boot entry directly at an unsigned grubx64.efi, you may get an immediate failure that looks like “it didn’t boot” with no logs.

Practical advice:

• If you don’t know the Secure Boot state, assume it might be enabled. Create the entry pointing to shim. It’s the lowest-drama default.
• Don’t toggle Secure Boot as a “fix.” That’s not a fix; it’s a policy change. It can also break other hosts if you treat it like a casual reboot option.
• Keep the ESP readable and boring. Some folks try to “optimize” by compressing or deduplicating ESP contents (via weird tools). Don’t. It’s FAT32. Let it be FAT32.

Three corporate mini-stories from the boot trenches

Mini-story 1: The incident caused by a wrong assumption

The team had a small fleet of Debian servers that booted from mirrored NVMe devices. A motherboard firmware update was scheduled during a maintenance window. All looked routine: patch, reboot, verify services, go home.

After the update, a subset of nodes came back to the UEFI shell. The on-call assumed the bootloader had been corrupted by the update process. They reinstalled GRUB from rescue mode, twice, because the first reinstall “couldn’t have failed.” It still didn’t boot. Tempers rose. The shell prompt stared back politely.

The real issue: the firmware update reset NVRAM and also toggled the boot mode preference. The servers now preferred PXE and shell entries, and the Debian entry wasn’t present. Reinstalling GRUB wrote files to the ESP correctly, but nobody recreated the NVRAM entry or fixed BootOrder.

Once someone ran efibootmgr -v and actually looked, the solution was trivial: create the entry pointing to shim and set BootOrder. The lesson wasn’t “firmware updates are bad.” The lesson was: don’t assume “bootloader corruption” when the system isn’t even trying to load your bootloader.

Mini-story 2: The optimization that backfired

A different org wanted “cleaner boot partitions.” They standardized images and trimmed the ESP to a minimum: one loader, one vendor directory, no extras. They also pruned “unused” UEFI entries aggressively as part of provisioning, because some machines arrived with a zoo of factory diagnostics.

Then they added dual-boot developer workstations in the same automation framework. One script, reused everywhere, removed anything not labeled exactly “debian” and re-ordered BootOrder. On paper, neat. In reality, the workstations had Windows using BitLocker and required its boot entry to remain stable.

The next Windows update rewrote its own boot entry and BootOrder (as it tends to do). The automation then ran, removed it, and rearranged things back. Windows recovery kicked in, users hit their helpdesk, and the platform team got a week-long reminder that “standardization” is not the same thing as “deleting things you don’t understand.”

They fixed it by making the script aware of platform roles, leaving non-Linux entries alone unless explicitly told otherwise, and by relying more on the fallback path as a safety valve rather than trying to enforce a single perfect BootOrder everywhere.

Mini-story 3: The boring but correct practice that saved the day

A bank (yes, really) had a policy: every UEFI-booting Linux server must have both a proper NVRAM entry and a maintained fallback loader at \EFI\BOOT\BOOTX64.EFI. They also required the ESP to be part of backup/restore procedures, even though it’s small and feels “not real.”

A site experienced repeated power issues. Several systems returned with NVRAM entries wiped. Normally this becomes a rolling disaster: remote hands, console sessions, manual poking. Instead, the hosts booted via fallback, shim loaded GRUB, and the OS came up. The applications didn’t even notice. The incident ticket was almost anticlimactic.

Later, the team recreated NVRAM entries during daylight hours and found the root cause (firmware plus unstable power). But the immediate business outcome was boring: services stayed up. Boring is the goal.

This is why you do the unsexy work: redundant boot paths, documented recovery commands, and a checklist that doesn’t depend on heroics.

Common mistakes: symptom → root cause → fix

1) Symptom: efibootmgr says “EFI variables are not supported”

Root cause: You booted the rescue environment in legacy/CSM mode, or efivarfs isn’t available.

Fix: Reboot the rescue media in UEFI mode (Task 1). Ensure efivarfs is mounted (Task 2–3).

2) Symptom: Debian entry exists, but it still boots to firmware setup

Root cause: BootOrder doesn’t include it, or it’s after PXE/shell, or firmware is skipping it due to a failed attempt.

Fix: Set BootOrder explicitly (Task 16). Use BootNext to test (Task 17).

3) Symptom: Debian entry points to grubx64.efi, but Secure Boot is enabled and it won’t start

Root cause: Firmware refuses to launch an unsigned loader.

Fix: Point the entry to \EFI\debian\shimx64.efi instead (Task 15, Pattern A). Reinstall shim-signed if needed (Task 12).

4) Symptom: efibootmgr create fails with “No space left on device”

Root cause: NVRAM variable storage is full.

Fix: Delete stale entries (efibootmgr -b #### -B) and retry, or use fallback path (fallback section) if writes remain unreliable.

5) Symptom: efibootmgr works, but entry disappears after reboot

Root cause: Firmware bug, write protection, or settings reset (sometimes due to a failing CMOS battery or aggressive “restore defaults” policies).

Fix: Use fallback path BOOTX64.EFI for resiliency, and schedule hardware/firmware remediation. If possible, update firmware again or disable “OS optimized defaults” features that nuke entries.

6) Symptom: GRUB starts, but kernel not found / drops to rescue

Root cause: This isn’t a missing UEFI entry. It’s a Linux boot config or storage problem: wrong root UUID, missing /boot, LUKS/mdadm misassembly.

Fix: Validate mounts in chroot (Task 10–11), run update-grub (Task 14), confirm initramfs has needed modules, and check /etc/fstab and crypttab.

7) Symptom: Entry points to the right file, file exists, but it still won’t boot

Root cause: ESP is on a disk the firmware can’t read (controller mode change, RAID remap, NVMe namespace changes), or the entry references a stale partition GUID after cloning.

Fix: Recreate entry with correct disk and partition (Task 15). If the controller mode changed (AHCI/RAID), revert or ensure firmware can access the ESP in that mode.

Checklists / step-by-step plan (boring, fast, repeatable)

Checklist A: You have console access and a rescue ISO

1. Boot the rescue ISO in UEFI mode (verify with Task 1).
2. Mount efivarfs if needed (Task 2–3).
3. Inspect NVRAM entries (Task 4). Decide if Debian entry is missing or wrong.
4. Find and mount the ESP (Task 5–6). Confirm loader files exist (Task 7).
5. If loader files are missing, chroot and reinstall (Task 10–14).
6. Create or recreate the boot entry (Task 15).
7. Set BootOrder (Task 16). Optionally set BootNext for a test (Task 17).
8. Reboot and observe.

Checklist B: NVRAM is full or firmware keeps forgetting

1. Confirm the ESP contains Debian’s shim/grub (Task 6–7).
2. Create fallback loader at \EFI\BOOT\BOOTX64.EFI (fallback section).
3. Try to clean NVRAM entries only if you can do so safely (delete obviously stale PXE shells or old OS entries).
4. Schedule firmware remediation: update, reset carefully, replace CMOS battery if applicable, and document the behavior.

Checklist C: Dual-boot or multiple Linux installs

1. Do not delete entries blindly. First list them (Task 4) and map each to an ESP path.
2. Use explicit labels: debian-prod, debian-rescue, windows.
3. Prefer shim-based entries if Secure Boot might be used by any OS.
4. Keep a fallback loader that boots your primary OS, not an installer.

FAQ

1) Why would a UEFI boot entry disappear at all?

Because it’s stored in motherboard NVRAM, not on disk. Firmware updates, resets, power events, or NVRAM quota issues can wipe or prune entries.

2) If the ESP is intact, why doesn’t the machine just find it?

UEFI doesn’t generally “scan and guess” like old BIOS. It follows BootOrder entries. Some firmware will try fallback paths, but you can’t count on it unless you set it up.

3) Do I need efibootmgr or can I just reinstall GRUB?

Reinstalling GRUB fixes the on-disk loader files. efibootmgr fixes the NVRAM pointers. When the entry vanished, you usually need efibootmgr (or fallback boot) to reintroduce the pointer.

4) What’s the right loader path format in efibootmgr?

Use a backslash-delimited absolute path inside the ESP, like \EFI\debian\shimx64.efi. Don’t use Linux paths like /boot/efi/... for -l.

5) Should I point to shim or grub?

If Secure Boot is on (or might be turned on later), point to shimx64.efi. If you’re certain Secure Boot is off and staying off, direct GRUB can be fine.

6) My system boots after I set BootNext, but not after a normal reboot. Why?

BootNext is a one-time override. Your persistent BootOrder still prefers something else (PXE, shell, another disk). Fix BootOrder (Task 16).

7) efibootmgr can list entries but can’t create them. What gives?

Reading variables can work while writes fail, especially with NVRAM quota exhaustion or firmware write restrictions. Check logs (Task 9) and consider fallback boot if writes don’t stick.

8) Is it safe to delete old Boot#### entries to free NVRAM?

Yes if you know what they are. Delete only entries that clearly point to nonexistent disks or old installers. In mixed OS environments, deleting the wrong one is how you buy a second incident.

9) What if there are multiple ESPs?

Pick one per boot disk policy and be consistent. Firmware may prefer the ESP on the first enumerated disk. The safest approach is: keep the primary ESP on the primary boot disk and ensure your entry points to it.

10) Does copying shim to BOOTX64.EFI replace the need for NVRAM entries?

Often it works as a safety net, but it depends on the firmware. Treat it as resilience, not a substitute for correct NVRAM entries.

Conclusion: next steps that prevent a repeat

If your Debian 13 UEFI entry vanished, the fastest reliable fix is not guesswork. It’s a tight loop:

1. Boot in UEFI mode, confirm efivars works.
2. Mount the ESP and verify loader files exist.
3. Reinstall shim/GRUB only if files are missing.
4. Recreate the NVRAM entry with efibootmgr, then set BootOrder.
5. Add a fallback loader at \EFI\BOOT\BOOTX64.EFI if the platform has a history of forgetting.

Do one extra thing after you’re back up: write down the exact efibootmgr command that worked for this hardware model, including the disk and partition. Future-you will thank present-you, and present-you is annoyingly hard to schedule.