Read UEFI Boot Entries with efibootdump

When a machine boots the wrong thing, or nothing, you want to read the boot entry itself before you touch anything, and efibootdump does exactly that. You will display an entry from the running machine or from a saved variable file, then tell a bad path from a wrong GUID from an invalid variable, in about fifteen minutes.

The command displays data. It does not create, delete or reorder boot entries.

You need a Linux system with the efibootmgr package installed, and either a UEFI variable to inspect or a file exported from efivarfs. Reading a live variable can require elevated privileges, depending on host permissions and firmware support. The file examples are ordinary, read-only commands.

1. Check the installed command

Check the binary and package version first. That stops you applying another machine's syntax to the command in front of you:

$ command -v efibootdump
/usr/bin/efibootdump
$ dpkg-query -W -f='${Package} ${Version}\n' efibootmgr
efibootmgr 18-1build2
$ efibootdump --help
Usage: efibootdump [-?] [-g|--guid={guid}] [-f|--file=<file>] [-v|--verbose]
        [-?|--help] [--usage] [OPTIONS...] [name0 [... [nameN]]]

The installed help includes -v/--verbose, which is useful for error reporting. The local manual page documents the main file, name and GUID forms but does not list that option. Treat the installed help as the authority for this version, and keep --verbose for cases where the default diagnostic is not enough.

2. Read a saved boot variable

A file is the safest first inspection. Pass the path after -f or --file:

$ efibootdump --file /path/to/saved/Boot0001
/path/to/saved/Boot0001: * Ubuntu HD(1,GPT,...)/File(\\EFI\\ubuntu\\shimx64.efi)

The path, description and optional data are host-specific. A line normally starts with the file name, then an asterisk for an active entry, its description and a formatted device path. Do not copy the sample output as a claim about your own boot loader. The useful verification is the exit status:

$ printf 'efibootdump status: %s\n' "$?"
efibootdump status: 0

The input file is opened and read by efibootdump, and this operation does not modify it. If you have several saved variables, repeat -f for each file:

$ efibootdump -f /path/to/saved/Boot0001 -f /path/to/saved/Boot0002

3. Inspect a live variable by name

To read a variable on the current machine, give its name, not a file path:

$ efibootdump Boot0001
Boot0001: * Ubuntu HD(1,GPT,...)/File(\\EFI\\ubuntu\\shimx64.efi)

Variable names are firmware-specific. Use an exact name such as Boot0001, not a guessed description. If the machine is not booted in UEFI mode, or its EFI variable interface is unavailable, there may be no live variable to read. The upstream project notes that its EFI tools require efivarfs or the legacy efivars kernel interface.

If an ordinary read fails with a permission error, first inspect the interface and its permissions. Only then retry the same read with the privilege your host policy requires:

$ findmnt /sys/firmware/efi/efivars
$ ls -ld /sys/firmware/efi/efivars
$ sudo efibootdump Boot0001

4. Supply a non-default GUID when needed

Names are looked up in the EFI Global Variable namespace unless you give -g or --guid. Use the exact GUID associated with the variable source:

$ efibootdump --guid GUID_VALUE Boot0001
Boot0001-GUID_VALUE: * Description HD(1,GPT,...)/File(\\EFI\\vendor\\loader.efi)

Replace GUID_VALUE with a real GUID, for example one supplied by the firmware documentation or the tool that exported the variable. Do not invent a GUID from the entry's description. The GUID option applies to named live variables; the file form reads the variable data already in the file.

When you are unsure which namespace a saved file represents, do not keep guessing. Preserve the original file, identify where it came from, and compare it with the exporter or incident record. A valid load option in the wrong namespace is still the wrong object to investigate.

5. Diagnose failures without changing boot state

An absent file is a path problem. Check it without writing to the directory:

$ test -r /path/to/saved/Boot0001 && echo readable
$ efibootdump -f /path/to/saved/Boot0001
$ printf 'status: %s\n' "$?"

What each failure looks like:

• Missing file. The installed command reports a stat error and returns status 7. That identifies the input path, not the contents of a UEFI variable. Check spelling, mount points and access before trying a different GUID.
• Invalid or truncated file. The program checks the EFI load-option structure and reports that the data is not a valid load option, with a non-zero status. Do not repair such a file by editing bytes in place. Re-export it from the original source or obtain a fresh diagnostic archive, keeping the bad copy for comparison.
• No name or file supplied. The command prints usage and returns status 4. That is expected argument validation, not evidence of broken firmware.

$ efibootdump
Usage: efibootdump ...
$ printf 'status: %s\n' "$?"
status: 4

Use --verbose when an error needs more detail. Treat an output line containing <bad device path>, <bad optional data> or an invalid description as a data-quality warning, even if the file itself was opened successfully.

6. Keep the safety boundary clear

efibootdump is an inspection tool. It has no undo operation because the examples above do not change firmware variables, files or boot order.

For a support bundle, capture the command, package version, exit status and relevant output separately. Redact machine names, disk identifiers and loader arguments when they identify a person or system. Preserve the original variable file and record its checksum if the investigation depends on proving it was not altered.