Control UEFI boot entries from Linux: list, reorder, add and remove EFI NVRAM entries using `efibootmgr`. 06.02.2026 | reading time: 3 min You just installed another OS or Windows clobbered GRUB — now the system boots the wrong firmware entry; `efibootmgr` lets a Linux administrator inspect and edit UEFI NVRAM boot entries from the shell so he can restore order without fumbling through firmware menus. Repair a missing GRUB: quick walkthrough Follow this concrete case: Windows update removed the GRUB boot option and the machine boots straight into Windows; mount the EFI System Partition and recreate a GRUB entry. Example commands and outputs (run as root): ```bash # mount /dev/sda1 /boot/efi # efibootmgr -v BootCurrent: 0001 Timeout: 1 seconds BootOrder: 0001,0002 Boot0000* Windows Boot Manager HD(1,GPT,...)\EFI\Microsoft\Boot\bootmgfw.efi Boot0001* ubuntu HD(1,GPT,...)\EFI\ubuntu\grubx64.efi Boot0002* Fedora HD(2,GPT,...)\EFI\fedora\shimx64.efi ``` To add a new entry pointing at the EFI GRUB file and make it first in order: ```bash efibootmgr -c -d /dev/sda -p 1 -L "ubuntu" -l '\EFI\ubuntu\grubx64.efi' efibootmgr: Created entry Boot0003 # verify efibootmgr -v BootOrder: 0003,0001,0002 Boot0003* ubuntu HD(1,GPT,...)\EFI\ubuntu\grubx64.efi ``` If an old entry needs removal: ```bash efibootmgr -b 0002 -B # sets permanent next boot only efibootmgr -n 0003 ``` Gotchas and deeper controls A few operational points matter: `efibootmgr` talks to EFI variables via efivarfs or the kernel EFI API so it requires UEFI mode and root privileges; many firmwares limit NVRAM entry count and may rename or reset entries during OS updates; use `-n` for one-shot next-boot, `-o` to set BootOrder, `-b`/`-B` to target a specific entry, and `-c` with `-d`/`-p` and `-l` to create an entry that points to a file on the ESP; when things misbehave, check `/sys/firmware/efi/efivars` and vendor firmware settings and prefer a cautious sequence of list → create → set order rather than blind edits. When and why other approaches help Some situations call for different tools: if Secure Boot policies are involved, shim/signed loaders matter and you may need `sbsigntool` or vendor utilities; in virtual machines use OVMF/UEFI firmware images and edit NVRAM from the host or via the guest console; if firmware ignores changes, updating firmware with `fwupd` or using the UEFI setup UI might be necessary; always document original BootOrder before changes so you can revert. Wrap-up and next steps Managing EFI boot entries gives hands-on control over which OS the firmware starts, but it touches NVRAM and firmware behavior so operate with caution and test changes; practice in a VM, read your firmware notes, and add these skills to a professional Linux toolkit to harden troubleshooting capabilities — consider deepening that toolkit with structured training and exam preparation at bitsandbytes.academy for certifications like CompTIA Linux+ or LPIC-1. Join Bits & Bytes Academy First class LINUX exam preparation. boot-process utilities troubleshooting setup
