Chapter 2. Installation Preparations

I am script kiddie.
Windows is warm and tasty;
blowfish goes down hard.

It’s not enough to install OpenBSD and get the machine running; you want a successful installation. A successful installation means that the system is configured to perform the job you intend it to do. A developer’s laptop has very different requirements than those of a dedicated firewall, which might look very different from a web server. Proper planning will make your OpenBSD installation quick, easy, and successful. We’ll spend a great deal of time on installation planning. Once you understand what you’re doing, the actual installation process is pretty simple. Many of the problems people have with OpenBSD come from not understanding their many choices.

The guidelines in this chapter cover most situations, but the final word on installing OpenBSD is the install document included in the release. For example, before installing OpenBSD on an i386 system, read i386/INSTALL.i386 for your release.

OpenBSD Hardware

OpenBSD supports a wide variety of different hardware architectures. Some platforms, such as i386 and amd64, have extensive support, and their web pages and release notes list pages and pages of supported hardware. Others, such as SGI, support only very specific hardware models.

OpenBSD’s currently supported hardware platforms include i386 (standard PC), amd64 (64-bit PC-style hardware), sparc64 (Sun-style hardware), SGI (Silicon Graphics), and others. It also supports old platforms such as the VAX and tiny computers like the Zaurus. The platforms that I find interesting include the following:

This chapter covers installing on the i386 and amd64 platforms. These are the standard 32-bit and 64-bit PC systems available from most vendors, and are what you’re most likely to find on the secretary’s desk while he is at lunch. They’re architecturally close and install in exactly the same way.

Old systems can run OpenBSD quite well. I’ve run OpenBSD/i386 quite nicely on a 166 MHz processor with 128MB of memory. You probably have some old system lying around that’s perfectly adequate for learning OpenBSD.

In this book, I assume that your equipment is PCI bus or newer. I do not cover EISA hardware, or ISA other than the onboard chips in modern hardware. If you have an EISA SCSI card or network interface card (NIC) that still works, OpenBSD probably supports it. I assume that you still have the original hardware configuration floppy and remember how to set the IRQ and interrupt to match that assumed by the OpenBSD kernel. If you don’t, recycle that card and buy something built this millennium.

Note that the hardware must be in working condition. If your old Pentium machine kept crashing because its RAM is bad, using OpenBSD won’t fix that problem. Also, OpenBSD will be most useful if the hardware meets certain minimum levels. I make recommendations based on my own experience, but again, the documentation gives the current and definitive requirements.

You can find a full list of supported hardware platforms at http://www.OpenBSD.org/plat.html. This page links to a page for each hardware platform, where you can get details on support for that hardware.

Supported Hardware

The good news is that OpenBSD supports most hardware. The bad news is that it doesn’t support everything. Generally speaking, OpenBSD supports the most common nonproprietary hardware. It might not support the very newest hardware, as the OpenBSD team doesn’t get much access to hardware before it’s released. Hardware that’s a few months old has better support than bleeding-edge gear.

To verify if OpenBSD supports your hardware, read the release notes for your platform or just give it a try.

Proprietary Hardware, Blobs, and Firmware

Some hardware vendors want to keep the inner workings of their equipment secret so that competitors can’t copy their designs. They hide their hardware designs in two common ways: proprietary hardware and binary object device drivers.

Some vendors will not provide documentation for their hardware. The vendor expects that the user will use the vendor-provided driver, and they provide drivers only for the most widely used commodity operating systems (such as Windows) or for a specific target market (Apple). Without documentation, writing device drivers is tedious and difficult. Some hardware can be supported well without complete documentation, but much cannot. For example, OpenBSD’s sparc64 platform didn’t support newer Sparc processors for several years, until Sun released documentation.

Some vendors don’t want to provide documentation, but do want users of open source operating systems to buy their hardware. These vendors provide drivers for their hardware in the form of binary objects, or blobs. This might sound reasonable at first, but the operating system must load these blobs into the kernel. The OpenBSD team has several objections to this. First, the code is not available for audit. If the blob has a security issue, or has some subtle interaction with the kernel that destabilizes the system, there’s no way for the developers to resolve the problem. The blob might only be inefficient or wasteful, but it could negatively impact other kernel subsystems or even include backdoors. Lastly, OpenBSD’s philosophy requires that all code be covered under a strict BSD license. In-kernel blobs are not free, and so OpenBSD will not support them.

Note that blobs are not the same as firmware. Firmware is a binary object a piece of hardware needs in order to run, and is loaded into the hardware itself, rather than into the operating system. You’ll find firmware in almost every computer component: CPUs, motherboards, NICs, disk controllers, and so on. Firmware is never loaded into the kernel; the kernel loads the firmware into the card. The OpenBSD team considers this acceptable. The firmware lets the hardware provide its documented interface to the operating system, and if it wasn’t on the disk, it would be on the hardware itself.

