Installing DragonFly on a dedicated Hetzner server

Last week, I ordered a dedicated Hetzner server. One click, 28 EUR less and a couple of minutes later, it was waiting for 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. Unluckily, they do not officially support DragonFly. 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:

  1. How can we boot from the DragonFly installer image?

  2. If we manage to boot the DragonFly installer image, how can we gain access to the console to proceed with the interactive installation?

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):

  • Check out the source tree:

    cd /usr && make src-create-shallow
    
  • For building the release image I think we also need dports:

    cd /usr && make dports-create-shallow
    
  • Then we have to slightly extend the installer configuration, so that it will use DHCP for the re0 ethernet device and will start up with sshd. To accomplish that, we add two lines to the installer rc.conf:

    echo 'ifconfig_re0="DHCP"' >> /usr/src/nrelease/root/etc/rc.conf
    echo 'sshd_enable="YES"' >> /usr/src/nrelease/root/etc/rc.conf
    
  • We further need to allow remote logins for the root user by copying our public SSH key which is usually stored in $HOME/.ssh/id_rsa.pub to the root user’s authorized_keys file:

    mkdir /usr/src/nrelease/root/root/.ssh
    chmod 700 /usr/src/nrelease/root/root/.ssh
    cat $HOME/.ssh/id_rsa.pub > /usr/src/nrelease/root/root/.ssh/authorized_keys
    
  • Then we are ready to start building the installer image. In doubt, or for more information, read the nrelease(7) man page.

    cd /usr/src/nrelease && make img
    
  • After the build has finished, the new installer image can be found in /usr/ob/release/dfly.img.

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.

Conclusion

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.