Boot Option Architecture là gì?

Boot Option Architecture là cách UEFI mô hình hóa các lựa chọn boot bằng Boot####, BootOrder, BootNext, BootCurrent và EFI_LOAD_OPTION. Trong đó, BootOrder, BootNext và BootCurrent là ba UEFI variables rất quan trọng trong boot flow. Chúng cho firmware biết boot option nào được ưu tiên, lần boot kế tiếp có cần boot một option đặc biệt không, và lần boot hiện tại đã boot từ option nào.

Nói ngắn gọn:

• BootOrder: danh sách thứ tự boot mặc định
• BootNext: boot một lần vào một option cụ thể ở lần boot kế tiếp
• BootCurrent: option đang được dùng trong lần boot hiện tại

Ba biến này là trung tâm của nhiều lỗi thực tế: đổi thứ tự boot trong BIOS nhưng không lưu, efibootmgr tạo entry nhưng firmware không boot, boot USB một lần nhưng lần sau vẫn boot USB, Boot#### tăng mãi làm đầy NVRAM, hoặc Windows/Linux boot manager tranh nhau sửa BootOrder.

Bộ biến boot cơ bản trong UEFI

UEFI Boot Variables
├─ BootOrder
│  └─ Danh sách UINT16: 0001, 0003, 0007...
├─ BootNext
│  └─ UINT16: option dùng một lần ở boot kế tiếp
├─ BootCurrent
│  └─ UINT16: option đang được dùng trong boot hiện tại
├─ Boot0001
│  └─ EFI_LOAD_OPTION: description, attributes, device path, optional data
├─ Boot0003
│  └─ EFI_LOAD_OPTION
├─ Boot0007
│  └─ EFI_LOAD_OPTION
└─ Timeout
   └─ Thời gian chờ boot menu tùy implementation

Trong đó Boot#### là variable có tên dạng Boot + 4 chữ số hex. Ví dụ Boot0000, Boot0001, Boot00AF.

BootOrder chỉ tham chiếu tới các số này. Nếu BootOrder chứa 0003 nhưng Boot0003 không tồn tại hoặc corrupt, BDS cần xử lý option đó là invalid.

BootOrder là gì?

BootOrder là UEFI variable chứa thứ tự ưu tiên boot. Data của nó là một array các giá trị UINT16. Mỗi giá trị tương ứng với một Boot####.

Ví dụ:

BootOrder = [0001, 0003, 0007]

Nghĩa là firmware sẽ thử:

Boot0001 -> Boot0003 -> Boot0007

Nếu Boot0001 fail hoặc không hợp lệ, firmware thử option tiếp theo.

Boot#### là gì?

Boot#### chứa nội dung boot option thật. Nó thường là một EFI_LOAD_OPTION.

Boot#### variable
├─ Attributes
│  ├─ ACTIVE
│  ├─ FORCE_RECONNECT
│  ├─ HIDDEN tùy implementation/spec version
│  └─ Category bits tùy spec/platform
├─ FilePathListLength
├─ Description
│  └─ Ví dụ: Windows Boot Manager, UEFI USB, Linux Boot Manager
├─ Device Path
│  ├─ HD(...)
│  ├─ File(\EFI\Microsoft\Boot\bootmgfw.efi)
│  └─ End node
└─ OptionalData
   └─ Dữ liệu thêm cho boot loader hoặc platform

Nếu Boot#### có device path sai, BootOrder đúng cũng không giúp máy boot. Nếu BootOrder trỏ tới Boot#### đã bị xóa, firmware phải bỏ qua hoặc rebuild.

BootNext là gì?

BootNext dùng để chỉ định one-time boot. Nó chứa một UINT16 trỏ tới một Boot####. Nếu BootNext = 0007, lần boot kế tiếp BDS sẽ ưu tiên Boot0007 trước BootOrder.

Sau khi dùng, firmware thường phải xóa BootNext để nó chỉ có hiệu lực một lần.

BootCurrent là gì?

BootCurrent cho biết boot option đang được dùng trong lần boot hiện tại. Nó thường được firmware set sau khi chọn một boot option thành công.

Ví dụ nếu firmware boot từ Boot0001, nó có thể set:

BootCurrent = 0001

OS hoặc bootloader có thể đọc BootCurrent để biết lần boot này đến từ entry nào.

BootCurrent không phải danh sách ưu tiên. Nó là “lần này boot từ đâu”.

Boot flow với BootNext và BootOrder

Tùy implementation, thứ tự clear BootNext trước hay sau khi boot option thành công có thể khác. Nhưng requirement thực tế là BootNext không nên gây loop vô hạn nếu option fail hoặc boot reset.

