UEFI boot entries and Secure Boot state on Linux and Windows

Goal

Inspect and, when needed, repair the UEFI firmware's boot-entry list and confirm the Secure Boot state on a Linux or Windows system that will not start from the expected disk or loader.

Prerequisites

UEFI (not legacy BIOS) firmware; root on Linux or an elevated prompt on Windows, from the running system, a rescue medium or the firmware setup screen; on Linux, efivarfs mounted (normal on UEFI-booted systems).

Steps

1. List entries on Linux: efibootmgr -v shows each entry's number, label and device path, the BootOrder the firmware follows and BootCurrent, the entry used for this boot. Create an entry with efibootmgr -c -d <disk> -p <partition> -L "<label>" -l '\EFI\<dir>\shimx64.efi' (-c also adds the new entry to BootOrder, normally at the front), delete one with efibootmgr -b <bootnum> -B, reorder with -o <bootnum>,<bootnum>,.... Each edit writes firmware variables immediately; there is no separate apply step. Record the -v output first so the old order can be restored with -o.
2. To test a new entry once without changing the order, set efibootmgr -n <bootnum> (BootNext); the firmware uses it for the next boot only and then falls back to BootOrder.
3. On Windows, bcdedit /enum firmware lists the firmware boot-manager entries (distinct from the OS-loader entries of a plain bcdedit /enum); in PowerShell quote identifiers such as '{fwbootmgr}'. Windows normally recreates its own entry with bcdboot <drive>:\Windows (elevated) rather than by direct editing.
4. If the system boots to firmware setup or the wrong OS after a boot-loader reinstall, the usual cause is a missing entry or one not first in the order — fix with efibootmgr -o or the firmware's boot-order setting.
5. Check Secure Boot before blaming it for a "not trusted" failure: mokutil --sb-state on Linux; on Windows Confirm-SecureBootUEFI in an elevated PowerShell returns $True or $False, and prints "Cmdlet not supported on this platform" on BIOS or unsupported firmware.
6. With Secure Boot on, the Linux chain is: firmware trusts a signed shim, shim also trusts Machine Owner Keys (MOK). mokutil --import <key.der> asks for a one-time password and only stages the key; at the next boot shim's MokManager asks at the console to confirm enrollment with that password, so someone must be at the console. This article does not cover generating or signing keys.
7. After any edit, reboot and confirm with efibootmgr -v or bcdedit /enum firmware that the order took effect.

Expected result

The intended entry is present and first in BootOrder; the reported Secure Boot state matches what the workload needs — preferably enabled, with a third-party module's key enrolled through MOK rather than Secure Boot switched off.

Limits and test basis

efibootmgr edits NVRAM directly — deleting the wrong entry is immediately live, so check boot numbers in the -v output before using -B. Firmware implementations differ in how they treat added or malformed entries (some drop or reorder them), so confirm behaviour on the actual hardware.