Daemonic Dispatches

Some late-breaking FreeBSD 14 breakage

I assumed the role of FreeBSD Release Engineering Lead a few days ago, and one of my first duties in the role was to write and send out the FreeBSD 14.0-RELEASE announcement. (To be clear: Glen Barber did all of the work of getting the release ready; the final bits had already been copied out to mirrors at the point that I took over.) FreeBSD 14 is a great release, but there are a few last-minute issues which deserve to be documented — probably somewhere on the FreeBSD website, but I can post to my blog much faster and hopefully we'll get these onto the FreeBSD website later.

You need to freebsd-update fetch install before you upgrade

Moving from FreeBSD 13 to FreeBSD 14 we have the unusual case of a file in FreeBSD 13 having the same name as a directory in FreeBSD 14. This is not something I ever imagined happening when I wrote freebsd-update, and my original code didn't handle it (I assumed that I could create everything new before deleting old bits). This was fixed via an Errata Notice but if you haven't installed the fix yet then using freebsd-update to upgrade to 14.0 will break.

FreeBSD Update reports 14.0-RELEASE approaching its EoL

The FreeBSD Update metadata includes the release End-of-Life date; but the wrong value got inserted when the FreeBSD Update bits were put together for FreeBSD 14.0-RELEASE. Just ignore the warning; it will go away with the value being corrected along with the first Security Advisory or Errata Notice.

Be careful when merging master.passwd

The default shell for root changed from csh to sh in FreeBSD 14. When you upgrade to FreeBSD 14, freebsd-update will prompt you to merge changes to /etc/master.passwd. Don't just take the new password line for root since it doesn't have a password. Keep your existing line and change the shell (or not, if you prefer to stick with csh).

No PINE64 SD Card image

One of the SD Card images we normally build is for PINE64. The build failed — we're not exactly sure why, but offset.inc somehow ended up being full of NUL bytes — but we decided to go ahead without that image. The PINE64-LTS image did build.

EC2 AMIs can't handle binary user-data

In order to support IMDSv2, the EC2 boot scripts were changed from using fetch(1) to get data from the EC2 Instance Metadata Service to using the newly written aws-ec2-imdsv2-get utility. Unfortunately a bug in that utility resulted in it assuming that data from the IMDS is always UTF-8 strings — which is usually true, but breaks if you provide binary user-data. In particular, if you generate a tarball and pass it to configinit it will break.

If you find my work on FreeBSD useful, please consider sponsoring my work. At a certain point, time and money are fungible, and the combination of maintaining the FreeBSD/EC2 platform and my newly acquired release engineering duties adds up to a significant draw on my time.

blog comments powered by Disqus