Install OpenBSD everywhere
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
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 https://cdn.openbsd.org/pub/OpenBSD/7.0/amd64/bsd.rd
--2022-03-27 15:08:50-- https://cdn.openbsd.org/pub/OpenBSD/7.0/amd64/bsd.rd
Resolving cdn.openbsd.org (cdn.openbsd.org)... 2a04:4e42:3::729, 151.101.14.217
Connecting to cdn.openbsd.org (cdn.openbsd.org)|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' {
recordfail
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
}
Networking
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 203.0.113.14/32
# route -n add 172.31.1.1 -link -iface vio0
You can then configure the network as usual during the installation, and use 172.31.1.1 as you default gateway.
To get things working permanently, you then have to adjust /etc/hostname.vio0
and /etc/mygate to read as follows:
dns2.aperture-labs.org ~ # cat /etc/hostname.vio0
inet 203.0.113.14 0xffffffff
inet6 2001:db8:d15a:51da::1 64
!route -n add 172.31.1.1 -link -iface vio0
and
host ~ # cat /etc/mygate
172.31.1.1
fe80::1%vio0
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.
Summary
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.