Generally speaking, if OpenBSD developers have a piece of hardware, documentation for that hardware, and any use for the hardware, they will probably implement support for it. If not, that hardware won’t work. In most cases, unsupported proprietary or blob-driven hardware can be replaced with more effective (and less expensive) open hardware.

Processor brand is irrelevant. OpenBSD doesn’t care if it’s running on a CPU from Intel, AMD, Cyrix, or any other Intel-compatible processor. OpenBSD probes the CPU on boot and uses whatever chip features it recognizes. I’ve run very effective multimegabit firewalls on 486-class processors, but you’ll be happiest with a 1 GHz or faster processor.

OpenBSD’s multiprocessor support is not as broad as some other operating systems, however. The OpenBSD kernel mostly runs with the Big Giant Lock method, so the kernel can run on only one processor at a time. (Some small chunks of the kernel are not under the Big Giant Lock.) In practical terms, this means that the OpenBSD kernel won’t make effective use of more than two processors or cores.

Does this mean you shouldn’t use OpenBSD on your dual-eight-core-processor server? That depends on your expected server load. User processes scale well as long as they don’t go into the kernel. Most web log analysis software, for example, runs almost entirely in user space, and you run massively parallel analysis jobs that scale quite well with the number of processors. Tasks such as forwarding packets, however, pass through the kernel. The hardware you need depends entirely on your expected workload.

Memory is good. The more memory you have, the happier you will be. Adding RAM accelerates your system more than any other generic improvement. You should have at least 256MB of RAM, and preferably at least 512MB. If you can get a couple of gigabytes in your system, OpenBSD will take full advantage of that memory.

If you keep adding memory, you will hit a point where your system has all the memory it needs, and more memory won’t further improve performance. This could be as low as 128MB for a small firewall, a couple of gigabytes for a desktop machine, or more for a large database server.

Most weird crashes and inexplicable, irreproducible problems can be traced back to bad memory, so be certain that the memory you are using is good. Memory is a common failure point in an old machine.

The smallest new hard drive you can buy today will run OpenBSD with vast amounts of space to spare. On older systems, I recommend at least 40GB of disk space—not because OpenBSD won’t fit in less, but because you’ll want room for additional files and software. The smaller your disk, the more closely you’ll need to monitor its use. It’s easy to fill a small disk when building a desktop environment from source, and disks are cheap these days. If you’re running a small firewall from a flash drive, I recommend at least 512MB.[5]

Virtualization

Many people run new operating systems in a virtual environment while they become accustomed to those systems. Some companies even have firm policies mandating that all systems be run as virtual servers. OpenBSD runs fine in common virtual environments, and even has specific device drivers for virtualization systems such as VMware.

The hardware requirements for running OpenBSD on a virtual server are similar to the requirements for running OpenBSD on real hardware. Note that no operating system running in a virtual environment is as secure as that same operating system running on real hardware. Virtual environments do not precisely replicate real hardware. Emulated CPUs have their own new and interesting bugs, virtual NICs have unique errors, and so on. Additionally, the environment providing the virtual server is itself an operating system. An intruder can attack that underlying operating system, and once an intruder controls the virtualization server, clients running on that machine are much more vulnerable. No operating system can protect itself against its hardware. You must consider this risk when planning OpenBSD’s role in your environment.

For learning about OpenBSD, however, a virtual environment is perfectly adequate. I run OpenBSD machines in VirtualBox, on ESXi, and on Linux’s KVM hypervisor without difficulty.

For many years, I ran multiple operating systems on a single computer. I remember being thrilled by my new 6GB hard drive because I could run FreeBSD, OpenBSD, Windows, and Linux on one computer with plenty of space for each operating system. This was the only way to run multiple operating systems on a single desktop, but advances in virtualization technology have made this approach obsolete.

Rather than carefully dividing your desktop hard disk to run multiple operating systems and hoping that some proprietary disk-partitioning program won’t munch its neighbor, I recommend running one operating system that supports a virtualization server and running your secondary operating systems as guests. OpenBSD supports running virtual guests with qemu.

Getting OpenBSD

Once you have hardware, you need OpenBSD. You can get OpenBSD on CD and over the Internet.

Why would you buy an official CD in the 21st century?

The OpenBSD project is funded largely by sales of official CDs, along with related books, clothing, and so on. You can download a disk image from the Internet and burn your own installation disk, but purchasing an official set helps improve OpenBSD. The OpenBSD team tries to make the official CD sets interesting pieces in and of themselves, and usually packages them in some sort of geek-themed art. To get an official CD, go to the OpenBSD website and look for the Getting OpenBSD link. You can also find a whole bunch of OpenBSD-related merchandise.

You can download installation images from the Internet, but they’re not the same as the official CD set. The downloaded disk images don’t contain any packages, lack the fancy physical packaging, and work on only one hardware architecture. You cannot download the images used for the official disks.

The main OpenBSD distribution point is in Canada, which increases delivery costs for those living on other continents. The OpenBSD website lists a variety of resellers that offer official OpenBSD CDs. Pick a vendor in your country and save on customs duties. If that option isn’t available to you, you can at least pick a vendor on your same continent and save on shipping.

The other OpenBSD installation methods require network access, either to download a complete image or to download files during the installation. Start by selecting an OpenBSD mirror site close to you. You can find a full list of mirrors at http://www.OpenBSD.org/ftp.html.

You can install the operating system files from an ISO image, FTP, HTTP, rsync, or even the Andrew File System (AFS) or Network File System (NFS) on some platforms. We will break the task into two parts: getting the target system to boot and getting the operating system files on the machine.

Mirror Site Layout

All of the OpenBSD mirrors contain files and directories much like these:

Release Directories

Look within any given release directory on an OpenBSD FTP site or on a CD, and you’ll see the following:

  • A directory for each architecture OpenBSD supports: amd64, i386, sparc64, and so on (on the CD, these directories are scattered among different disks as space permits)

  • A packages directory containing precompiled software for this release (see Chapter 13)

  • A ports.tar.gz file containing the compressed ports tree (see Chapter 13)

  • A src.tar.gz file containing the operating system source code (see Chapter 20)

  • A sys.tar.gz file containing the OpenBSD kernel source code (see Chapter 19)

  • A xenocara.tar.gz file containing the OpenBSD version of the X Window System (see Chapter 19)

  • A tools directory with software to help installation

  • Several documents such as the release announcement (ANNOUNCEMENT), the basic instructions (README), and notes on OpenBSD’s support for third-party software and different hardware

Look through your CD or the mirror site and find the directory for your hardware architecture. The architecture directories contain fairly similar files for every hardware platform.

First, find the installation instructions for your hardware. These are named INSTALL followed by the platform name (such as INSTALL.i386, INSTALL.amd64, and so on). Always read the installation instructions for your platform. While I’ve made every effort for accuracy in this book, OpenBSD continually changes, and the install document for your release is the last word on installation instructions.

Boot Media

The OpenBSD boot media varies by hardware platform, and each hardware item has its own boot media requirements. You can’t expect to boot a Zaurus or a VAX from a CD.

To easily boot the OpenBSD installer on i386 or amd64 hardware, use either a floppy disk or a CD (I usually recommend the latter). You can boot the installer from a USB disk, but the standard method requires bootstrapping from an OpenBSD machine, and nonstandard methods vary widely depending on available equipment.

If you cannot boot from a CD, use a floppy disk. OpenBSD provides one amd64 floppy image and three different i386 floppy disk images. If you’re booting i386 from a floppy, I suggest downloading all floppy images.

If you cannot boot using either method, you must use the Preboot eXecution Environment (PXE) diskless booting method, as described in Chapter 23. This method works well but requires a bit more preparation.

Choosing Install Media

The boot disk can format your hard drive, configure your network, and copy installation files to disk. Boot media don’t include those installation files, however. Installation files for i386 and amd64 machines come on an ISO image and over the network via FTP or HTTP.

If you intend to install this release on multiple OpenBSD machines, you might download the CD image that includes the installation files. It’s much larger than the boot-only installer ISO image, however, so downloading it will require some sort of broadband connection.

If you’re doing a single OpenBSD installation, or you don’t have a CD drive, I recommend an HTTP installation. If you install from a reasonably close mirror site and have sufficient bandwidth, OpenBSD installs from HTTP quickly and reliably, and uses only about half as much bandwidth as downloading the installation ISO image. If you prefer, you can install from FTP as well.

Advanced users can install OpenBSD via the PXE method, as mentioned in the previous section and covered in detail in Chapter 23.

Local Installation Servers

One reason CDs are so popular is that you need to download files from the Internet only once, but can reuse your downloads to install OpenBSD on many machines. But CDs are physically fragile, and not every machine has a CD drive. If you want to install OpenBSD on several machines without using up bandwidth for each installation, download all of the installation files for your architecture. If you copy these files to a local FTP or web server, you can install OpenBSD on any number of machines from these files. To install from the local FTP server, you’ll need a username and password for the FTP server.

To help save the OpenBSD Project on bandwidth costs, download only the directories for the architectures you need. If you know exactly what you want to install, download just those file sets. You might have no respect for your own bandwidth, but please respect others’ bandwidth.

File Sets

The release directory for each architecture contains several compressed files with names like comp52.tgz, base52.tgz, and so on. These file sets contain compressed OpenBSD installation files. By choosing to install particular file sets, you can pick how much functionality your OpenBSD system will have out of the box. For example, the documentation is kept in a separate distribution set. If you have documentation elsewhere, you might choose to not install it on a particular system. Also, intruders often make use of compilers, so you might not want them on a system you want to protect. But if this is your experimental “learning OpenBSD” machine, install everything.

