Patching OpenBSD kernel and packages "how to"


Every operating systems has bugs, OpenBSD is no different. It is the admin's responsibility to watch for new patches and apply those patches accordingly. OpenBSD does not put out new binaries and they do not really have a good patch system compared to other OS's. What they lack in user friendly tools they more than make up for in diligent security patches. When a problem is found the group prides itself on identifying the cause and putting out a fix.

This "how to" is a simple reminder as to what steps need to be taken to patch the kernel. We have also included a set of scripts at the end of the page to update the kernel and all packages from the CVS tree. These scripts access the "-stable" tree, not the bleeding edge "-current" tree.

Example 1: Patching the kernel and building a new one

The following are kernel patches against OpenBSD v4.6 -stable. Each one patches the kernel for the reason listed.

The idea is: We need to download the kernel source "sys.tar.gz" and untar it in the /usr/src tree. We also need each of the kernel patches we want to use. Then apply the patches and make sure that after the patch completes it says something like, "Hunk #1 succeeded" as this is your assurance the patch took correctly. Lastly, config the new kernel and rebuild. You can check to make sure the file /bsd has the current date. This is the new kernel. Finally reboot to use the new kernel.

For example, to make a new kernel after patching it with the above you can use the following lines:

## Get the source and patch files
cd /usr/src

## Untar source files and apply patches
tar zxvf sys.tar.gz
patch -p0 < 003_getsockopt.patch
cd /usr/src/sys/arch/`arch -s`/conf

## OPTION 1: rebuild GENERIC single proccessor kernel
config GENERIC && cd ../compile/GENERIC

## OPTION 2: rebuild GENERIC.MP multi-core proccessor kernel
config GENERIC.MP && cd ../compile/GENERIC.MP

## compile the new kernel
make depend && make && sudo make install

## reboot using the new kernel

After the machine reboots you can type "dmesg" and make sure the top line that specifies the kernel date is the same date you rebuilt the kernel. If the box rebooted fine and the kernel date is correct then you are done. Good Job.

Example 2: Getting your local src repository to cvs -current

If you are looking for additions to OpenBSD that are only available in -current then you need to setup a -current local src repository. This will allow you to build any packages available since your last CVS sync.

First, you must always populate /usr/src with the sys and src files:

cd /usr/src
wget`uname -r`/sys.tar.gz
wget`uname -r`/src.tar.gz
tar zxvf sys.tar.gz
tar zxvf src.tar.gz

Second, we need to sync with the -current cvs repository. You can run the following command each time you want to make sure you have the latest cvs files. For this example we are going to use the repository at Check the OpenBSD page for the repository closest to your location for faster access.

cd /usr; cvs -d "" checkout -P src

Done. Now you can find the packages you are interested in which are synced to -current. Look in /usr/src for the packages you want to build. Then read the README file in that directory for build instructions if you need them.

IMPORTANT NOTE: Most cvs servers are update every two(2) hours from the main OpenBSD cvs server. It is not a good idea to setup a cron job to update more often then this. In fact, we recommend only updating your cvs when you are ready to build. This will save bandwidth and load on the remote servers as well as provide you with the latest code as you need it.

Want more speed? Make sure to also check out the Network Speed and Performance Guide. With a little time and understanding you could easily double your firewall's throughput.

Example 3: Patching the kernel and all packages

These are a set of three scripts to help you keep your systems updated. Once you have a populated /usr/src/ with the kernel source (sys.tar.gz) and package source (src.tar.gz) you can run these scripts to update your system anytime.

Before using the scripts: Populating /usr/src

NOTE: First you must download and untar the kernel source and the package source into /usr/src if you wish to use these scripts. To get the source code for OpenBSD v4.2 you can:

cd /usr/src
tar zxvf sys.tar.gz
tar zxvf src.tar.gz :The first script will sync you source tree with the current "-stable" CVS source tree. Depending on the speed of your system and your connection this will take around 15 minutes.

## OpenBSD -stable (the "Patch branch")

## If empty, you must populate /usr/src/ with src before trying a cvs update.
## 1st, get the OpenBSD src:
## 2nd, untar in /usr/src/
## 3rd, make sure the value below matches your distribution: OPENBSD_4_1

cd /usr/src/
setenv CVSROOT
cvs -d $CVSROOT up -rOPENBSD_4_2 -Pd
logger "patch_1_sync_cvs_source `date`"

## You need to make sure the CVS download completes. CVS lacks any logic to
## restart or resume a failed download, so you need to verify before building
## the kernel (patch_2) or any binaries (patch_3).

## TIME TO COMPLETE: 15 minutes on a amd64 2.4GHz :The second script will build the new kernel with all of the patches that were already applied to the CVS tree.


## This script will build the new kernel, put it in
## place while backing up the old kernel, and reboot
## the box.

cd /usr/src/sys/arch/amd64/conf
/usr/sbin/config GENERIC
cd /usr/src/sys/arch/amd64/compile/GENERIC
make clean && make depend && make
cp /bsd /bsd.old
cp bsd /bsd
logger "patch_2_build_kernel `date`"

## TIME TO COMPLETE: 10 minutes on a amd64 2.4GHz :The third script will rebuild all of the binaries on the machine with the new patched source code. This will take a while to complete.


## This script will build all new binaries and
## reboot the box. After this step is done you
## may want to check if any new third party
## packages are available for your install.
## pkg_add -un will check your PKG_PATH server

cd /usr/src
rm -r /usr/obj/*
make obj && make build
logger "patch_3_build_binaries `date`"

## TIME TO COMPLETE: 1 hour 20 minutes on a amd64 2.4GHz


It is best if you properly understand what each of the commands in the scripts do. Test out your updates on a spare machine before trying to use these scripts in production. Once you understand how the scripts work you can use them any time to get your machines up to the latest CVS stable release code.

Questions, comments, or suggestions? Contact