How UEFI boot options are structured

UEFI boot option architecture is the way firmware represents, stores, and selects boot targets. It is built around UEFI variables such as Boot####, BootOrder, BootNext, and BootCurrent, plus the EFI_LOAD_OPTION payload stored inside each Boot#### entry.

If you learn each variable in isolation, the model feels fragmented. During debugging, you need the architecture: who creates the boot option, who orders it, who parses the device path, who calls LoadImage(), and which policy changes the order after a failure.

The overall picture

UEFI Variable Store
├─ BootOrder
│  └─ UINT16 list: 0001, 0003, 0007...
├─ BootNext
│  └─ One-time UINT16 option
├─ BootCurrent
│  └─ Current booted option
├─ Boot0001
│  └─ EFI_LOAD_OPTION
├─ Boot0003
│  └─ EFI_LOAD_OPTION
└─ Boot0007
   └─ EFI_LOAD_OPTION

BootOrder is only a reference list. Boot#### stores the description, attributes, device path, and optional data. BootNext is a one-time override. BootCurrent records what the firmware actually used.

Role of each part

How BDS consumes boot options

Some boot failures look like OS loader problems, but the firmware may never reach the loader because device path resolution or LoadImage() failed first.

Who creates Boot####?

Boot options may be created by several producers:

• firmware when it discovers an OS loader
• BIOS Setup UI when the user adds an option
• an OS installer
• OS tools such as efibootmgr or Windows boot management tools
• recovery flow or firmware update logic
• platform policy that creates fallback entries

Because there are many producers, boot options can easily become duplicated, stale, or inconsistent with the UI.

Boot option lifecycle

A boot option usually moves through this lifecycle:

Create -> Add to BootOrder -> Try -> Success/Fail -> Keep/Reorder/Delete/Disable

Real variants include:

• The option is created but never added to BootOrder.
• The option is in BootOrder but inactive.
• Firmware moves a repeatedly failing option toward the end.
• The option still points to an old disk after cloning or SSD replacement.
• An OS update creates a new entry but does not remove the old one.
• A firmware update preserves NVRAM and therefore preserves old errors too.

Real debug case: boot option leak

A boot option leak happens when the system keeps creating new boot options without cleaning old ones. Over time, the variable store fills up or the boot menu becomes full of duplicate-looking entries.

Symptoms include:

• Boot0001, Boot0004, and Boot0008 share the same description.
• BootOrder becomes unusually long.
• BIOS Setup shows many similar entries.
• SetVariable() starts returning EFI_OUT_OF_RESOURCES.
• dbx update or BIOS Setup save fails because space is low.

Debug direction:

1. Dump all Boot#### entries.
2. Compare description and full device path.
3. Check which entries are referenced by BootOrder.
4. Find the producer that creates new entries.
5. Check variable store reclaim.
6. Do not blindly delete Secure Boot variables or Setup variables.

Source-reading checklist

Useful logs

BootNext
BootOrder
BootCurrent
All Boot#### names
EFI_LOAD_OPTION attributes
Device Path text
OptionalData size
Producer path if a new option is created
LoadImage status
StartImage status
Variable store free space or quota

Good logs tell you whether the failure is in boot option structure, boot selection policy, or the loader itself.

Related notes

• What is the UEFI Boot Manager?
• What is Boot####?
• What is EFI_LOAD_OPTION?
• What is BootOrder?
• What is BootNext?

☕ Ủng hộ tác giả

Nếu bài viết hữu ích, một ly cà phê nhỏ sẽ giúp mình tiếp tục viết thêm nội dung chất lượng.

MoMo

QR image
/images/support/momo-qr.png

PayPal

QR image
/images/support/paypal-qr.png

PayPay

QR image
/images/support/paypay-qr.png

Mở app MoMo → Mở PayPal → PayPayで送る →

Trên điện thoại, hãy nhấn nút bên dưới mỗi QR để mở app thanh toán.