Each file set has a name and a version number. For example, one distribution set of OpenBSD in release 5.2 is base52.tgz. These are the base files of release 5.2. In the next release, this same file set will be called base53.tgz.

All architectures include all file sets, unless otherwise noted in the architecture’s release notes. If this is your first OpenBSD installation, take a moment to decide which distribution sets you need. If at all possible, install them all on your test machine. You can always trim them down later for dedicated-purpose machines.

The following file sets are available:

bsd, bsd.mp, and bsd.rd

These file sets contain only OpenBSD kernels. The kernel is the heart of the operating system, containing the device drivers and basic system functions. Without a kernel, the system will not boot. The bsd kernel is for single-processor machines, while the bsd.mp kernel supports multiple processors. The bsd.rd kernel contains the OpenBSD installer, basic userland utilities, and the live system kernel. You can run only one kernel at a time.

baseXX.tgz

This contains OpenBSD’s core programs—all the things that make OpenBSD Unix-like. The contents of /bin, /sbin, /usr/bin, and /usr/sbin; the system libraries; and all the miscellaneous programs you expect to find on a minimal Unix-like system are in this file set. You must install this file set.

etcXX.tgz

You might guess that this file set contains the files from /etc, but it also contains other required files and directories, such as /var/log and the root user’s home directory. You must install this file set.

manXX.tgz

If you need the man pages for the programs in the base and etc file sets, install this distribution set. The man pages for other sets are installed with their respective file sets.

compXX.tgz

This file set contains C and C++ compilers, the assembler, libraries, tools, manuals, and the toolchain for each. You need this file set to develop or compile software, or use the ports collection (see Chapter 13). You do not need this file set if you plan to use only precompiled software packages. At roughly 60MB, it is the largest file set for most platforms, but it’s trivial compared to the size of modern hard disks. You might choose to not install it on a secure machine.

gameXX.tgz

This file set contains several simple games, based on games originally distributed in BSD 4.4. Some of these, such as fortune(1), are considered UNIX classics, and old farts won’t be happy unless they’re installed. Others, such as /usr/games/wargames, assume that you’re familiar with early 1980s films. You don’t need the games file set (unless you want to see what passed for “computer games” back when I was in high school).

xbaseXX.tgz

This contains the core of Xenocara, the OpenBSD version of the X Window System. If you want to use X, you need this. Although you might not have a console or monitor on this computer, remember that X allows programs on this server to display remotely.

Most OpenBSD packages assume that you have installed this file set. If you find that a package crashes with errors about missing X libraries, you need this file set.

xetcXX.tgz

This contains the X configuration files. If you’re using X for more than its libraries, you need this file set.

xfontXX.tgz

This contains X fonts. If you plan to use X on this machine’s console, install this file set.

xservXX.tgz

This file set contains all the X video card drivers. If you plan to use X on this machine’s console, install this file set.

xshareXX.tgz

This contains the X documentation. If you plan to use X on this machine’s console, install this file set.

Partitioning

Partitions are logical subsections of a hard drive. OpenBSD can handle different partitions with their own unique privileges. You might make some partitions read-only so that files on them cannot be added, moved, or changed.

OpenBSD might refuse to run programs on a specified partition, and it knows that device nodes should appear only on certain partitions. User files should not have setuid or setgid permissions, so the operating system won’t recognize those privileges on files on the user data partition. While many operating systems support these sorts of privilege controls, OpenBSD uses them by default.

The most difficult part of installing OpenBSD is partitioning. When you don’t know how partitions work, choosing partitioning can be troublesome.

If you’re familiar with other Unix-like operating systems (such as some distributions of Linux), you might be accustomed to using a single large root partition and putting everything on it. This is a bad idea for several reasons. OpenBSD uses partitions as a security tool. A single large partition eliminates per-partition security and privileges. With your log files safely contained on one partition, a process or user gone amok cannot fill your entire drive. While it could fill a partition, you could still create and edit files on other partitions, giving you the flexibility you need to address the problem.

Unlike many installers that have fancy menus and graphic tools, OpenBSD’s installer expects you to know how to use low-level disk management tools such as disklabel(8). Unlike with those operating systems, however, OpenBSD can be installed in a much wider variety of ways on a wider variety of systems, all with a single installer.

If this is your first OpenBSD installation, use the default partitioning offered by the installer. OpenBSD will provide all its standard partitions, but adjust their sizes based on the size of your disk. The discussion here is based on a standard i386 installation on a fairly small disk.

If you’ve previously installed OpenBSD and you’re installing it on a special-purpose machine, you might want special partitioning. In that case, get a piece of paper and a pencil, and write down the size of your hard disk, each partition you need, and each partition’s desired size. Your special-purpose OpenBSD machine should almost certainly have all the same partitions as a default installation, but their sizes will differ. A web server has very different disk space requirements than a desktop machine, which in turn has different requirements than those of a firewall.

