Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Rikitav/Unified.Firmware/llms.txt

Use this file to discover all available pages before exploring further.

Once a boot entry exists in NVRAM you can rename it, swap its device path, reorder it relative to other entries, force a one-time boot override, or remove it entirely. All of these operations go through the FirmwareBootService static class, which handles the underlying NVRAM serialization and BootOrder bookkeeping for you. This guide covers the full edit and delete workflow.
Before making any changes, save a copy of the current BootOrder array so you can restore it if something goes wrong. See the Reorder boot entries section below for the save-and-restore pattern.

​
Edit an entry in place (read-modify-write)

FirmwareBootService.EditLoadOption reads the existing Boot#### variable, passes the deserialized FirmwareBootOption to your callback, and writes the mutated object back — all in a single call. This is the safest way to change individual properties because it preserves every field you do not touch. 
using Unified.Firmware.BootService;
using Unified.Firmware.BootService.LoadOption;

// Rename Boot0001 without changing anything else
FirmwareBootService.EditLoadOption(0x0001, option =>
{
    option.Description = "Ubuntu 24.04 LTS";
    option.Attributes = LoadOptionAttributes.ACTIVE;
});
The callback receives a live FirmwareBootOption reference. Any mutations you make inside the lambda are immediately serialized back to NVRAM when the lambda returns.

​
Full replacement update

Use FirmwareBootService.UpdateLoadOption when you want to replace an entry completely — for example after rebuilding the device path protocols from scratch. Unlike EditLoadOption, this method does not read the existing variable first; it overwrites the Boot#### slot with the new object you supply. 
using Unified.Firmware.BootService;
using Unified.Firmware.BootService.LoadOption;
using Unified.Firmware.BootService.Protocols;

DevicePathProtocolBase[] newProtocols =
[
    new HardDriveProtocol(new Guid("xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx")),
    new FilePathProtocol(@"EFI\ubuntu\grubx64.efi"),
];

FirmwareBootOption replacement = new FirmwareBootOption(
    LoadOptionAttributes.ACTIVE,
    "Ubuntu (updated)",
    newProtocols,
    Array.Empty<byte>()
);

// Overwrite Boot0001 with the new object
FirmwareBootService.UpdateLoadOption(replacement, 0x0001);
Prefer EditLoadOption for small property tweaks and UpdateLoadOption when the device path itself must change.

​
Reorder boot entries

FirmwareBootService.LoadOrder is a get/set property backed by the BootOrder NVRAM variable. Read it, rearrange the BootOptionIndex[] array, and write it back. 
using Unified.Firmware.BootService;

// Save a backup before modifying
BootOptionIndex[] saved = FirmwareBootService.LoadOrder;

// Move Boot0003 to the front of the list
BootOptionIndex[] current = FirmwareBootService.LoadOrder;
BootOptionIndex target = 0x0003;

BootOptionIndex[] reordered = [
    target,
    ..current.Where(x => x != target)
];

FirmwareBootService.LoadOrder = reordered;
To roll back to the previous state, simply assign the saved array: 
// Restore the original order
FirmwareBootService.LoadOrder = saved;

​
Set next boot once

FirmwareBootService.NextLoadOptionIndex writes the BootNext NVRAM variable, which causes the firmware to load the specified entry exactly once on the next reboot. After that single boot the variable is automatically cleared and the normal BootOrder resumes. 
using Unified.Firmware.BootService;

// Boot from Boot0007 on the next reboot only
FirmwareBootService.NextLoadOptionIndex = 0x0007;
This is useful for maintenance scenarios — booting into a firmware updater or a recovery partition — without permanently altering the boot order.

​
Delete a boot entry

FirmwareBootService.DeleteLoadOption zeros the Boot#### variable in NVRAM and removes its index from BootOrder in one operation. 
using Unified.Firmware.BootService;

// Remove Boot0005 from NVRAM and from the boot order
FirmwareBootService.DeleteLoadOption(0x0005);
Deleting the only active OS boot entry will leave the system with no path to your operating system. The firmware may fall back to the default \EFI\Boot\bootx64.efi file on the ESP, or it may drop into the firmware setup UI. Always verify the remaining BootOrder after deletion, and keep a recovery mechanism available before removing entries from a production machine.

​
Complete edit-and-verify example

using System;
using Unified.Firmware.BootService;
using Unified.Firmware.BootService.LoadOption;

// ---- Save current order for rollback ----
BootOptionIndex[] originalOrder = FirmwareBootService.LoadOrder;

try
{
    // Rename an existing entry in place
    FirmwareBootService.EditLoadOption(0x0001, opt =>
    {
        opt.Description = "Windows 11 (renamed)";
    });

    // Verify the change
    FirmwareBootOption updated = FirmwareBootService.ReadLoadOption(0x0001);
    Console.WriteLine("New description: {0}", updated.Description);

    // Promote Boot0001 to the top of the order
    BootOptionIndex[] order = FirmwareBootService.LoadOrder;
    FirmwareBootService.LoadOrder = [0x0001, ..order.Where(x => x != (BootOptionIndex)0x0001)];

    Console.WriteLine("Boot order updated.");
}
catch (FirmwareEnvironmentException ex)
{
    Console.Error.WriteLine("Firmware operation failed: {0}", ex.Message);

    // Restore original boot order on error
    FirmwareBootService.LoadOrder = originalOrder;
}

Build docs developers (and LLMs) love

Get started for freeTalk to us