Dual-Boot OpenBSD on a UEFI System

Synopsis #

Dual boot places OpenBSD and another operating system on the same physical computer. This arrangement combines partitioning, firmware, encryption, and recovery risks. A backup and a tested recovery path for both systems are prerequisites, not optional final steps.

This guide maintains one conservative scope: OpenBSD on an amd64 system that already boots another operating system in UEFI mode from a GUID Partition Table (GPT) disk. It does not prescribe a universal Windows, Linux, legacy BIOS, Apple, or third-party boot-manager procedure. Those components change independently and retain their own recovery requirements.

Choose Whether Dual Boot Is Appropriate #

Dual boot is useful when OpenBSD needs direct access to the computer’s hardware and only one operating system runs at a time. A dedicated disk is preferable to sharing one disk because the partition and recovery boundaries are clearer. A virtual machine is preferable when simultaneous operation, snapshots, or frequent switching matters more than direct hardware access.

Before changing the disk, confirm:

  • the exact computer architecture and firmware mode;
  • whether full-disk encryption protects the existing system;
  • whether the vendor recovery process expects a particular partition layout;
  • how the existing operating system will be recovered if its boot entry disappears;
  • how OpenBSD installation media will be booted independently;
  • where a complete external backup is stored and how it was tested.

Do not resize an encrypted or vendor-managed filesystem with an unrelated partition editor. Use the existing operating system’s supported tool to shrink its own filesystem and partition.

Record the Existing Layout #

Record the firmware boot entries and disk layout from the existing operating system before mutation. Also create recovery media for that system.

After booting verified OpenBSD installation media, choose (S)hell and inspect the disks with sysctl(8) , dmesg(8) , and fdisk(8) :

# sysctl hw.disknames
  # List recognized disks and their disk identifiers
# dmesg | grep -E '^(sd|wd)[0-9]'
  # Match device names to reported hardware
# fdisk -v sd0
  # Display the GPT without modifying it

sd0 is an example only. Stop if the installer and the existing operating system do not describe the same physical disk and unallocated region.

Create Free Space from the Existing System #

Shrink the existing filesystem and its containing partition from the operating system that owns them. Leave the resulting space unallocated. Do not create an OpenBSD filesystem, Linux filesystem, or generic data partition in that area.

Reboot the existing operating system after the resize and run its supported filesystem check. Confirm that it still starts normally before beginning the OpenBSD installation.

Install OpenBSD into the Unallocated Region #

Boot the OpenBSD installer in UEFI mode. A firmware menu can expose the same device twice, once for UEFI and once for legacy boot. Select the UEFI entry.

At the disk stage, identify the disk again and preserve every existing GPT partition. Allocate only the previously verified unallocated region to OpenBSD. disklabel(8) then divides the OpenBSD area into OpenBSD filesystems.

The installer and the official installation FAQ remain authoritative for the current prompts. Installing OpenBSD covers media verification and the installation sequence.

The Handbook’s full-disk encryption procedure initializes an entire selected disk and must not be followed on a disk shared with another operating system. Partition-preserving encrypted dual boot requires a separate, architecture-specific procedure and is outside this guide. Use a dedicated disk when the OpenBSD installation requires that encryption workflow.

Stop rather than write the disk when:

  • the free-space size or offset differs from the recorded plan;
  • an existing EFI System Partition, recovery partition, or data partition would be removed;
  • the installer appears to have booted in a different firmware mode;
  • the target disk name changed and cannot be matched to the recorded hardware.

Select an Independent Boot Path #

OpenBSD installs UEFI boot files for its own system. Firmware implementations differ in how they discover, name, retain, and order boot entries. First prove that both operating systems can boot through the firmware’s one-time boot menu. This avoids making either operating system’s boot manager an immediate dependency of the other.

If a third-party boot manager is later adopted, use its current documentation and retain the firmware-menu path. Do not copy a fixed GRUB, Windows BCD, or firmware command from an older guide without confirming the installed versions and exact EFI paths.

Operating-system updates and firmware updates can change boot order. A missing menu entry does not by itself mean that either filesystem was erased.

Verify and Document Both Systems #

Boot OpenBSD and record the final GPT and disklabel without editing them:

# fdisk -v sd0
  # Record the shared GPT
# disklabel sd0
  # Record the OpenBSD disklabel

Then boot the other operating system and verify its filesystems, encryption, network access, and recovery tools. Record:

  • the firmware key used to open the one-time boot menu;
  • the OpenBSD disk and partition boundaries;
  • the location of both recovery media sets;
  • the procedure for restoring each boot entry;
  • the location and last successful test date of the backup.

Recover Without Repartitioning #

When one entry disappears, use the firmware menu or recovery media before editing the partition table. Confirm that the GPT and filesystems still exist. Repair only the failed boot component with that operating system’s supported procedure.

Do not initialize the disk, recreate the GPT, or format a partition merely because a firmware entry is missing. If the GPT itself differs from the recorded layout, stop write operations and recover from verified backups or specialist tooling.

Report a bug