If you have a large disk, leave some space unallocated. Having partitions the size you need accelerates filesystem integrity checks; fsck(8) doesn’t spend cycles integrity-checking unused disk space. On solid-state disks, unused space gives wear-leveling algorithms more cells to play with, increasing the life span of the disk and decreasing the odds of failure. It’s better to have spare disk space you never need than to need disk space you don’t have.

The standard OpenBSD partitions are / (root), swap space, /tmp, /var, /usr, /usr/X11R6, /usr/local, /usr/src, /usr/obj, and /home. If you create a custom layout and don’t include one of these partitions, the installer will put files that go into that partition into either your root or /usr partition, quickly filling them. If you want to create a partition after installation, you must find space on your disk for it. Unless you left unallocated space on your disk, you’re better off reinstalling the whole system.

The root partition holds the main OpenBSD configuration files and the most essential software needed to get the computer into single-user mode and on the network. Your system needs fast access to the root filesystem, so if you have multiple disks, put the root partition on the fastest (or smallest) one.

The root partition is the only one whose placement on disk is vitally important. Over the years, i386 systems have been repeatedly expanded to surpass their own limits—they’re based on an architecture that could originally handle only up to 640KB of RAM, after all! All modern operating system kernels work around these limits in a manner mostly transparent to users, but when the system is first booting, you’re trapped within the hardware’s limits.

Many old i386 systems have limits on hard drive size. They only recognize 128GB drives, 2TB drives, or some other number. The hardware BIOS cannot access anything beyond that limit. If you’re using a computer that has a 128GB limit on hard drive size, and you put the kernel somewhere beyond the first 128GB of disk space, the computer will be unable to find the kernel and thus unable to boot the system. Check your hardware manual before you get started. If the manual refers to a disk size limit, your entire root partition must fit within that limit.

If you violate this limit, your system will probably appear to work. The second you change the file /bsd, however, it’s likely that your computer will refuse to boot. Save yourself much pain by putting the root partition first on the disk, and making sure it’s small enough to fit within the hardware’s limits.

Swap space is used for virtual memory. When your computer runs low on RAM, it starts to move information that has been sitting idle in memory into swap space. When the computer needs that information, it’s loaded from virtual memory into real memory. This isn’t necessarily bad for performance. Many programs spend the vast majority of their time executing only a small fraction of their code. OpenBSD is pretty good about figuring out which sections of memory can be moved into swap space and which are used too frequently to be swapped. If things go well, your computer will almost never need swap space.

OpenBSD also uses swap space during system failures. If the kernel panics, the computer writes the contents of system memory to the swap partition. This means that the swap partition must be, at its smallest, slightly larger than the amount of physical RAM in the system.

How much swap space do you need? The short answer is, “It depends on the system.” OpenBSD defaults to allocating twice as much swap space as you have physical RAM. This isn’t a bad rule, as long as you understand it’s very general. A swap space three or four times the size of your physical memory won’t hurt. If your computer uses more swap space than that, it’s overloaded and will perform poorly.

If you find yourself using swap space often, consider increasing your physical memory instead. RAM is cheap.

Also consider future upgrades. If your system has 2GB of RAM when you install OpenBSD, but you intend to increase that to 8GB, assigning 16GB of swap space is a good idea. Adding a swap partition later is difficult, unless you leave unallocated disk space when you install the software. (Note that, while you can swap to a file, OpenBSD can write only crash dumps to an actual swap partition.)

The /tmp directory is temporary space for all users on the system. Space requirements for /tmp are generally a matter of opinion—after all, you can always use a chunk of space in your /home directory for scratch space. Automated software installers frequently extract files into /tmp. I usually recommend at least 3GB in /tmp, but I do horrible things to my temp space. Many people use a /tmp directory of 256MB or 512MB and get along just fine.

The /var partition contains frequently changing data, such as logs, databases, mail spools, temporary run files, websites, and so on. OpenBSD allocates about 5GB to /var by default. This should be plenty for an educational installation. If you’re building a web, database, or logging server, however, /var should get the majority of your disk space. If you’re on a really tiny system, you could use as little as 10MB for /var.

The /usr partition holds the operating system programs, compilers, libraries, and add-on programs. The majority of /usr changes only when you upgrade your system. OpenBSD assigns /usr 2GB by default, which is more than sufficient, even on a desktop system.

The /usr/X11R6 partition contains the X Window System programs and documentation. OpenBSD does package software linked against the X Window System, and a lot of software you might expect to find on servers (such as ImageMagick) requires X libraries.

If you are not going to install any X software, and plan to build all your own software without X, you don’t need this partition. If you’re in doubt, or if this is your first installation, keep this partition.

The /usr/local partition contains add-on OpenBSD software, usually from packages (see Chapter 13). This can be much larger than the /usr partition containing the core OpenBSD software. OpenBSD allocates 5GB of disk space to /usr/local by default, and I’ve never needed more than that.

