Synopsis #
This FAQ provides concise answers to recurring OpenBSD questions. Detailed procedures remain in the relevant handbook chapters. The official OpenBSD FAQ and the OpenBSD manual pages remain authoritative for the operating system itself.
General Questions #
What Is the Current OpenBSD Release? #
OpenBSD 7.9 is the current release documented by this handbook. The official OpenBSD release page records the current release and release date. OpenBSD normally publishes a release approximately every six months.
Systems must be upgraded one release at a time. The Updating and Upgrading OpenBSD chapter explains the supported upgrade process.
Is This the Official OpenBSD FAQ? #
No. The OpenBSD Handbook is an independent practical guide. The official OpenBSD FAQ is maintained by the OpenBSD project and supplements the manual pages. This handbook adds longer workflows, background information, and operational examples.
Does OpenBSD Have a Code of Conduct? #
The OpenBSD project does not publish a standalone, project-wide page titled “Code of Conduct.” It does publish mailing-list netiquette that asks participants to be considerate, stay on topic, research questions before posting, respect differences of opinion, and avoid bullying or abusive language. Repeated violations can cause messages to require moderation or be dropped.
These rules describe participation on the official mailing lists. They should not be represented as a separate formal policy that the project has not published.
What Is OpenBSD? #
OpenBSD is a complete Unix-like operating system. Its kernel, base utilities, libraries, toolchain, and core services are developed and released together. This differs from Linux distributions, which combine the Linux kernel with userland components maintained by many separate projects.
OpenBSD and the other BSD systems share historical origins, but each is an independent operating system with its own kernel, userland, release process, packages, and technical priorities. Features, packages, commands, and configuration interfaces must not be assumed to exist on OpenBSD because they exist on FreeBSD, NetBSD, Linux, or another Unix-like system.
Is OpenBSD Suitable as a Desktop Operating System? #
Yes, when the hardware and required applications are supported. OpenBSD includes the X Window System and provides packages for common desktop environments, browsers, communication tools, and multimedia applications. Hardware support, accelerated graphics, power management, and the availability of particular commercial applications may be more restrictive than on mainstream desktop operating systems.
The Graphical Environments and Multimedia chapters describe the supported workstation components. Hardware compatibility should be checked before installation.
Where Should a New OpenBSD User Begin? #
Begin with the Installing OpenBSD chapter, then complete the checks described by afterboot(8) . The OpenBSD Basics chapter introduces accounts, permissions, processes, services, and packages.
Manual pages are the primary technical reference. help(1) identifies useful introductory manuals, and man(1) searches and displays them.
Security #
Why Is OpenBSD Considered Secure? #
OpenBSD applies security work across the complete base system. Examples include secure defaults, code auditing, privilege separation, reduced daemon privileges, exploit mitigations, and application sandboxing. These measures reduce risk; they do not make every installation or third-party application secure without correct administration.
The Security chapter covers privilege management and system policy. Current security fixes for a release should be installed with syspatch(8) .
What Are pledge(2) and unveil(2)? #
pledge(2) restricts the classes of system operations available to a process. unveil(2) restricts the filesystem paths that a process can access. A program must use these interfaces explicitly; installing a third-party application does not automatically give it a useful pledge or unveil policy.
Applications in the OpenBSD base system and ports collection may use one or both interfaces. The application documentation or source must be checked instead of assuming coverage.
Installation and Hardware #
How Is OpenBSD Installed from a USB Drive? #
Download the installation image for the intended architecture, verify it, write it directly to the USB device, and boot the target system from that device. Writing the image destroys the previous contents of the selected USB device, so the device name must be verified before the command is run.
The Installing OpenBSD chapter covers image selection, verification, media creation, disk layout, file sets, and the first boot.
How Are OpenBSD Installation Images Verified? #
Official mirrors provide SHA256 and the signed SHA256.sig file with each release. On OpenBSD, signify(1)
verifies the signature and the selected file. Verification on another operating system requires a compatible signify implementation and a trusted OpenBSD release key obtained through a trustworthy path.
The checksum alone detects accidental corruption but does not establish who produced the checksum file. Signature verification provides that authentication.
Which OpenBSD File Sets Should Be Installed? #
The kernel and base system sets are required. The compiler, manual, games, and X sets provide additional system components. A normal first installation should keep the installer’s default set selection; the OpenBSD project recommends all sets for new users.
Partial installations can omit libraries, manuals, build tools, or X components required by packages and administrative work. The installation chapter describes each set.
How Can Hardware Compatibility Be Checked Before Installation? #
Check the official page for the target hardware platform , then inspect the manual page for each important device driver. Product names alone are not sufficient because vendors can ship different chipsets under the same model name.
Booting current installation media is the most reliable non-destructive test of device detection. The resulting dmesg(8) output identifies detected hardware and the attached drivers.
Packages and System Maintenance #
What Is the Difference Between Packages and Ports? #
Packages are prebuilt software archives installed with pkg_add(1) . The ports tree contains build infrastructure that produces those packages from source. Packages are the normal choice because they are faster to install and are built with the expected OpenBSD configuration.
Ports are appropriate when a package must be built with a supported flavor or when port development is required. The Packages and Ports chapter describes both workflows.
What Is the Difference Between syspatch, sysupgrade, pkg_add, and fw_update? #
syspatch(8)
installs binary fixes for a supported release. sysupgrade(8)
upgrades the base system to the next release or to a newer snapshot when used as documented. pkg_add -u updates installed third-party packages. fw_update(8)
installs or updates firmware packages required by detected hardware.
These commands maintain different parts of the system and are not interchangeable. The Updating and Upgrading OpenBSD chapter gives the required order for a release upgrade.
What Is OpenBSD-current? #
OpenBSD-current is the active development branch. Binary snapshots are built from it, and interfaces or package dependencies can change before the next release. A -current system must be updated as a coherent base system with packages from a compatible snapshot.
It is appropriate for development, testing, or hardware support that requires current code. A normal system that prioritizes predictable maintenance should use a release and its supported fixes. The official -current FAQ records required reading and incompatible changes.
Storage, Networking, and Services #
How Do OpenBSD Disk Names and Partitions Work? #
Disk drivers assign names such as sd0. OpenBSD disklabel partitions use letters a through p; partition c represents the whole disk and is not a normal filesystem partition. MBR or GPT partitions form a separate outer partitioning layer.
The Storage chapter explains device naming, disklabel(8) , MBR, GPT, filesystems, encryption, and softraid.
How Is OpenBSD Configured as a Router or NAT Gateway? #
A router requires configured interfaces, IP forwarding, a valid routing table, and PF rules that permit and, when required, translate traffic. DNS and DHCP services are separate design choices rather than automatic parts of packet forwarding.
The Build a Simple Router and Firewall guide provides the complete workflow. PF configuration should be validated before it is loaded, and remote administration paths must be preserved when firewall rules change.
How Is a Minimal PF Firewall Configured Safely? #
Start with an explicit policy, permit the required management traffic, and validate /etc/pf.conf with pfctl -nf before loading it. Rule order, interface selection, address families, state tracking, and the difference between filtering and translation must all match the intended network design.
The PF chapter explains rules, tables, NAT, redirection, logging, testing, and troubleshooting.
How Are Services Managed with rcctl? #
rcctl(8)
enables and disables services, starts and stops daemons, and reads or writes service variables. Service configuration belongs in the daemon’s configuration file and in /etc/rc.conf.local values managed through rcctl.
The OpenBSD Basics
chapter covers the service-management workflow. Package-provided services use the same rcctl interface when they install a compatible rc.d script.
How Is SSH Access Secured on OpenBSD? #
OpenSSH is part of the base system. A safe configuration uses authenticated accounts, host and user keys, an appropriate PF policy, and validation before the daemon configuration is reloaded. Password and root-login policy must match the system’s recovery and administration requirements.
The OpenSSH Server
chapter covers keys, access controls, effective-configuration inspection, Match rules, file transfer, and troubleshooting.
Software Compatibility and Virtualization #
Can Podman Run Natively on OpenBSD? #
No. Podman is not available as a native OpenBSD package, and OpenBSD does not provide the Linux kernel interfaces required to act as a Linux container host. Podman can instead run in a Linux guest under vmm/vmd or on a separate Linux host controlled over SSH.
The Linux Compatibility chapter describes these alternatives.
Can OpenBSD Run Virtual Machines? #
Yes. The vmm(4) hypervisor and vmd(8) daemon run supported OpenBSD and Linux guests on compatible hardware. Guests use a serial console; features such as graphical consoles, hardware passthrough, live migration, and guest snapshots are not provided by the native stack.
The Virtualization chapter covers host preparation, guest configuration, storage, and networking.
Should a Custom OpenBSD Kernel Be Built? #
Normally, no. OpenBSD installations are expected to run a supplied GENERIC or GENERIC.MP kernel. These kernels are the supported configurations and receive the project’s regular testing.
Building the base system or a kernel from source is a development and testing task, not the normal update method. The official source-build FAQ documents the supported process.
How Should an OpenBSD Bug Be Reported? #
Use sendbug(1)
or follow the official bug-reporting instructions
. A useful report identifies the exact OpenBSD version and architecture, includes a complete dmesg, describes reproducible steps, records the actual and expected results, and includes relevant logs or diagnostics.
Security vulnerabilities have a separate reporting address documented on the official reporting page. Public mailing lists should not receive undisclosed vulnerability details.