OpenBSD: Installation and Initial Thoughts

So for a long string of reasons I don't really need to get into here, I decided, mostly on a lark, that I would install OpenBSD on my desktop recently. And I did. Here follows a few thoughts about the process, and my initial impressions of the system itself.

Installation

The Basic Process

Surprisingly, this was very straightforward and simple. The whole default install, from nothing to a functional system, took less than an hour and a negligible number of keystrokes.

I was somewhat surprised, shortly after booting from the USB stick, to get a boot> prompt; however, that quickly passed as the boot proceeded, and the installation process itself was a breeze. I was expecting to really have to roll up my sleeves and get metaphorically greasy; but I've never had a Windows installation, or even an Ubuntu installation, ever go more smoothly.

Partitioning

The only trick was learning the way that the BSDs deal with partitions and slices; but this is (a) very simple, really, and (b) something I already knew from working with FreeBSD.

It was a little unsettling to see the sheer number of partitions that OpenBSD sets up, though. I'll admit that I've hitherto been a user of the slapdash default Linux-style partitioning system in which the entire system dwells happily on one partition—except after I got a 2-terabyte hard drive, which I mounted on /home, since that's where most of the data is. So I was already used to being much more complicated than the vast majority of Linux and BSD users by having two partitions: / (that is, root) and /home (where all my personal data goes).

But OpenBSD goes crazy with this. It set up, by default (and I did use the default partitioning; this was done perfectly smoothly and without any effort on my part at all) no fewer than nine partitions, each for a different purpose:

