Otto Moerbeek (
posted to misc@
a useful summary of the state of play of FFS2
in the 6.7 release (and, to some extent, -current).
In his mail, Otto clarifies some things about the latest release:
- In OpenBSD 6.7, ffs2 is the default for new filesystems (with some exceptions).
- In OpenBSD 6.7, if you create a new filesystem manually (using newfs(8)) you will still get an FFS1 filesystem unless you force -O2 or if the filesystem will be larger than 1 TB.
In a commit touching quite a few files, Theo recently renamed the installation images from
Date: Sun, 17 May 2020 11:04:29 -0600 (MDT)
From: Theo de Raadt <firstname.lastname@example.org>
Subject: CVS: cvs.openbsd.org: src
Module name: src
Changes by: email@example.com 2020/05/17 11:04:29
bin/dd : dd.1
Change install images called *.fs to *.img. These are UFS filesystem images,
but additionally have a bootblock in the first 8K (since UFS does not use that
space). There are some UEFI direct-from-internet bootloaders that require
the name *.img. So this makes things more convenient for those, while keeping
it consistant in all architectures.
ok kettenis beck kn
This means that with recent snapshots, you should use the .img file to prepare your installation medium, where you were previously using the .fs file. It also means that you can install 'direct-from-internet' on these fancy UEFI machines! Note that if you want to install the OpenBSD 6.7 release, you still need to use install67.fs.
The OpenBSD project has released OpenBSD 6.7
, marking the 48th release of our favorite operating system. The announcement message
and the release page
both have detailed information.
These are some highlights of the improvements in the present release:
- For new installs on nearly all architectures the default file system is now FFS2, sporting 64-bit timestamps and block counters
- There are numerous SMP improvements, including unlocking of several system calls
- Hardware support in all architectures is much improved and expanded, with a number of new drivers including the iwx(4) driver for new Intel WiFi devices as well as significant expansion of arm64 and armv7 hardware support.
- Enabled rpki-client(8), to support Origin Validation in BGP-speaking routers in the base install.
- New versions of programs and subsystems maintained as part of OpenBSD but widely reused elsewhere:
See the release page and the daily changelog for a full list of changes since the previous release.
Those upgrading from version 6.6 should read the
Thanks to the developers for all the good work that goes into each release! To support further work on OpenBSD, please see the donations page for ways to contribute even if you can not offer up code yourself.
In a set of commits to the tree on Saturday, Mark Kettenis (
kettenis@) added the early beginnings of support for the 64-bit PowerPC platform:
Date: Sat, 16 May 2020 11:11:14 -0600 (MDT)
From: Mark Kettenis <firstname.lastname@example.org>
Subject: CVS: cvs.openbsd.org: src
Module name: src
Changes by: email@example.com 2020/05/16 11:11:14
sys/arch/powerpc64/compile: Makefile Makefile.inc
sys/arch/powerpc64/conf: GENERIC Makefile.powerpc64
sys/arch/powerpc64/include: _types.h atomic.h bus.h cdefs.h
conf.h cpu.h db_machdep.h
disklabel.h endian.h exec.h fpu.h
frame.h intr.h limits.h mutex.h
param.h pcb.h pmap.h proc.h psl.h
ptrace.h reg.h signal.h softintr.h
spinlock.h tcb.h vmparam.h
sys/arch/powerpc64/powerpc64: autoconf.c conf.c cpu.c disksubr.c
genassym.cf locore.S locore0.S
machdep.c pmap.c process_machdep.c
softintr.c sys_machdep.c syscall.c
Planting the first seed for OpenBSD/powerpc64.
As support for additional hardware platforms brings opportunities to find (and fix) bugs on other, more established environments, this is definitely an interesting development. Of course it is still currently very much in its infancy, so don't drag out your POWER9 systems just yet, unless you're ready to roll up your sleeves and get some diffs submitted. Thanks to Mark for working on this port!
After our article on TLS 1.3 server support in LibreSSL, we have decided to upgrade the machine running the undeadly website to newer LibreSSL.
Since earlier today the site supports TLS 1.3. Undeadly still gets an
In a post to the ports@ mailing list, Landry Breuil (
landry@) shared some of his notes on using qemu guest agent on OpenBSD kvm/qemu guests. He made a few enhancements for Undeadly:
In a post to
the availability of a
patchset for OpenBSD:
A while ago I wanted to learn more about OpenBSD development. So I
picked a project, in this case WireGuard, to develop a native client
for. Over the last two years, with many different iterations, and
working closely with the WireGuard's creator (Jason [Jason A. Donenfeld - Ed.], CC'd), it started
to become a serious project eventually reaching parity with other
official implementations. Finally, we are here and I think it is time
for any further development to happen inside the src tree.
From the WireGuard® point-of-view, this is an official patchset.
full thread on
for more detail.
With the following
Joel Sing (
jsing@) enabled the
TLSv1.3 server code (in
LibreSSL) in -current:
Module name: src
Changes by: firstname.lastname@example.org 2020/05/11 12:19:19
lib/libssl : ssl_locl.h
Enable the TLSv1.3 server.
ok beck@ tb@
The client code was already enabled in -current (and will be in the
Thanks to Joel, Bob Beck (
Theo Buehler (
tb@), and others for the hard work!
While many of us have been busy social distancing, OpenBSD development work
Noteworthy things not previously reported here include:
- The OpenBSD version has moved to 6.7-beta
- Some 11 syscalls have been
since the 6.6 release.
- FFS2 has been made the default filesystem for new installs on most platforms.
- The rpki-client web site has been launched.
- Supported hardware on the arm64 platform has widened further, including support for
Pine64 Pinebook Pro and Rasperry Pi 4.
- The default compiler on the macppc platform has been switched to
- Ports work has entered slowdown in the move towards release.
Developer Otto Moerbeek (
FFS2. He writes in with the below article, to give us a little insight into the challenges he faced while working on this.
FFS2 filesystem support has been in OpenBSD for quite a while. FFS2
has a few advantages above FFS1: large partition support, 64-bit
timestamps, faster newfs(8) and faster fsck(8), but it is only used
for large (> 1TB) filesystems at the moment. The only drawback is that
its meta-data overhead is a bit larger than FFS1 because of 64-bit
instead of 32-bit blocknumbers and timestamps.
I decided that it was time to start using FFS2 in as many places as
possible, and that includes booting from it. Booting is an area where
there are quite large differences between the various platforms OpenBSD
supports. The boot code interacts with the platform-specific firmware
and the bootstrap process uses different vendor-specific mechanisms.