bootnext: sets the UEFI BootNext variable and reboots

bootnext is a simple command-line tool for Linux and Windows that sets the UEFI BootNext NVRAM variable and triggers a reboot into the target operating system. This facilitates quickly switching to another OS without modifying the default boot order. Note that this tool only supports operating systems installed in UEFI mode rather than legacy BIOS mode, so be sure to read the Troubleshooting section for details on how to check which mode your OS is running under.

Booting into another OS just requires specifying a regular expression that will be matched against the human-readable description of the target UEFI boot entry:

# Selects the Windows Boot Manager and boots into it
bootnext windows

# Selects the GRUB bootloader installed by Ubuntu Linux and boots into it
bootnext ubuntu

# Selects the first available bootable USB device and boots into it
# (Note that the regular expression is case insensitive, so `bootnext usb` works too)
bootnext USB

Contents

• Background and intended use
• Installation
  • Prerequisites
  • System-wide installation
  • Portable installation
• Usage
  • Listing boot entries
  • Booting into a target OS
  • Performing a dry run
  • Automatic privilege elevation
  • Setting the BootNext variable without rebooting
• Troubleshooting
  • Booting into Linux just loads its bootloader (e.g. GRUB) and boots the default menu entry
  • Determining whether an operating system is running under UEFI mode or legacy BIOS mode
  • Running bootnext prints the error unsupported system configuration: the operating system has not been booted in UEFI mode
• Building from source
• Legal

Background and intended use

This tool is primarily designed for scenarios where a user is remotely accessing a bare metal machine that boots multiple operating systems, and they need to switch between OSes. Unless the remote machine supports IPMI or is being accessed via a mechanism that supports BIOS/UEFI interaction such as a KVM over IP switch, a lack of physical access typically precludes the ability to interact with any boot menus. The simplest fallback option is to manipulate the machine's UEFI NVRAM variables through OS-specific software mechanisms, and this is precisely what bootnext does:

• Under Linux, the efibootmgr command is used to manipulate UEFI variables

• Under Windows, the bcdedit command is used to manipulate UEFI variables

In addition to its intended use in remote access scenarios, bootnext can also simply act as a convenient cross-platform tool for quickly booting into a given target OS without needing to interact with the BIOS/UEFI. It is particularly handy when booting into installers and live environments stored on bootable USB devices, and can even be stored on the USB device itself when using multiboot systems such as Ventoy. However, take note of the limitations discussed in the Listing boot entries section, since USB devices will need to be present at system startup in order to be detected.

When accessing boot entries that are already present in the UEFI NVRAM, running bootnext is typically faster and easier than rebooting and accessing the UEFI boot menu. Its ability to automatically select the first boot entry whose description matches a user-provided regular expression also makes it slightly faster than directly running efibootmgr or bcdedit.

When accessing boot entries that are not already present in the UEFI NVRAM and require a reboot in order to be detected (e.g USB devices that were plugged in after system startup), rebooting and running bootnext to trigger a second reboot will always be slower than just rebooting once and accessing the UEFI boot menu directly. That being said, using bootnext might still be preferable if you are unsure of the correct key to press to enter the boot menu at startup, or if you are using a machine with a buggy UEFI implementation that refuses to display a boot menu. (Note that if you do happen to have a machine with a buggy UEFI implementation, there are other workarounds available that you can always use to access the UEFI setup or boot into another OS, so bootnext simply represents a convenience on these machines rather than a necessity.)

Installation

Prerequisites

Although the bootnext executable itself is fully self-contained, it does require that the appropriate OS-specific UEFI variable manipulation tool is available at runtime:

• Under Linux, the efibootmgr command needs to be installed. It is available in the system package repositories of most distributions. For example:

  • Arch / Manjaro: sudo pacman -S efibootmgr
  • CentOS / Fedora / RHEL: sudo dnf install efibootmgr
  • Debian / Ubuntu: sudo apt-get install efibootmgr
  • openSUSE: sudo zypper install efibootmgr

• Under Windows, the bcdedit command ships with the operating system by default, so nothing needs to be installed.

System-wide installation

Pre-compiled binaries can be downloaded from the releases page, and just need to be placed in a directory that is included in the system's PATH environment variable. Note that you will need to download the appropriate binary for your operating system and CPU architecture, and each binary is named with the suffix -OS-ARCH, where OS is either linux or windows and ARCH is the name of the CPU architecture. The architecture names follow the naming conventions used by the Go programming language, and the following architectures are supported:

• 386: 32-bit x86
• amd64: 64-bit x86, also known as x86_64
• arm64: 64-bit ARM

You can use the following commands to download and install the latest release binary under Linux:

# Note: replace the `amd64` suffix with the appropriate value under other CPU architectures
URL="https://github.com/TensorWorks/bootnext/releases/download/v0.0.2/bootnext-linux-amd64"
sudo curl -fSL "$URL" -o /usr/local/bin/bootnext
sudo chmod +x /usr/local/bin/bootnext

Under Windows, run the following command from an elevated command prompt or PowerShell window:

# Note: replace the `amd64` suffix with the appropriate value under other CPU architectures
curl.exe -fSL "https://github.com/TensorWorks/bootnext/releases/download/v0.0.2/bootnext-windows-amd64.exe" -o "C:\Windows\System32\bootnext.exe"

Portable installation

If you are using bootnext to boot from a multiboot USB device managed by Ventoy then it can be handy to store the binaries on the USB device itself. As mentioned in the Prerequisites section, the binaries are fully portable and self-contained, so they can simply be downloaded from the releases page and copied to the Ventoy filesystem partition on the USB device. Note that if you are running bootnext from a USB device on a Linux system then you will still need to ensure the efibootmgr command is installed on the system, just as you would when running a system-wide installation of bootnext.

With the binaries copied to the Ventoy partition, booting to the USB device is as simple as running bootnext usb from a terminal or command prompt in the directory containing the binaries, replacing bootnext with the appropriate binary for the system (e.g. ./bootnext-linux-amd64 under Linux or .\bootnext-windows-amd64.exe under Windows). As discussed in the Automatic privilege elevation section, you will be prompted for elevated privileges (i.e. a sudo password request under Linux or a User Account Control dialog under Windows) if you are not running bootnext as a user with administrative privileges.

For an even simpler workflow on Windows machines, you can create a batch file and place it in the same directory as the bootnext binaries:

@rem Note: replace the `amd64` suffix with the appropriate value under other CPU architectures
%~dp0.\bootnext-windows-amd64.exe usb

With this batch file in place, booting to the USB device is as simple as double-clicking the .bat file in Windows Explorer, and accepting the UAC prompt that is displayed.

Usage

Listing boot entries

Before making any changes to the UEFI configuration, you can list the available UEFI boot entries by specifying the --list flag:

bootnext --list

Querying the available boot entries can be useful in scenarios where you are unsure of exactly how a given boot entry is labelled, and can help to inform the pattern that you specif