/usr/src Partition

The /usr/src partition is dedicated to the OpenBSD source code. On a dedicated-purpose machine that doesn’t have a compiler, such as a firewall or a secure web server, you probably don’t need a local copy of the source code. If you don’t plan to upgrade this machine from source code, and you don’t plan to use the source code as a reference on the local machine, you don’t need this partition. If you’re in doubt, keep it.

/usr/obj Partition

The /usr/obj partition is where OpenBSD builds new versions of the operating system and Xenocara. The files in here are temporary; once you’ve installed a new OpenBSD version, you don’t need these files any longer. Creating a new filesystem is faster than erasing the individual files in this kind of filesystem, so /usr/obj is configured as its own partition.

If you don’t intend to build a new OpenBSD from source code, you don’t need /usr/obj. If you find that you do need this partition later, you can either create it from unused space or mount it via NFS.

The /home partition can be described as “everything else.” User directories go into /home, as well as any random data that’s meant for users. The family MP3 and photo collections should go in /home, as well as your personal source code, email, and anything else you want to keep.

OpenBSD supports up to 16 partitions per disk. If you want other partitions, you can create them using the installer. Does your company have a policy that all add-on software must go in /opt or /usr/companyname? Fine, create that partition. The OpenBSD standards are not a straitjacket, but rather a starting point. You own the system. Make it behave according to your needs.

Partition Filesystems

The words filesystem and partition are often used interchangeably. They are closely related, but two different things. A filesystem is a method of allocating and tracking files that are on a partition. You can back up and restore a filesystem, but if a partition is damaged, you’re in much worse trouble.

OpenBSD uses the standard Fast File System (FFS) by default. FFS has been around for decades, and is both well debugged and well understood. Unfortunately, with its default settings, it can handle partitions only up to slightly less than 1TB in size. Modern disks make partitions of that size common.

If a partition is 1TB or more in size, the installer automagically formats it with FFS version 2 (FFS2). In Chapter 8, we’ll cover how to adjust your filesystems to exactly fit your needs.

Multiple Hard Drives

Disk input/output is usually the slowest part of a computer. If you have more than one hard drive, you can use those drives to accelerate your system performance.

First, make sure that each drive is on its own port. SCSI and SATA drives usually accommodate one drive per port (unless you specifically use a port multiplier), but IDE drives usually attach two devices per port. Each port has a maximum throughput. It does no good to attach two fast drives to one port, as the drives compete for the one port’s throughput.

In general, when you have multiple drives, you want to split the read and write activity between the drives. I usually put the data I’m serving on one disk and the important system files on another. If I’m building a database server, I might dedicate one disk to swap space and /var, while assigning all other partitions to the other disk.

Split your swap space between the drives. Be sure that at least one partition is large enough to hold the contents of your physical RAM, so that OpenBSD can do a crash dump if needed. OpenBSD cannot split a crash dump between two different swap partitions.

If you’re a more experienced OpenBSD user, you can use multiple hard drives to create a redundant disk with software RAID. We’ll cover how to do that in Chapter 9.

If your second drive is much slower than your main system drive, don’t bother using it. A computer runs only as fast as its slowest component, so adding that old IDE drive to your SATA system will drag down the whole machine. Not only will its presence degrade performance for the whole system, but it’s also probably much older than your main drive and far more likely to fail.

Understanding Partitions

As a historical accident, i386 and amd64 systems have two different types of partitions. OpenBSD refers to the first as MBR partitions and the second as disklabel partitions (or just partitions).

MBR Partitions

MBR partitions, also known as primary partitions, are universally understood by operating systems that run on i386 hardware. Every hard drive has four MBR partitions. In most cases, only one partition has any space allocated to it; the other three partitions have zero size. If you want to install multiple operating systems on a single disk, then each operating system needs its own MBR partition.

Most operating systems manage MBR partitions with a program called fdisk. It’s not the same program, mind you—OpenBSD’s fdisk(8) is not the same as Microsoft’s Fdisk, which is different from the program for Linux, FreeBSD, OpenSolaris, and so on. Any operating system’s fdisk can see MBR partitions that belong to other operating systems, and while they might not recognize what’s on the MBR partition, they will recognize that space has been allocated for something and will warn you about overwriting it. Unfortunately, not all fdisk programs play nicely with each other. Do not partition disks for one operating system with another operating system’s tools.[6]

With the advent of cheap virtualization, installing multiple operating systems on a single disk is no longer advisable. Assign each disk a single MBR partition that fills the entire disk, and give the other three MBR partitions zero size. You will see an example of how to do this in Chapter 3.

Disklabel Partitions

BSD did not originate on i386 hardware; it had its own disk-partitioning system, based on labeling the disk’s partitions. When BSD was ported to i386, the disklabel was nailed up inside an MBR partition. When someone speaks of “partitions” in OpenBSD, they almost certainly mean disklabel partitions.