• /: root, obviously, where all the filesystems you can access are based.
• /home: home, where all the user data is placed.
• /tmp, which is used for temporary flotsam that doesn't need to last very long.
• /usr, which most people pronounce as “user” but which is actually an acronym for “user system resources” (or so I've been told), where programs that the user is likely to use are stored. Stuff like editors, media players, word processors, email programs, and similar tools. But that's not all! /user is subdivided into four additional partitions:
  • /usr/X11R6, where X-related (that is, the windowing system, or GUI, files go);
  • /usr/local, where information specific to the particular instance is located.
  • /usr/obj, which I can only assume is where shared object files are placed;
  • /usr/src, which is where source files (source code, that is) go;
• /var, where files that the system writes to very frequently (such as logs, mail spools, print spools, and so on) are located.

Good gravy! OpenBSD insists that there is a method to this madness: the permissions and settings of each partition are designed to protect the security of the whole system. For example, /usr/local has nosuid set, whereas /usr does not, because in the former case there is no decent reason for a program to claim superuser status, while in the latter there might well be. I am willing to take their word for it, for two reasons:

• I know just enough about security to avoid the big, obvious holes; the more subtle aspects of it require me to trust the experts. Whatever else the OpenBSD devs might be, they are certainly security experts.
• They did this all seamlessly, without any work on my part whatsoever. Hit the default config for the disk, and all this magic happened. When trusting the experts requires literally no effort, it's easy to trust the experts.

There was one special wrinkle, unique to my case—the aforementioned 2-terabyte hard drive. I could, of course, install my entire system on this drive; but I also have a much smaller drive that is very suitable for the system install, so why not use that? So the drive that BSD partitioned as above was my system drive; my much-larger data drive had to be treated differently.

Since it was previously formatted for the FreeBSD UFS filesystem, and OpenBSD uses a different filesystem, called FFS (the difference is not clear to me, nor does it need to be), I made sure that the drive was backed up and then created a new FFS partition which occupied the entirety of the drive. (This is a straightforward process of two or three commands that can be easily found on the Internet, if you don't already know it.)

Next, I ran disklabel on it. disklabel is an OpenBSD utility which does a lot of things; but what I needed was to determine what the duid of my large hard drive was, so I could enter it into my /etc/fstab file for automatic mounting on startup. First, of course, I had to figure out which drive label was mine; I ran dmesg and plugged around looking for a hard disk until I found mine, labelled /dev/sd1. I then ran disklabel sd1 and grepped for duid, the disk unique identifier, which I then put into my /etc/fstab with the suffix .a, for the partition of that disk which contained the actual FFS filesystem. I then replaced the line in the fstab line which previously contained the home partition with one identical to it, except that the duid of my huge partition with the .a suffic replaced the previous one. Then, save and reboot.

Voilà! I now have my OpenBSD super-secure partition system, but with my own giant disk set as the /home partition.

Very, very simple. Nice.

Post-Installation

Of course, I had to install the usual panoply of programs that don't come with a system. vim, mutt (and its many concomitant programs, fetchmail, procmail, msmtp, abook, mairix, muttprint), cmus, texlive (the whole kit and kaboodle, by my preference, though of course you can do a lot less), vlc, vorbis-tools, audacity, and on and on. It's a lot to install.

Fortunately, OpenBSD makes this pretty easy, too; the pkg_add program, and all its friends (pkg_info -Q being the most useful, if you know what you want but can't remember the exact package name), worked seamlessly and simply. I had a complete, useful system up in very little time at all.

I use fvwm2 as a window manager, which did require me making an .xinitrc file to start it up (as opposed to the .xsessions file I had used in FreeBSD). But this is a simple thing:

export LC_ALL=en_US.UTF-8
xrdb -load $HOME/.Xresources
xsetroot -solid black &
fvwm2

This is not the place, of course, to talk about what all these means, but that was enough to get an identical system running in OpenBSD that I'd had in FreeBSD, and this took another half hour or so to figure out.

Problems

It wasn't all sunshine and rainbows, though.

Bizarrely-named Programs (For No Good Reason)

For one thing, gcc was a bother.

Not that gcc itself was a bother, mind you; but that OpenBSD deliberately made gcc a bother. See, gcc is GPL licensed, and OpenBSD wants to avoid that in favor of BSD-licensed software. I get it; I disagree, but I get it, and that's okay. clang is the default compiler, which is an unfortunate choice, but I will live with it for the other benefits that OpenBSD provides.

But when I installed gcc, why does OpenBSD have to make it so needlessly opaque? After installing it, I kept getting command not found errors, which seemed weird given that I'd just installed the command. Some research led me to find that gcc is, for historical reasons dating back to an ancient fork of the compiler suite, installed under the name egcc, and that is why the system couldn't find it.

Why? Not a single distribution of any other operating system I've ever seen (and I've installed a bundle, I promise you) lists the GNU compiler under that name. The fork that led to that particular name ended decades ago. There is no earthly reason to keep the name egcc other than to make it difficult to use the compiler.

What gives? OpenBSD is all about choice; why make my choice more difficult? Especially when I only wanted the GNU compiler to make sure that my programs would compile with as many different compilers as possible?

No matter; I just ran the following to solve the problem:

# ln -s /usr/local/bin/egcc /usr/local/bin/gcc
# ln -s /usr/local/bin/eg++ /usr/local/bin/g++

Even after the compilers are updated in the future, these links will still run the updated version, so this truly does solve the problem. Still, why must it be so difficult?

Memory Limit Issues

OpenBSD tries to limit the memory that a single user can make use of. Speculating, I'd say this is to prevent a single user from taking advantage of too much of the operating system, which makes perfect sense when there are many users on the system. However, on my system there is only one user. Additionally, some of my tasks require more memory than that.

Additionally, the results of insufficient memory for a task aren't clear: the program simply crashes and dumps core, without explanation. I have no experience reading core dumps, and I was only able to induce that the memory limitations wer causing these crashes.

So go to /etc/login.conf and changed every line that contained a data limit (datasize-cur and datasize-max) and changed their assigned values to infinity.

The crashes stopped. It's possible that I'll need to adjust other limits in this file, such as openfiles-max, but so far I've been okay. I just wish there were something in the system prep itself explaining that this was a possibility so I didn't have to grope in the dark trying to figure it out.

Locale Issues

For some reason, in 2022, OpenBSD does not, by default, set the locale to UTF-8. (Or to anything at all, actually; there was literally no locale set in my system.) The locale, which takes many forms but for the user mostly the environmental variable LC_ALL, governs how the system treats “special characters”—that is, characters which have a binary representations higher than one hundred twenty-seven, or outside the basic ASCII range. OpenBSD doesn't set this variable, which means the system has literally no guidance whatsoever as to how to deal with these characters.

This is, in my opinion, a big problem. These characters are often very simple, such as “á”, “ø”, and “þ”/“ð”, along with the correctly-shaped quotation marks around each one—and the fact that I can fearlessly put those characters in a web page without any worry about your browser rendering them shows how normalized dealing with those sorts of characters have become. We just set the locale to Unicode, specifically UTF-8, like nearly everything else these days, and everything will be find.

But because the locale wasn't set, my terminals (and their fonts) didn't know what to do with them, and I got a bunchy of gobbledygook. This is unacceptable. Fortunately, it's a relatively simple fix.

Up above, where I talked about the .xinitrc file I had to build? Remember that first line:

export LC_ALL=en_US.UTF-8

That takes care of it for all other logins. For this login (to spare myself having to log out and then back in), I do the following:

$ export LC_ALL=en_US.UTF-8
$ ~/st/st &

I then close out the current st and use the new st I just opened, and I no longer have issues.

Well, except one. OpenBSD also does not contain the default font that st is expecting, and UTF-8 support isn't very helpful without fonts that actually contain the symbols that UTF-8 is displaying. So I need to install those, as well. Fortunately, there's a package for that:

# pkg_add liberation_fonts

And now I can freely type Greek letters and quotation marks and accents without getting weird placeholder symbols. Excellent.

Conclusion

All told, I'm very pleased with the process so far. While the documentation of common installation issues isn't what I'd like it to be, all the problems I've come across were solvable, and without too much effort. It was easy to install and so far has been very easy to use. All told, I'm very happy, and will update if anything goes bad.