FreeBSD 14.2 wants to woo Docker fans, but still struggles with Wi-Fi

FreeBSD 14.2, the latest point release of the most widely used of the BSDs, brings some new features to tempt Docker fans.

FreeBSD 14.2-RELEASE appeared on Tuesday. This is the latest minor release of version 14, which means it's time to start thinking about upgrading from 14.1. That appeared last June and it's due to reach the end of its life three months after 14.2 – so the clock is ticking. FreeBSD 14.0 reached its official end of life at the start of October, and isn't getting updates any more.

This version is dedicated to the late Michael J Karels, a long-time contributor to the BSD project since 2.9BSD on the PDP-11. He was the system architect of 4.3BSD, one of the most influential Unix releases of all time, and also of BSD/OS, the commercial system that was the first BSD for x86 PCs.

The FreeBSD console, old-style as a lot of BSD folks seem to prefer – click to enlarge

Version 14.2 includes OpenZFS 2.2.6, as well as OpenSSL 3.0.15, which both came out three months ago. The full 14.2 release notes list all the changed and updated components, and the README has some useful starting points. During installation, an interesting new feature is the ability to automatically download and install any necessary firmware, such as for network adapters.

Along with being available in multiple versions and formats for four primary architectures in nine variants, this version has significantly improved container support. Not because it now supports containers – FreeBSD has done that, in the form of Jails, for 24 years now. It first appeared in version 4 back in 2000, four years before Solaris got Zones.

The difference is that FreeBSD now can handle containers in ways that are compliant with OCI specifications. The Open Containers Initiative is a Linux Foundation-backed inter-company alliance that's standardizing how containers are packaged, delivered, deployed, and managed. These are the methods that are most familiar to people in the vast industry around containers on Linux.

Podman is an all-FOSS, daemonless container management system that's compatible with Docker, and the x86-64 and Arm64 editions of FreeBSD 14.2 now contain a Podman-compatible toolkit for handling OCI containers on FreeBSD. As that site says:

For clarity, no, unless you use something like Linuxulator, this does not mean that you can take a Linux container and run it directly on FreeBSD. Nor does it mean that you can directly run FreeBSD in a container on top of Linux. In case you need a quick refresher why not, The Reg FOSS desk explained how containers work in part three of our brief history of virtualization way back before Docker was a glint in some VC's eye. It is possible to run containers from one OS on top of a different OS, but it involves some shenanigans with virtual machines. This, for instance, is why and how so many people use Alpine Linux and don't even know. Instances of Alpine in VMs are how Docker Desktop runs Linux containers on Windows and macOS.

Old school X11 on shiny new FreeBSD: a window manager and a bunch of xterms. Who needs more? – click to enlarge

For now, the OCI support is all about running FreeBSD containers on top of FreeBSD itself. FreeBSD does include a Linux emulator, called the Linuxulator, and as well as running some individual Linux binaries on it, you can also run the userland of an existing distro on the Linuxulator, a setup called a Linux Jail. As an example, Stefano Marinelli – about whom we've written before – has documented running Alpine in a jail.

FreeBSD's OCI support is still quite new, and for now, you do still have to run it as root – even though rootless operation is one of Podman's selling points on Linux. This will probably change in time, and there is the interesting theoretical prospect of running Linux containers directly on FreeBSD.

But for now, these are still the same existing, time-tested FreeBSD-on-FreeBSD containers. The difference is that rather than using FreeBSD's own unique commands to manage your jails, you can use Docker-compatible syntax, Docker-compatible container file formats, standard JSON config files, and so on.

• FLTK hits 1.4, arrives speaking Wayland and with better HiDPI support
• Apple macOS 15 Sequoia is officially UNIX. If anyone cares...
• Version 7.6 – the 'OpenBSD of Theseus' – released
• Switching customers from Linux to BSD because boring is good

On one hand, this will make life easier for experienced Docker-herders who might be migrating to FreeBSD, but on the other, it will ease integration with existing tooling that knows how to manage standard tooling such as Podman, Buildah for generating OCI container images, and Skopeo for working with remote container registries, which can retrieve images from repos, copy from one repo to another, inspect images, and so on. Notably, at this year's EuroBSDCon, we discovered that managing FreeBSD boxes often uses Ansible.

Soon, managing containers on FreeBSD servers using existing tooling aimed mainly at Linux should become much easier.

We upgraded our FreeBSD testbed machine (a Lenovo ThinkPad T420) to the new release. This old laptop had a bumpy ride going from FreeBSD 13.3 to 14. Although it only has the CPU's built-in Intel HD 3000 GPU, upgrading FreeBSD removed part of the Intel DRM driver and the Slim display manager, so X11 stopped working. We managed to fix that a while ago, but before trying 14.2, we had to upgrade the machine from 14.0 to 14.1:

freebsd-update -r 14.1 upgrade
freebsd-update install

Then we rebooted, ran freebsd-update install a second time, then rebooted again. The upgrade went perfectly smoothly and everything worked fine. We then repeated the process for 14.2:

freebsd-update -r 14.2 upgrade
freebsd-update install

That didn't go so well, and although the machine still works, the console doesn't: the screen goes blank when the kernel initializes the GPU. It's possible to log in blind and type startx to launch Xfce 4.18, but we had to SSH into the box to find that it was still running. (Apparently, it's a known issue with drm-kmod, which does not excuse it in our book.) The claims we've heard from many enthusiastic FreeBSD evangelists that upgrades are so safe that they're almost boring don't apply if you're running a laptop with a GUI, sadly.

If you prefer a few more mod cons, there are a choice of desktops available, installable via the optional 'desktop-installer' tool – click to enlarge

A couple of months ago we wrote that the FreeBSD Foundation had won some funding to improve the desktop experience. We hope it spends the money wisely because it's badly needed. We also noted that although Wi-Fi is working fine, it's only able to see and connect to our 2.4 GHz home network. 5 GHz support is still missing. An attempt to install a fresh copy onto our testbed Thinkpad W520, into a partition alongside Windows 10 and two Linux distros, failed completely, on the other hand. In a multi-boot setup, even the latest version does not play well with others, it seems.

We had more success installing it in a VirtualBox VM. A tip that we learned at the EuroBSDCon is that although VirtualBox still says that UEFI support is for "special OSes only," it's important for FreeBSD. Apparently, it has some known problems booting from ZFS on BIOS systems on disks partitioned with MBR. Picking UEFI and allowing the OS to choose its own partitioning scheme worked perfectly, and gave us a running system with no problems on a GPT-partitioned 16 GB virtual drive.

FreeBSD 14.2 has some useful new features that should help it to integrate better with existing enterprise infrastructure, while laying the groundwork for some exciting possibilities in future. But despite its improved firmware handling, don't expect miracles in this point release. It's still not an easy OS to install compared to contemporary Linux systems, and for now, Wi-Fi support remains disappointing. ®