A wrong boot order can turn a routine reboot into a trip to the server room, and efibootmgr edits exactly that. You will inspect the firmware boot entries, test a one-time next boot, and change the persistent BootOrder only after recording the current state. Allow about fifteen minutes, plus a maintenance window if the machine must restart.
The examples use efibootmgr 18, installed here as package version 18-1build2. You need a Linux system booted in UEFI mode, the efibootmgr package, and root access for the commands that read or write EFI variables.
Warning: This tool changes firmware state, not a GRUB menu or a file under /etc. Keep physical or remote console access available before changing the default boot path.
Check the installed binary and version as an ordinary user:
$ command -v efibootmgr
/usr/bin/efibootmgr
$ efibootmgr -V
version 18efibootmgr needs the kernel's EFI variable interface, normally exposed under /sys/firmware/efi/efivars/ or the older /sys/firmware/efi/vars/ path. A system booted in legacy BIOS mode cannot use this workflow. Check the interface without changing anything:
$ test -d /sys/firmware/efi && echo 'UEFI interface present' || echo 'UEFI interface absent'
UEFI interface presentThe output is host-specific. If the directory is absent, stop. Rebooting in UEFI mode is a boot configuration decision, and installing more efibootmgr options will not create the missing kernel interface.
Read the firmware variables as root and save the text output somewhere protected. This is a read-only command, but it may expose loader names or device details, so do not paste the file into a public issue:
$ sudo efibootmgr | tee "$HOME/efibootmgr-before.txt"
BootCurrent: 0001
BootOrder: 0001,0000
Timeout: 1 seconds
Boot0000* Linux
Boot0001* UEFI OSThe entries and numbers will differ. How to read the output:
BootCurrent is the entry that started this system.BootOrder is the persistent order the firmware tries.BootNext is printed by some firmware, and takes precedence for one boot.Checkpoint: Write down the exact four-hex-digit entry number you want to test, and confirm its displayed label and device path. Do not infer an entry number from its position in the list.
Use --bootnext to select an existing entry for the next boot only. Replace 0000 with the entry number from your own listing:
$ sudo efibootmgr --bootnext 0000
BootNext: 0000
BootOrder: 0001,0000This writes a firmware variable, so elevated privileges are required. It does not reorder BootOrder. The firmware normally consumes BootNext after one boot, whether that attempt succeeds or fails. Verify it before rebooting:
$ sudo efibootmgr | sed -n '1,4p'
BootNext: 0000
BootOrder: 0001,0000To cancel the pending one-time choice before rebooting, remove BootNext:
$ sudo efibootmgr --delete-bootnext
$ sudo efibootmgr | sed -n '1,4p'Tip: Do not use --delete-bootnext as a repair for a failed loader. It only removes the one-time selection. Investigate the loader entry and filesystem separately.
Only do this after the one-time test, or after confirming the intended order from the saved listing. Pass a comma-separated list of existing entry numbers:
$ sudo efibootmgr --bootorder 0000,0001
BootOrder: 0000,0001The option accepts values from 0000 to FFFF, provided each value corresponds to an existing Boot#### variable.
Warning: This changes persistent firmware state. A wrong order can leave the host unable to reach the expected operating system, so keep a recovery console and the original output available.
Verify both the order and the entry contents:
$ sudo efibootmgr
BootOrder: 0000,0001
Boot0000* Linux
Boot0001* UEFI OSRecovery: Run the same option with the original order recorded in efibootmgr-before.txt. For example, if the saved order was 0001,0000:
$ sudo efibootmgr --bootorder 0001,0000Creating an entry is more sensitive than reordering existing ones. It depends on the EFI System Partition, partition number, loader path and firmware device-path behaviour. First identify the mounted EFI System Partition with your normal disk tools, then use explicit values rather than relying on efibootmgr's defaults.
The manpage's defaults are /dev/sda, partition 1, label Linux and loader \EFI\ubuntu\grub.efi. Those defaults are not universal.
For an EFI System Partition on /dev/nvme0n1, partition 1, with a loader at \EFI\debian\grubx64.efi, an administrator might run:
$ sudo efibootmgr --create \
--disk /dev/nvme0n1 --part 1 \
--label 'Linux' --loader '\EFI\debian\grubx64.efi'Warning: Do not paste that command until the disk, partition and loader have been checked on this machine. --create adds a new boot variable and puts it into BootOrder. If you need a new entry without adding it to the order, the manpage also provides --create-only.
Recheck the full listing afterwards, and remove only a duplicate or incorrect entry whose number you have positively identified.
An error saying that EFI variables are unsupported usually means the system is not booted with usable EFI variable access. On this machine, the installed command returns that message and status 2 because the execution environment does not expose EFI variables. That is a limitation of the running environment, not evidence that a different boot number is needed.
If a requested entry does not exist, inspect the listing again and correct the number. If firmware refuses a newly created path, the manpage documents --full-dev-path and --file-dev-path, but these are compatibility choices, not routine fixes. The default uses an abbreviated hard-disk HD() path. Try a different path mode only after recording the failed entry and checking how this firmware represents working entries.
Destructive action: Do not delete BootOrder, boot entries or the EFI System Partition as a troubleshooting shortcut. --delete-bootorder and --delete-bootnum are destructive firmware changes with no general undo command.
Recovery: Restore a known order with --bootorder, and recreate a deliberately removed entry only after verifying its complete path.
BootOrder and entry numbers.BootNext for a one-boot test where possible.