Note: This is an old post from when I wrote on medium.com…formatting may be wonky here until I clean it up.
Matterhorn…if you squint you can see Puffy up there, I swear. (https://commons.wikimedia.org/wiki/File:Matterhorn_from_Domh%C3%BCtte_-_2.jpg)
Virtualization is just plain fun. While I do rely on it specifically to satisfy professional needs while running OpenBSD on my laptop (mostly hacking on some enterprise Java software that doesn’t natively support *BSD), I find myself constantly fascinated by it and tinkering with it.
The OpenBSD man pages are a great resources, as well are the mailing lists and FAQ…but when it comes to non-OpenBSD specific needs like tuning your Linux VM there isn’t much out there. Hopefully someone finds these useful 😀
The following are some tips/tricks for making Alpine Linux far more usable under OpenBSD, especially if you need to do real work in a Linux environment and want to do it on your local OpenBSD machine without rebooting.
This post will cover some installation, disk management, and vm networking tips!
Honestly, this should be self-evident if you’ve played with Alpine and VMD. If not, it doesn’t hurt to revisit. Trust me I’ve personally lost sanity points on this.
Alpine has many flavors, each with slightly different, pre-baked boot args, kernel configs, etc. Regardless of which you use you need to properly tell Alpine’s boot loader to pass along details to the kernel that you need serial console support. (I believe the exception is the virt flavor, but it doesn’t hurt to know this!)
At boot, hit
TAB to see the boot menu label available. Chances are it’s something like
grsec depending on your Alpine version (3.6 vs. older).
Type the name (e.g. “hardened”), a space, and then
console=ttyS0,115200 like so:
hardened console=ttyS0,115200. It should be all you need to properly get serial console access via the
-c flag during
vmctl start or when using
There are still some sync issues between OpenBSD’s serial terminal emulator (cu(1)) and the virtualized serial console “plugged” into the Alpine Linux VM. This problem, on my host system, seems non-deterministic in how it randomly locks up…so I recommend scrambling to establish SSH access to complete the install.
While it’s not readily apparent, most Alpine iso flavors (at least alpine-standard) have the OpenSSH package available, just not installed. This means you don’t even need internet access in the VM.
Once your inside Alpine Linux after initial boot from the iso:
apk add openssh
/etc/ssh/sshd_config, uncommenting and changing the PermitRootLogin line to something like
PermitRootLogin yes. You can use
sedor whatever floats your 🛥
setup-alpineis the easiest way to do this…just work through the steps up until you select a network device and configure either static of a dynamic IP (write this down or copy it).
Once you have the IP, it’s safe to kill the serial console via the
cu(1) control sequence
RET RET ~.).
Then just ssh into the Alpine box using the IP you obtained or set during the aborted install and you’ll be on far more stable connection, bypassing the serial console. From there you can re-run
alpine-setup and complete the install.
If you’ve followed other guidance you may have at least configured the Alpine instance to use the serial console by default. However, unless you intervene you’ll either have long boot times or have to manually intervene to navigate the boot menu presented by syslinux. Let’s change that so
vm.conf can then be used to start it automatically at OpenBSD boot time quickly and confidently.
BTW: This is easily done during install and before reboot/poweroff of the VM. If you’ve just completed
alpine-setup, you just need to mount the boot partition from your new disk:
mount /dev/vdb1 /mnt
Note: It most likely will be the
vdbblock device assuming
vdbis the device you chose to initialize as
sys. Choose whichever device you chose during
Update the config file
/boot/syslinux/extlinux.conf if you’re already rebooted after install) to make it look more like the following:
You can either comment out existing lines or remove them entirely. The important things to note are:
MENUrelated entries, other than any nested under
LABELblock since it has your system’s root partition UUID (mine won’t work for you) and the proper kernel name, which may be different.
LABELvalue you want to boot, e.g.
Save and reboot. Other than maybe a slow ntp daemon, it should boot right up and be ready to go.
This is super handy if you plan on storing lots of stuff within the Alpine VM and want to be able to nuke the root disk. Let’s say your root disk image (where you’ve installed Alpine) is called
$ vmctl create alpine-data.img -s 20G
$ vmctl start my-alpine-vm -d alpine-root.img -d alpine-data.img
# apk add parted
(parted) mklabel gpt
(parted) unit MiB
(parted) mkpart 1 ext4 1 20479
(parted) align-check opt
(parted) name 1 data
# mkfs.ext4 /dev/vdb1
mkfsreports! Copy that.
/etc/fstabin Alpine, adding a new line with the UUID like:
UUID=2fc3aff6–5a80–4ef7–809b-33de8a3ceb17 /data ext4 rw,relatime,user 0 0
mount /data(where /data is my mount-point). If things are good, the entry in
/etc/fstabshould tell the system all it needs to mount the disk.
vm.conf, update to include the additional disk in the vm settings.
Using disk partition UUIDs, we can make sure if we accidentally or purposely change the order we attach the virtual block devices, the system can still find the right partitions for booting, root, and our new data partition. The joy of GPT and UUIDs!
If you use the data disk idea above and plan on using Docker on Alpine, it makes a perfect way to isolate the storage used by the containers and their data so you don’t blow out disk space for your root partition.
First install Docker, then modify the
/etc/conf.d/docker config file, adding a custom
# any other random options you want to pass to docker DOCKER_OPTS=”–data-root /data/docker”
/data/docker is a location on my mounted data disk.
Restart Docker with
rc-service docker restart. You should see the hierarchy of the Docker puke 🤢 in your new directory.
Last step is never tell anyone on the internet you run Docker on virtualized hardware because you’ll be told you just killed about 1000 kittens. 🤷
Hopefully the above tips help someone someday. If they do, do us all a favor and kick a few bucks to OpenBSD development.
Future tips might include: