Daemonic Dispatches

Portifying FreeBSD/EC2 startup scripts

There was one complication which had me stuck for a while: Installing the port into a new disk image. The usual solution to this problem is to chroot into the image; but since this I'm doing this as part of a release-building process, the binaries in the image under construction are normally from a newer version of FreeBSD than the kernel running from the "host" FreeBSD — which means they might rely on new system calls and fail when those aren't available. As a result, it's necessary to install the sysutils/ec2-scripts port without using anything from inside the image under construction.

I spent several hours struggling with this and asking FreeBSD developers for ideas, and was about to give up on finding a good solution and instead start writing code to perform a "fake" package install — i.e., install the requisite bits and packaging metadata "by hand" rather than using the mechanisms in the FreeBSD ports tree — when Scott Long came up with the solution: Use unionfs to mount parts of the guest on top of the host, then install the port on the host — at which point they end up in the right places in the guest. Or in code:

# mount_unionfs /mnt/image/usr/local /usr/local
# mount_unionfs /mnt/image/var/db/pkg /var/db/pkg
# cd /usr/ports/sysutils/ec2-scripts && make install clean
# umount /var/db/pkg
# umount /usr/local

Of course, this trick isn't always going to work for creating disk images with preinstalled packages — if you're building an embedded system running a different architecture, this would install binaries built for the host's architecture instead; the FreeBSD ports tree unfortunately does not have any mechanism for cross-building packages yet. In the case of the FreeBSD/EC2 startup scripts, however, it works perfectly — there aren't any binaries to build at all, never mind cross-architecture problems.

What's left for FreeBSD/EC2? Two kernel patches (one to work around an EC2 bug; one to work around a FreeBSD/Xen/Linux networking incompatibility) and either adding the XENHVM kernel to the FreeBSD release builds or merging the XENHVM bits into the GENERIC kernel; then FreeBSD/EC2 will simply be "release bits plus sysutils/ec2-scripts package plus configuration files". It isn't going to happen for FreeBSD 9.1, but I think the odds are quite good that once FreeBSD 9.2 comes around, FreeBSD/EC2 will be just as much "official FreeBSD" as what you get from any other FreeBSD server hosting service.