OpenBSD version: 7.0
Arch:            amd64
NSFP:            Mostly

Running things on OpenBSD naturally starts with installing OpenBSD. The installation documentation luckily documents close to everything there is to know about installing OpenBSD on a machine in front of you. However, running AS59645 ‘on the cheap’ at the moment, I also had to install OpenBSD on several systems that do not allow me to insert boot media. So, how do you get OpenBSD on a system where you can not select boot media or–like with the excellent offer from OpenBSD.Amsterdam–come pre-installed with OpenBSD?


Hetzner is most likely the standard hoster in the German market. Systems are reasonably priced, and you always get the same level of service, no matter their product. Essentially, they are the McDonalds of dedicated server hosting in Germany…. with the drawback of… well, them being the McDonalds of dedicated servers. Nevertheless, before having my own hardware–and ever after abandoning that–I have been renting physical servers over there.

However, as unlikely as you will be able to order a lasagna at McDonalds, OpenBSD is not exactly a ‘supported operating system’ at Hetzner.

So, how do you get it on your machine?

Dedicated Server

Getting a console

For a dedicated server, the first step is getting access to the VGA output (and ability to send keyboard inputs.) Conveniently, you can rent KVM consoles for your servers, which–for the first three hours–is even free. Unlike the old Lantronix Spiders, the new Raritan consoles even work without you having to run Java.

Booting the installer

Next, we have to get the installer booted. OpenBSD is not a supported operating system at Hetzners. Hence, there is no automatic installation option. Also, there is no OpenBSD resque system available (we will discuss further drawbacks of that below). Hence, your best shot is using GRUB2 on an installed linux (if you already have one running). Alternatively, you can of course also dd an installXX.img or minirootXX.img to /dev/sda from the resque system. However, so far, I have not tried that.

Making GRUB2 load OpenBSD is relatively easy. We first cd /boot and then use wget to download bsd.rd from our favorit mirror:

root@host ~ # cd /boot/
root@host /boot # wget
--2022-03-27 15:08:50--
Resolving ( 2a04:4e42:3::729,
Connecting to (|2a04:4e42:3::729|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4208189 (4.0M) [application/octet-stream]
Saving to: ‘bsd.rd’

bsd.rd       100%[===============================>]   4.01M  3.71MB/s    in 1.1s    

2022-03-27 15:08:52 (3.71 MB/s) - ‘bsd.rd’ saved [4208189/4208189]

To configure GRUB2, there is [a config generation system][grubgcfg] on Debian-oid systems. However, as this system is not going to live much longer after bsd.rd has been booted, we can also directly edit /boot/grub/grub.cfg. To load an OpenBSD kernel with GRUB2, we can use the kopenbsd keyword. In the end, the diff on my machine looked like this:

root@host /boot # diff -u /boot/grub/grub.cfg_old /boot/grub/grub.cfg 
--- /boot/grub/grub.cfg_old	2022-03-23 01:58:01.008353127 +0100
+++ /boot/grub/grub.cfg		2022-03-27 15:15:08.600347317 +0200
@@ -119,6 +119,9 @@
 set linux_gfx_mode=text
 export linux_gfx_mode
+menuentry 'OpenBSD' {
+	kopenbsd /bsd.rd
 menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-99e3bcb5-ec9a-4d24-9d31-f7130c9832e5' {
 	gfxmode $linux_gfx_mode

From here on, the whole process is pretty much a normal installation.

UEFI, OpenBSD and Hetzner (NSFP)

One caveat I encountered is that I was unable to get Hetzner dedicated servers to boot OpenBSD using UEFI and GPT partitions. This is somewhat difficult as most Hetzner dedicated servers come with disks large than 2TB. This lead to a somewhat curious setup.

We first create MBR partitions on all disks:

# fdisk -iy sd0
# fdisk -iy sd1

Then, we create a softraid0 for our / partion(s; I personally have a very flat partition layout; Some people may want to split out more).

# disklabel -E sd0
Label editor (enter '?' for help at any prompt)
sd0> a a
offset: [64]
size: [4294961621] 50G
FS type: [4.2BSD] RAID

Next, we use b in disklabel to change the disk boundaries. This allows us to use an MBR partition table, but still be able to access the whole disk.

sd0> b
Starting sector: [64] 
Size ('*' for entire disk): [4294961621] *

We can then add a second partition that spans the rest of the disk and use it for data.

sd0*> a b
offset: [4294961685] 
size: [3519075483] 
FS type: [swap] RAID

Having two RAID volumes here is not strictly necessary. However, I figured that it might be nice to ensure that / is always in a part of the disk that can be MBR read ‘within specification’.

Next we can create our RAID volumes. Keep in mind that beyond the documentation, you will have to run an additional MAKEDEV to add an additional device for our second RAID:

# cd /dev
# sh MAKEDEV sd0 sd1 sd2 sd3

Apart from that, the installation then goes according to the documentation.

Hetzner Cloud VMs

Update: A person on IRC pointed out that you can actually select OpenBSD installer images for cloud VMs. Seems like there is an easier way than what i describe. ;-)

Similar to dedicated servers, there is no straight-out way to get your VMs with OpenBSD. Luckily, we have access to a console on the VMs via the cloud management system. Hence, installation goes just as with the dedicated servers. We throw in a bsd.rd and boot it from GRUB2.

Booting the Installer

One thing to keep in mind though is that these machines do not come with a seperate partition for /boot. Hence, you either have to put the bsd.rd into /, or change the path as follows:

menuentry 'OpenBSD' {
	kopenbsd /boot/bsd.rd


One peculiar thing about Hetzner VMs is that you get a /32 IPv4 address and use an [RFC1918][rfc1918] address as your default gateway. However, unsurprisingly, that address is not in the /32 you got, and you have to set a static route.

The way I solved this is by executing a shell before starting the installation, running:

# ifconfig vio0
# route -n add -link -iface vio0

You can then configure the network as usual during the installation, and use as you default gateway.

To get things working permanently, you then have to adjust /etc/hostname.vio0 and /etc/mygate to read as follows: ~ # cat /etc/hostname.vio0 
inet 0xffffffff
inet6 2001:db8:d15a:51da::1 64
!route -n add -link -iface vio0


host ~ # cat /etc/mygate

Serial Console Only VMs

One of my machines is a VM at IN-BERLIN. It is a small community hoster for not for profit projects and $THINGS, so a somewhat ideal place to do stupid things. One thing about the VMs there is that you get an SSH interface to connect to the serial console of your VM instead of a VGA interface. Even though OpenBSD installs just fine via the serial, you have to tell bsd.rd that it should use the serial.

I took me some serious looking around until I stumbled over an article by cosarara, encountering the very same problem. Turns out, kopenbsd has an argument -h, which allows you to tell bsd.rd to start up on com0.

The ultimate GRUB2 entry hence looks like this:

menuentry 'OpenBSD' {
	kopenbsd -h com0 /boot/bsd.rd

Thereafter the installation is pretty much default, and with the redirect of the default console from the installer, OpenBSD can also be operated via the SSH based serial provided by IN-BERLIN.


So, that’s it. All pecularities of installing OpenBSD I encountered. There will be another article when I move my Nextcloud instance and have to set that up again (there have been some NSFP things done to it). Also, I am eyeing moving to an NVME based VM host (or own hardware… let’s see… ), which will have another article, as I won’t be able to skimp on UEFI then.