Check Hardware Compatibility Before Installing

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.

Identify the Required Architecture #

Start with the OpenBSD platform list . Confirm that the processor architecture is supported and read the matching installation notes. A machine advertised as ARM, for example, is not automatically supported merely because OpenBSD supports the arm64 architecture. Board firmware, interrupt controllers, storage, and other platform components must also be supported.

For an existing Unix-like system, record the processor and attached PCI and USB devices with the host system’s native inventory tools. Preserve numeric vendor and product identifiers where possible. Marketing names are often reused for different chipsets.

Match Devices to OpenBSD Drivers #

OpenBSD manual pages in section 4 document supported hardware interfaces. Search the Handbook manual-page service for the controller or chipset, then inspect the driver’s HARDWARE section when present.

The most important device classes are:

  • storage controllers and the boot disk;
  • wired and wireless network interfaces;
  • graphics hardware and display outputs;
  • keyboard, touchpad, and other input devices;
  • audio controllers;
  • suspend, resume, battery, and backlight interfaces;
  • USB controllers and required peripherals.

A device that requires downloadable firmware still needs a kernel driver. Firmware can complete support for an attached driver, but it cannot add a missing driver.

Compare Complete Kernel Messages #

The kernel records detected hardware in the boot-time message buffer. On OpenBSD, dmesg(8) displays this information.

$ dmesg > dmesg.txt

Search current, complete dmesg reports from the same or closely related hardware in the NYC*BUG dmesgd archive . Treat an archived report as evidence for the listed OpenBSD release and exact devices, not as a permanent certification of the product family.

The following distinctions are important:

  • A device attached to a named driver has at least kernel-level recognition.
  • A device reported as not configured has no attached driver in that kernel.
  • The absence of an error line does not prove that higher-level functions such as suspend or accelerated graphics work.
  • A report from an older release may not describe the current release.

Boot Current Installation Media #

The most reliable pre-installation test is to boot current, verified installation media without modifying the internal disk. The installer runs from the bsd.rd ramdisk kernel and provides a shell.

At the installer prompt, enter S for a shell. Record the complete kernel messages and inspect the detected interfaces.

# dmesg
# ifconfig
# sysctl hw.sensors

The installation chapter describes verified media creation. Do not start disk partitioning merely to test hardware recognition.

Evaluate Network and Firmware Requirements #

Use ifconfig(8) to identify attached network interfaces. If the wireless driver requires firmware that is not present on the install media, plan one of these bootstrap paths:

  • temporary wired Ethernet;
  • a supported USB Ethernet adapter;
  • firmware copied to removable media from another computer;
  • a prepared install image containing the required firmware for the installed system.

The detailed offline procedure is described in Bootstrap Wi-Fi Firmware Without Ethernet .

Decide Whether the System Is Suitable #

Classify each required function as confirmed, unconfirmed, or unsupported. Installation should proceed only when unsupported items are either nonessential or have a tested replacement.

For a server, storage, console, and networking may be sufficient. A laptop normally also requires usable graphics, input, wireless networking, audio, battery reporting, and acceptable suspend and resume behavior. A workstation may require particular display outputs or acceleration that a simple installer boot cannot validate.

Preserve the hardware inventory, installation-media version, and dmesg with the installation notes. These records make later regressions and support requests reproducible.

Report a bug