How it works
UEFI firmware uses GUIDs to identify almost everything it handles: the protocols offered by drivers, DXE, PEI and SMM modules, firmware volumes and variable namespaces, such as the one for global boot variables or the one for Secure Boot signature databases. A GUID on its own says nothing; this tool looks up its symbolic name in a catalog of thousands of GUIDs from EDK2 and the main firmware vendors.
A device path is the route the firmware uses to reach a device or a file: from the root of the PCI bus to the controller, the disk, the partition and the .efi loader. Boot#### boot entries store a device path in binary; the tool translates it into its text form and explains each node with its fields.
Examples
8BE4DF61-93CA-11D2-AA0D-00E098032B8CEfiGlobalVariableGuidNamespace of the specification's global variables, such as BootOrder, Boot#### or SecureBoot.db-d719b2cb-3d3a-4596-a3bc-dad00e67656fEfiImageSecurityDatabaseGuidFile name from /sys/firmware/efi/efivars: the Secure Boot db variable. The tool extracts the GUID from the name.Fv(7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1)/FvFile(7C04A583-9E3E-4F1C-AD65-E05268D0B4D1)Fv → FvFile 7C04A583-9E3E-4F1C-AD65-E05268D0B4D1 = FullShellBoot entry of a UEFI Shell built into the firmware: the file is looked up by GUID within a firmware volume.01 00 00 00 20 00 55 00 45 00 46 00 49 00 20 00 4F 00 53 00 00 00 02 01 0C 00 D0 41 03 0A 00 00 00 00 01 01 06 00 02 1F 03 12 0A 00 00 00 FF FF 00 00 7F FF 04 00UEFI OS — PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0xFFFF,0x0)Binary content of a Boot#### variable: attributes, description and device path. If you paste the efivarfs file, the four variable attribute bytes at the beginning are recognized automatically.Use cases
- Understand what each entry listed by efibootmgr -v boots before changing the boot order or deleting one.
- Identify the GUIDs that appear in a boot log, a variable dump or EDK2 code.
- Find out which variable each file in /sys/firmware/efi/efivars corresponds to, for example the Secure Boot signature databases.
- Locate which disk, partition and file a boot entry uses when it stopped working after cloning or replacing a disk.
- Review the modules of a firmware image opened with UEFITool or other analysis tools.
Frequently asked questions
Where do I get the device path of a boot entry from?
On Linux, efibootmgr -v shows each entry with its device path in text, and the Boot#### files in /sys/firmware/efi/efivars contain the complete binary, which can be dumped with xxd or hexdump -C. In the UEFI Shell, bcfg boot dump -v shows the entries and map -v shows the device paths of the disks.
Why is a GUID not listed in the catalog?
Any manufacturer can create GUIDs for its own modules without registering them anywhere. The catalog gathers those from EDK2 and those the community has identified in firmware from the main manufacturers, but there will always be proprietary GUIDs without a name. The partition GUIDs that appear in HD nodes are unique to each disk and are never listed.
Which device path formats does it accept?
The specification's text form, as shown by the UEFI Shell and EDK2, a complete efibootmgr -v line and the binary in hexadecimal, whether separated by spaces or not, and also as xxd or hexdump -C output. The binary can be the device path alone, the content of a Boot#### variable or the efivarfs file with its attributes at the beginning.
Is the device path sent to a server?
No. The device path is decoded in your browser. Only the firmware GUIDs that appear in the nodes are looked up on the server, to show their names; partition GUIDs and the rest of the data never leave your computer.
What is the data that efibootmgr shows after the file path?
It is the entry's optional data, which the firmware passes to the loader. Windows Boot Manager, for example, stores a reference to its BCD store there. It is not part of the device path; if you paste the variable's binary, the tool shows it separately.