Synopsis #
This chapter documents the current status of Linux binary compatibility on OpenBSD. It describes the historical linux(4) subsystem that once enabled Linux ELF binary execution, the reasons for its removal, and modern alternatives for accessing Linux-only software, including virtualization, remote execution, and native packaging.
Historical Note #
OpenBSD previously supported partial Linux compatibility through the linux(4) kernel subsystem. This layer enabled execution of select Linux ELF binaries, primarily for compatibility with older commercial or binary-only software. It required the presence of Linux-shared libraries and emulated system calls within a controlled environment.
The feature was rarely used and became increasingly difficult to maintain. It was formally removed from the kernel in OpenBSD 6.3.
Rationale for Removal #
The linux(4) implementation was removed for the following reasons:
- Maintaining binary compatibility with a foreign ABI conflicted with OpenBSD’s focus on correctness, simplicity, and security.
- Most software that once required Linux compatibility has become open source and is available natively.
- The compatibility layer required ongoing effort to track changes in Linux behavior and libc interfaces, with little user demand.
The subsystem was considered obsolete and unmaintainable in light of modern application and system design.
Alternatives and Workarounds #
Native Packages and Ports #
A large number of software packages initially developed for Linux are now available as native OpenBSD ports. These include:
- Desktop software: Firefox, Chromium, LibreOffice
- Development tools: GCC, Rust, Go
- Networking tools: WireGuard, Docker clients, Kubernetes utilities
To search for available software:
$ pkg_info -Q firefox
$ pkg_info -Q libreoffice
If a package is not available, it may be possible to build it from source, assuming it does not rely on Linux kernel-specific interfaces.
Virtualization #
Linux applications requiring a full Linux environment can be executed inside a virtual machine using OpenBSD’s built-in hypervisor framework (vmm(4) and vmd(8)).
Instructions for setting up virtual machines with Linux guests are provided in the Virtualization chapter.
Podman on OpenBSD #
Podman is not available as a native OpenBSD package, and upstream Podman does not support OpenBSD as a container host. Linux containers depend on Linux kernel interfaces that an OpenBSD host does not provide. Commands such as pkg_add podman therefore do not install a native container engine.
Podman can run inside a Linux guest under vmm(4) and vmd(8) , or on a separate Linux host. The OpenBSD system can control that environment over SSH without requiring a local Podman client:
$ ssh container-host podman ps
$ ssh -t container-host podman run --rm -it docker.io/library/alpine
Network services published by the container remain services of the Linux guest or remote host. Access from OpenBSD depends on the virtual-machine or remote-host network configuration, not on a native OpenBSD container layer.
Remote Execution #
For workflows involving Linux-only software, remote execution on a Linux host may be a practical solution. This can be done over SSH with optional X11 forwarding:
$ ssh -X user@linuxhost gimp
To run console-only applications:
$ ssh user@linuxhost ffmpeg -i input.avi -vf scale=640:360 output.mp4
Files may be transferred using scp or rsync as needed.
The same method applies when the remote Linux environment is a virtual machine or a container host.