Yesterday I wrote about how I ended up manually converting a FreeBSD 15 server and the eight jails it hosts to packaged base manually. I dashed that post off in a bit of a hurry because I knew that if I put it off until later I would probably never get around to it. 20 or so hours later, here’s a followup with some caveats and some tips on how to ensure the conversion goes well.
First, I should point out that the procedure outlined in yesterday’s post has no guardrails and should not be attempted unless you are very comfortable with FreeBSD system administration and willing and able to fix things if they go awry.
Second, perhaps I should elaborate on why I (mostly) skipped 15.0. We (the FreeBSD project collectively) have been working on packaged base for over a decade. At some point we thought 14.0 was when it would finally land, but that did not pan out. Then it was going to be 15.0, and there was a massive push to get everything ready, both in base and in pkg… and we still failed: packaged base in FreeBSD 15 is officially a technology preview, and FreeBSD 16 is when we will finally transition. As a result, the pre-release churn on the stable/15 branch was much higher than for a normal major release and a number of things fell through the cracks (including some that had nothing to do with packaged base). The bottom line is that I did not feel that 15.0 was production-ready when it came out, but I worked hard to get most of the issues I was aware of sorted out for 15.1, and I feel much better about 15.1 than I did about 15.0.
Third, I left out a couple of steps for brevity. Most importantly, the systems I converted were all on ZFS (eight jails and their host, as previously mentioned) which allowed me to take a snapshot of the root filesystem (which in a standard FreeBSD install includes /var and /usr/local) so if something had gone wrong I could simply have reverted to that, or rebooted to the boot environment that freebsd-update created when it upgraded my system to 15.1.
My case is also atypical because I have my own package repositories, including for packaged base. I converted the host to packaged base using the official FreeBSD-base repository first, then switched to my own before running pkg upgrade -fy; I then converted the jails directly to my own repository without passing through FreeBSD-base. This is somewhat risky because my base packages are built with non-standard options and do not match FreeBSD distribution sets perfectly, but I know exactly where they differ and how to deal with it.
Assuming your system meets the prerequisites (recently updated binary install of 15.0 or 15.1), the worst thing that can happen is that you forget to install a set and end up with unregistered files (e.g. you had tests.txz installed on your system but left out FreeBSD-set-tests from your pkg install --register-only command line). This is easily remedied, even after the fact, by registering that set and then removing it:
# pkg install --register-only -y FreeBSD-set-tests
# pkg remove -fy FreeBSD-set-tests
# pkg autoremove -y
But watch out! FreeBSD-set-tests depends on FreeBSD-set-base which depends on FreeBSD-set-minimal and FreeBSD-set-optional, so if you had already trimmed your system down to e.g. FreeBSD-set-minimal-jail you will have to remove those extra sets again:
# pkg remove -fy FreeBSD-set-{base,minimal,optional}
# pkg autoremove -y
Since we used --register-only, one thing that can’t happen is that pkg replaces a modified configuration file with its stock version, saving the modified version with a .pkgsave extension. On the other hand, it is possible that pkg upgrade -fy fails to install a file because a directory of the same name exists. I’ve had that happen exactly once due to a discrepancy in /usr/src (I’m not sure why but freebsd-update(8) has never been entirely reliable when it came to patching the source tree). So you may want to run the following after converting:
# find -xs / -name '*.pkgnew'
If you get any hits, there will usually be an empty directory of the same name (without the .pkgnew suffix) which you can remove before manually renaming the file.
Another useful post-conversion command is:
# find -xs / \( -name var -prune \) -or -not -type d -print0 |
xargs -0 pkg which 2>&1 | grep 'not found' | less
This will give you a list of files on the root filesystem which pkg does not know about. You should be able to identify most of them (configuration files, the trust store, miscellaneous generated files such as /etc/spwd.db).
Finally, look for empty directories on the root filesystem:
# find -xs / -type d -empty
There will usually be a few in /usr/lib/debug and /usr/tests which you can remove if you did not choose to install debugging symbols or tests.
And my final piece of advice, if you want minimum hassle at the cost of having the machine do some pointless work that immediately gets reverted, just register all the sets, then remove the ones you don’t have or don’t want. You’ll get errors from autoremove about missing files, but that (and the few dozen extra seconds the process will take) is about the only downside.