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.

Checkpoint: The package is efibootmgr, version 18-1build2, and the command resolves to /usr/bin/efibootdump.

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

Security warning: A boot variable can contain loader paths and optional data that help identify the installed system. Keep these files in a directory with appropriate permissions, and do not paste unredacted output into a public bug report.

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

Tip: sudo is not a general repair. It cannot create a missing variable interface, make a legacy boot or firmware expose UEFI data, or fix a malformed saved file. Keep the command read-only, and avoid using efibootmgr to change boot state while you are still diagnosing a display problem.

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:

$ 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.

Warning: The main irreversible trap is outside the command. Do not redirect output over an evidence file, and do not substitute efibootmgr commands that edit entries while following this read-only procedure.

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.

Done means