Installation and First Boot on OpenBSD Handbook

Complete the First 30 Minutes After Installation

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis #

A new OpenBSD installation is usable immediately, but several administrative tasks should be completed before it enters service. This guide establishes a conservative baseline: verify the installed system, read the initial administrative mail, install firmware and errata, update packages, test a non-root administrator account, review enabled services, and record enough information to support recovery.

Complete remote-access changes from a local console or provider console. Do not disable an existing access method until its replacement has been tested in a separate session.

Check Hardware Compatibility Before Installing

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis #

OpenBSD hardware support is determined by the exact processor architecture and device interfaces, not by a computer’s marketing name. A useful compatibility check therefore identifies the architecture and device controllers, confirms the relevant OpenBSD drivers, boots current installation media, and preserves the resulting kernel messages.

No compatibility list can guarantee that every function of a system will work. Graphics acceleration, wireless networking, audio, suspend and resume, brightness controls, and external displays must be evaluated separately.

Bootstrap Wi-Fi Firmware Without Ethernet

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis #

Some wireless devices require firmware that OpenBSD cannot distribute with the installation media. fw_update(8) normally downloads the required signed firmware after installation, but that method first requires a working network connection.

When no wired connection is available, obtain the exact firmware archive on another computer, copy it to OpenBSD-readable removable media, and install it locally with fw_update. Firmware enables a supported driver; it does not add support for hardware that lacks an OpenBSD driver.

Run OpenBSD as a Virtual Machine Guest

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis #

OpenBSD can run as a guest under several third-party hypervisors. The installation procedure remains the standard OpenBSD procedure, but the hypervisor controls firmware, virtual disks, network adapters, consoles, power events, and snapshot behavior.

This guide defines provider-neutral choices and verification steps. Hypervisor product interfaces change frequently and are not reproduced here. Confirm the current OpenBSD release and the selected virtual devices before relying on a guest for production work.

Install OpenBSD on a VPS or Cloud Server

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis #

A virtual private server can install OpenBSD when the provider offers a supported architecture, compatible virtual devices, persistent storage, and a usable console or rescue path. The provider may supply an OpenBSD image, permit a custom ISO, or allow the OpenBSD ramdisk kernel to be booted from an existing rescue environment.

This guide describes the common workflow without endorsing a provider or reproducing a provider control panel. Record the provider’s current network and recovery requirements before changing the boot disk.

Install OpenBSD with Full-Disk Encryption

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis #

OpenBSD implements bootable disk encryption with the CRYPTO discipline of softraid(4) . The encrypted volume appears as another sd device. The installer places the OpenBSD filesystems on that virtual disk while the unencrypted physical disk contains the partitioning and softraid metadata needed to start the boot process.

This procedure destroys the selected disk. It uses an amd64 or another architecture on which CRYPTO volumes are bootable. Confirm boot support in softraid(4) and read the platform’s INSTALL.<arch> file before starting.

Dual-Boot OpenBSD on a UEFI System

Mon, 01 Jan 0001 00:00:00 +0000

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 covers one setup: 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 need their own recovery procedures.

Automate OpenBSD Installation with Autoinstall and PXE

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis #

autoinstall(8) answers installer questions from a response file. A network-booted amd64 client normally obtains an address and boot metadata through DHCP, loads pxeboot and bsd.rd through TFTP, and retrieves a host-specific or generic response file through HTTP.

An unattended installer can erase a disk and a response file can contain authentication material. Build this workflow only on a controlled provisioning network, identify every client by verified hardware information, and retain console access until the installed system has been validated.