One disklabel can support 16 partitions. If you need more than 16 partitions, you must create a second MBR partition and add more disklabels. I would suggest that if you need more than 16 partitions on a single disk, you took a wrong turn somewhere in your decision-making process. Step back and reassess what you want to accomplish and how you’re going about it.

Foreign operating systems do not recognize OpenBSD disklabels. BSD-based operating systems might appear to understand them, but the disklabel formats used on the various BSD-derived systems have diverged in the past 20 years. Use only OpenBSD disk tools to manage OpenBSD partitions.

Understanding Disklabels

The OpenBSD installer expects you to understand disklabels. You can avoid learning about disklabels by blindly accepting the default partitioning OpenBSD offers, but that won’t take you very far. Disklabels might look intimidating to the new user and require some basic math, but they aren’t that difficult once you walk through them slowly. You need to understand disk geometry first.

Once upon a time, disk drives had clearly defined geometry. Each disk was actually round, and it spun inside the hard drive. The manufacturer divided each disk into tiny sections, called sectors. Each sector had a number, with sector 0 at the beginning of the disk and the sectors numbered sequentially until the end of the disk. Sectors were gathered into rings, or tracks. Stacks of tracks were aggregated into cylinders. Each disk drive had a number of heads—data-reading devices that read information from the disk as the disk spun beneath them. Taken as a whole, sectors, tracks, and cylinders described the disk geometry.

This all seems simple enough, but today you can’t actually count on disk sectors to actually map to anything useful. Over the years, both hard drive manufacturers and operating systems have set and broken limits. This applies to all aspects of machine design, from the 640KB memory limit to the 504MB disk limit. Hard drive manufacturers avoided these limits by tricking the system BIOS and/or the operating system.

If you’re a hard drive manufacturer making a hard drive with 126 sectors per track, but the most popular operating system can accept only 63 sectors per track, you have a problem. The easy solution is to teach your hard drive to lie. If you claim you have half as many sectors per track but twice as many platters, the numbers still add up, and you can still provide unique sector numbers. Every hard drive manufacturer chooses to lie in a slightly different way. The most obvious examples are flash drives (which still report cylinders, sectors, and tracks, even though they’re not round and don’t spin[7]) and hardware RAID (which reports the same information about several disks as if they were one). If you read about the history of hard drives, you’ll discover all sorts of interesting lies.

By the time disk geometry information reaches the operating system, it has been through one or more translations. Reach into your head, find the button that says “Accept What You’re Told,” and press it as you repeat the following: Disks are divided into sequentially numbered sectors. Partitions fill a number of consecutive sectors. Sectors are grouped into cylinders, based on the number of heads in the drive. Partitions end on cylinder boundaries.

The installer will display your disk’s disklabel. (You can also see the disklabel once the system is installed and running, as discussed in Chapter 8.)

We’ll look at the disk’s physical information first. While the physical information doesn’t usually directly impact the installation, you need to know how to read it if something goes wrong.

1 # /dev/rsd0c:
2 type: SCSI
3 disk: SCSI disk
4 label: DSA2CW120G3
5 duid: adb697598fa0a010
  flags:
6 bytes/sector: 512
  sectors/track: 63
  tracks/cylinder: 255
  sectors/cylinder: 16065
  cylinders: 14593
7 total sectors: 234441648
8 boundstart: 64
9 boundend: 234436545
  drivedata: 0

Except for the device unique identifier (DUID), you cannot change any of these entries without changing the underlying hardware.

The first entry is the device name, /dev/rsd0c 1. The leading /dev means that this is a device node. The rsd0c is the disk name. sd means that this drive uses the sd(4) device driver, and the 0 means that this is the first drive OpenBSD found and attached. (This is usually, but not always, BIOS drive 0.) The leading r means that we’re addressing the disk in raw mode, while the tailing c means that we’re examining disklabel partition c. Disklabel partition c always matches the entire MBR partition containing this disklabel. Almost any disk that isn’t explicitly IDE will probably show up as a SCSI disk.

The type 2 is a general label describing the disk’s physical interface. Any IDE disk will show up as ESDI (Enhanced Small Device Interface), while SCSI, SAS, SATA, and almost every other type of disk has type SCSI.

The disk field 3 shows what sort of disk is attached to this interface. Here, it shows a SCSI disk, but we knew that already from the type.

The label 4 displays the manufacturer’s name and/or the drive model number. In the case of virtualized servers, this shows virtual drive or something similar.

The duid 5 is the DUID for this disk. If you’ve ever managed a system with more than a couple of disks in it, you know how easy it is to confuse disks. The hardware BIOS identifies disks by the physical port they’re attached to. If you need to replace a SATA or SCSI card, and you get the disks mixed up as you rerun cables, you will have a hard time finding your boot drive again. By using the DUID in your system configuration instead of the BIOS-assigned device name, you will always have the same disk used for the same purpose. As noted earlier, the DUID is the one editable field in the top of the disklabel information.