BootOrder, BootNext, BootCurrent nên có attributes gì?

Nếu BootOrder thiếu RUNTIME_ACCESS, OS tool như Linux efibootmgr hoặc Windows boot management có thể không quản lý được. Nếu thiếu NON_VOLATILE, thứ tự boot có thể mất sau reboot.

OS và firmware cùng sửa BootOrder

Một lý do BootOrder “tự đổi” là OS boot manager cũng có quyền sửa UEFI variables. Windows, Linux, update tool, recovery tool hoặc installer có thể tạo/sửa Boot####, BootOrder, BootNext.

Boot#### leak làm đầy NVRAM

Nếu firmware hoặc OS tạo boot entry mới mỗi lần boot, NVRAM sẽ đầy dần.

Ví dụ:

Boot0001 Windows Boot Manager
Boot0002 UEFI USB
Boot0003 UEFI USB
Boot0004 UEFI USB
Boot0005 UEFI USB
...

Device path giống nhau nhưng mỗi lần lại tạo option mới.

BootOrder trỏ tới option không tồn tại

Một lỗi khác: BootOrder chứa số 0008, nhưng Boot0008 đã bị xóa hoặc corrupt.

Firmware có thể:

• Bỏ qua entry đó
• Xóa entry khỏi BootOrder
• Rebuild BootOrder
• Vào boot menu
• Boot chậm vì retry nhiều option invalid
• Tạo lại Boot#### nếu detect device

BootNext fail thì chuyện gì xảy ra?

BootNext có thể trỏ tới option không tồn tại, inactive hoặc load fail. Firmware cần xử lý an toàn.

Các câu hỏi cần trả lời khi đọc BDS code:

• Firmware clear BootNext trước hay sau khi thử boot?
• Nếu BootNext option fail, có fallback BootOrder không?
• Nếu BootNext trỏ missing Boot####, có clear không?
• Nếu BootNext boot vào updater và updater reset, có loop không?
• Nếu BootNext set bởi OS nhưng variable store write fail, status có được báo không?

BootCurrent debug boot source

Khi máy boot không đúng entry, BootCurrent giúp biết firmware thực tế đã chọn entry nào. Nhưng cần hiểu timing.

Failure pattern thực tế

Debug Diary: efibootmgr tạo entry nhưng firmware không boot

User tạo boot entry Linux bằng efibootmgr. Lệnh báo tạo thành công, nhưng reboot vẫn vào Windows.

Debug theo hướng:

Debug Diary: BootNext không clear làm máy kẹt updater

Capsule updater set BootNext tới một firmware update boot option. Máy reboot vào updater, updater fail rồi reset. Boot sau lại vào updater vì BootNext chưa bị clear. User thấy máy loop.

Fix direction:

• BDS clear BootNext đúng thời điểm
• Updater clear BootNext khi đã nhận control nếu phù hợp
• Nếu BootNext option fail, fallback BootOrder
• Log BootNext value trước và sau boot attempt
• Không return success giả khi xóa BootNext fail
• Có recovery path nếu BootNext loop nhiều lần

Debug Diary: BootOrder tự quay về Windows Boot Manager

Một case thường gặp trên dual boot: user đặt Linux lên đầu, nhưng sau khi vào Windows, BootOrder quay lại Windows Boot Manager.

Có thể không phải BIOS bug. Windows boot manager, update, recovery hoặc OEM tool có thể ghi BootOrder runtime.

Checklist:

Instrumentation nên có

Không log OptionalData nhạy cảm nếu platform dùng để chứa dữ liệu riêng. Với device path, log summary đủ dùng nếu log public.

Debug playbook

Security checklist

Khi đọc source nên tìm gì?

Câu hỏi tự kiểm tra

Blog seeds

• BootOrder Explained: danh sách nhỏ quyết định máy boot từ đâu
• BootNext: one-time boot trong UEFI và bug boot loop
• BootCurrent: debug máy thật sự boot từ entry nào
• Boot#### Leak: boot option tăng mãi làm đầy NVRAM
• efibootmgr tạo entry nhưng không boot, debug từ đâu?

Bài liên quan

• Boot Manager là gì?
• Boot#### là gì?
• BootOrder là gì?
• BootNext là gì?
• BootCurrent là gì?
• EFI_LOAD_OPTION là gì?
• UEFI Variable Store là gì?
• Variable Store Full là gì?
• NVRAM Corruption là gì?
• BDS là gì?

Nguồn tham khảo public

• UEFI Specification
• EDK II BDS modules
• EDK II Boot Manager library
• EDK II Variable driver modules

☕ Ủ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.