blowing up OpenBSD

Ooops.

I recently upgraded my OpenBSD servers to 6.8, and made a bit of a silly mistake.

The problem is this: the automated upgrade command, sysupgrade, requires at least 1.1G free on /usr. Older standard OpenBSD installations, which I generally used, set up a 2G partition there (current versions default to 3G). The partition gets used for many things, including additional packages. It is also used by the relink feature, which ensures each computer running OpenBSD has its own unique version of the OS, another trick to make hacking the system more difficult. In consequence, it is very easy to leave insufficient free space for sysupgrade.

image: esch/uelzecht

There are alternatives to sysupgrade, but, ignoring virtual machines, they require physical access to the computer, which isn’t always possible. Thus, in some cases, I had to make free space available on a machine before I could to upgrade it.

The relink feature uses approaching 500M of space; that’s a quarter of the default /usr. I decided to create the necessary free space by moving it elsewhere.

I couldn’t find where the relink feature is configured (I since discovered it’s hardcoded in /etc/rc), so I decided to set up a soft link to a directory on /var instead. That was a mistake.

I moved the directory to another partition with ample disk space available, and make a soft link between the two. In normal circumstances, I thought, that should be fine, so long as the operating system’s relinker is willing to follow links.

The problem came when I ran sysupgrade. It downloads and runs a special installer version of OpenBSD. This mounts its own versions of the standard mounts in memory, & mounts the computer’s standard partitions under /mnt. Unfortunately for me, it also relinks the newly installed operating system.

The installer’s relinker uses the relink directory, as usual. Unfortunately, because this was now a soft link, it no longer pointed to the computer’s normal partition, mounted by the installer at /mnt/var/…. Instead, it pointed to /var/… on the installer disk! In consequence, when sysupgrade attempted to relink the operating system directory, it started filling up space on its own installation drive, not on the target operating system’s standard drive. This, unsurprisingly, filled up, and the installer expressed unhappiness.

Fortunately for me, I could still get to the upgrade shell, and fix the problem. None the computers that required remote upgrade built anything, so I did so by remounting the default compilation directories (/usr/src, /usr/obj) to the relink directory and for anything else that filled up /usr.