The bytes per sector, sectors per track, tracks per cylinder, and sectors per cylinder 6 all describe the disk’s geometry. These numbers are all lies, but the total number of sectors on the disk 7 is accurate. You also see the first sector you may fill with disklabel partitions 8, and the last sector you may use 9. (You lose a few sectors due to the hard drive’s geometry transformations. Don’t try to hold the hardware accountable. You can’t win that argument.)

The next section displays the disklabel partitions, and you can alter it as needed. Here’s a disklabel from my desktop:

  16 partitions:
  #             1 size         2 offset 3fstype 4[fsize bsize  cpg]
5  a:          2097121               64  4.2BSD      2048 16384    1 # /
6  b:          4698424          2097185    swap
7  c:        312581808                0  unused
   d:          8388576          6795617  4.2BSD      2048 16384    1 # /tmp
   e:         16736864         15184193  4.2BSD      2048 16384    1 # /var
   f:          4194304         31921057  4.2BSD      2048 16384    1 # /usr
   g:          2097152         36115361  4.2BSD      2048 16384    1 # /usr/X11R6
   h:         20971520         38212513  4.2BSD      2048 16384    1 # /usr/local
   i:          4194304         59184033  4.2BSD      2048 16384    1 # /usr/src
   j:          4194304         63378337  4.2BSD      2048 16384    1 # /usr/obj
   k:        245003968         67572641  4.2BSD      2048 16384    1 # /home

This disklabel declares that it has 16 partitions, but lists only 11. The disklabel has space for 16 partitions, but like the MBR partition table, not all of them have space allocated to them. As with most configuration files in Unix-like operating systems, a hash mark (#) indicates the beginning of a comment. The comments here give the headers for the table above.

The first column is the partition letter. A unique letter identifies each disklabel partition. The first partition in our example is a 5, the second is b 6, the third is c 7, and so on.

The size 1 is the number of sectors the drive uses. In this example, partition a fills 2097121 sectors, partition b 4698424 sectors, and partition c 312581808 sectors.

The offset 2 is the number of sectors from the beginning of the MBR partition where the disklabel partition begins. If a disk is bootable, it has a master boot record (MBR) flagging it as such. The MBR record takes the first 63 disk sectors, numbers 0 through 62. The first sector available for a disklabel partition is sector number 63. Partition a begins on sector 64 in order to correctly align with the memory cells in solid-state disks.

Take a look at partition b. It has an offset of 2097185, meaning it starts in sector 2097185. How do we get there? Well, partition a starts in sector 64 and has a size of 2097121. 2097121+64=2097185, or the first free sector after partition a ends. This seems perfectly sensible until you look at partition c. Disklabel partition c is magical. On every disklabel partition, c represents the entire disk. It has an offset of 0 and a size equal to the number of sectors on the disk. You cannot put a filesystem on partition c; it’s there only for reference. Partition d picks up where partition b left off.

The fstype 3 marks the type of filesystem on this partition. OpenBSD filesystems, such as partition a, are labeled as 4.2BSD. (The OpenBSD filesystem is no longer exactly the same as that from BSD 4.2, mind you.) Partition b is swap space.

The next two columns 4 display the fragmentation behavior of the filesystem on this partition. These values are set by the filesystem creation tool when putting the filesystem on the partition, and should not be changed by hand. If you’re curious, read newfs(8) and its related man pages. The fsize is the fragment size for any file fragments on the partition. The b is the size of a block on disk, in bytes. We talk about FFS fragmentation in Chapter 8. All you really need to know at this point is that FFS and FFS2 are both highly fragmentation-resistant, and neither requires any sort of defragmentation process.

The last column shows the number of cylinders per cylinder group. This is almost always 1 for modern disks.

One interesting thing is that the disklabel can be considered a configuration file for formatting a disk. You could save this disklabel to a file, get an identical hard drive, write this label to that new disk, and perfectly duplicate the partitioning of the old disk on the new.

If at any time you feel confused about your partitioning, print out your current disklabel and compare it to how you would like your system to look.

Other Information

If this machine is going to be on the Internet, you must know its network configuration before starting. If your network has DHCP, you’re all set. If not, you need a valid IP address, netmask, default gateway, and name server IP addresses.

Decide in advance if this machine will run the X Window System. Generally, desktops run X and servers do not.

At this point, you have all the background you need to install OpenBSD on i386 or amd64 hardware. Break out your equipment, and let’s get started.


[5] Yes, that’s megabytes—you know, the unit below gigabytes. Yes, megabytes can apply to disks.

[6] I’m assured by OpenBSD developers that any fdisk should suffice for any operating system. Having been repeatedly savaged by buggy fdisk programs, I find myself unable to give you carte blanche to try this.

[7] Yes, you can make flash drives spin. But a flash drive doing 5400 RPM has a whole set of problems beyond the scope of normal systems administration.