Installing DragonFly on a dedicated Hetzner server

Last week I ordered a dedicated Hetzner server. It took one click and 28 EUR less in my wallet and just a few minutes later the server was up and running eagerly awaiting my commands.

Hetzner servers come with a rescue system that you can enable via the web interface. After a reboot you can then ssh into the rescue system to perform the installation remotely. Unfortunately they do not officially support DragonFly BSD. Despite this annoying fact, my new Hetzner server now runs happily the most recent version of DragonFly. If you want to know how, keep on reading.

Install instructions

To enter the rescue system, you first have to enable it in the web interface. It then shows you a password. Remember this password, as you need it to log in via ssh. I think you have to manually reset the server, so that it enters the rescue system. Of course this can also be done from the web interface. You can now log in to the rescue system with a simple ssh root@your-server-ip followed by entering the remembered password.

To install DragonFly on that server we basically have to solve two problems:

But before we solve these two problems, the first thing I want to do is to get a bit more information about the server’s hardware. So we select the Linux rescue system (the FreeBSD rescue system did not work or more likely I was just too impatient), reboot and then log in via ssh. Then, on the console of the Linux rescue system, lspci tells us that this server has a Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) ethernet controller. This controller is supported by DragonFly’s re(4) device as we can quickly verify by looking up the DragonFly man page. This is all we need to know.

Creating a custom DragonFly installer image usable for remote installation

Let’s tackle the second problem first. The approach I have taken requires us to build a new installer image using nrelease(7). The alternative would have been to use a pre-existing installer image, mount it (using vnconfig…) to then update the relevant files directly on the mounted installer image. The approach I explain below is a little bit more complex and requires a DragonFly system already installed somewhere. On that DragonFly system we perform the following steps (all as root):

Booting from the installer image

Now let’s tackle the first problem. I solved it by copying the created installer image to my server, where I made it publicly available via HTTPS for a short period of time (it might be still there :). Of course I bzip2‘ed the file before, as that image is rather large otherwise. So let’s assume this new image is accessible as https://www.ntecs.de/dfly.img.bz2.

Back on the Linux rescue system, we just have to copy that image to the disk and reboot. I did that with:

wget https://www.ntecs.de/dfly.img.bz2 -O - | bzcat | dd of=/dev/sda

Now reboot. Wait, hope, and wait a bit longer, as we forgot to change the autoboot_delay="10" in /boot/loader.conf to some lower value. But, finally I could connect with ssh root@my-server-ip to the DragonFly installer image running on the Hetzner server. And from there I followed the normal installation path. Note that the server has two hard disks, so I installed DragonFly onto the second disk first. It’s important not to forget to update the boot blocks of the first disk (the installer will ask you for that), otherwise it will continue to boot from the first disk which still contains the installer image. This can be quite tricky to notice, as both systems look very similar. Luckily, the installer also copied the /etc/rc.conf and our authorized_keys file to the new installation so that we can log in immediatly as root via ssh. As I did not liked it to be installed on the second disk, I performed a second installation from the second disk to the first disk. But that’s rather cosmetic.

Summary

I am sure there is a simpler approach, but this is how it worked for me. A similar approach would probably work for other providers as well. In case I develop a growing demand for Hetzner servers in the future, a script that automates all of the above mentioned steps would be nice to have.