What is HD Device Path Node?

Quick note explaining HD Device Path Node for BIOS/UEFI and embedded firmware readers.

3 min read
Đọc bằng English Tiếng Việt 日本語
Boot / NVRAM / Device Path Terms cover

HD Device Path Node is part of UEFI Device Path handling, which describes structured routes to devices, partitions, files, or boot targets.

What does an HD node contain?

An HD node usually carries PartitionNumber, PartitionStart, PartitionSize, Signature, MBRType, and SignatureType. With GPT, the partition GUID/signature and LBA range are often the most useful debug fields.

Example text form:

HD(1,GPT,3F2A...,0x800,0x100000)

This means the boot option points to partition 1, GPT style, with the given signature/GUID, starting at LBA 0x800 and spanning 0x100000 blocks. If you recreate the ESP, the GUID may change and the old boot option becomes stale.

Why it matters

  • Explains how UEFI describes the path to a device or file.
  • Helps debug stale or incorrect boot options.
  • Useful when comparing Boot#### variables and actual hardware topology.

Practical example

Example: a boot option for an NVMe SSD usually contains a path chain such as PCI node → NVMe/storage node → HD node → FilePath node.

Quick checklist

Quick takeaway

HD Device Path Node is a small concept, but it often becomes important when reading logs or debugging real firmware.

How I usually read it

I try not to treat HD Device Path Node as a dictionary entry. I read it as part of a firmware path: who produces it, who consumes it, and what symptom appears when it is wrong. That habit makes the note useful during debugging, not only during study.

Where it shows up

A boot issue often comes from navigation data rather than the boot loader itself. After a BIOS update, disk replacement, or CMOS reset, I would check boot variables, device paths, and ordering before assuming the OS image is broken. HD Device Path Node belongs to that path-finding layer.

In a real debugging session

Treat HD Device Path Node as part of a boot chain, not as an isolated term: Boot Manager reads NVRAM → selects a boot option → parses the Device Path → opens the .efi file → transfers control to the loader. When a system boots the wrong target, the routing metadata is often guilty before the loader itself.

A practical check is to dump the boot variables, see which option the value points to, confirm that the option is active, and then inspect whether the embedded device path still matches the current disk and partition layout.

Public references

Found this useful?

Save it or share it with someone learning firmware, BIOS/UEFI, and embedded systems.

Biến note thành bài viết hoàn chỉnh

Notes là nơi ghi nhanh khái niệm.