Showing posts with label sysupgrade. Show all posts
Showing posts with label sysupgrade. Show all posts

Monday, September 2, 2024

You Have Installed OpenBSD. Now For The Daily Tasks.

© 2024-2026 Peter N. M. Hansteen

Despite some persistent rumors, installing OpenBSD is both quick and easy on most not too exotic hardware. But once the thing is installed, what is daily life with the most secure free operating system like?

Welcome to OpenBSD! I assume you are reading this as a new user who has just completed installing the system. If you are more experienced with the system and reading because you want to see what they're teaching the young ones these days, you are welcome here, too. And at any rate, input such as corrections and comments are always welcome.

But first, for the really impatient, here are the main points we cover in this piece:


TL;DR: Supported Releases and Five Commands You Need To Know

  • OpenBSD has two releases per year, May 1st and November 1st (roughly). Only the two most recent releases are supported.
  • The first command to run after a new install is syspatch, which pulls in any security updates and installs them. If the output indicates a reboot or other action is needed, do as the program says.
  • OpenBSD's sudo replacement doas is in base, is easy to set up and use and likely fills your needs for privilege elevation.
  • Third party software comes in packages. Use pkg_add to install packages. For finding packages, openbsd.app might help.
  • When you need to upgrade to a new release, sysupgrade does the job well in almost all cases.
  • For managing services (if you need to), rcctl is there for you to get things done.
  • Please keep yourself up to date on developments, and keep the length or limit of the support period for your release in mind. Also, we will offer some insight on running -current at the end.

Installing OpenBSD is quite straightforward on most hardware (possibly excluding some true antiques and, occasionally. the newest of the new). In the rest of this article we will assume that you have completed a basic install, following the OpenBSD Installation Guide in the OpenBSD FAQ, possibly supplemented by other sources.

In our experience, following the FAQ's instructions should get you there, and keep in mind that the defaults are sane, and it is not entirely unheard of that the interactions with the installer consist almost entirely of pressing the Enter key in response to the prompts with suggested default values. And if you have not read the afterboot(8) man page, now is likely a good time to give it at least a glance.

Note: This piece is also available without trackers but classic formatting only here.

Planning Ahead: One Release Every Six Months, The Two Most Recent Releases Are Supported

When you start poking around OpenBSD and learning how things are done, it is important to keep in mind that

  • The OpenBSD project makes two releases a year, with release dates normally falling on or around May 1st and November 1st.
  • The project offers security updates to the base system and packages for supported releases, currently the two most recent ones. See the FAQ item about OpenBSD flavors for further explanation.
  • Support is available primarily through the project mailing lists. In addition, user groups and commercial (paid) support options are available in several locations.

This means that there is no such thing as an OpenBSD Long Term Support (LTS) release, you are actually expected to upgrade to a supported version at least once a year.

At the time of this writing (late May 2026), the supported releases are OpenBSD 7.8, which was released on October 22nd, 2025, and the most recent release OpenBSD 7.9, released May 19th, 2026. Once OpenBSD 8.0 becomes available (the link will start working some time before the event), OpenBSD 7.8 support stops, and you need to move on to a supported release.

So once you are past the initial experimental phase, please start planning for how to maintain your systems. You will not regret doing those preparations down the road.


Protip: Before starting anything that produces output that likely scrolls off the top of your screen or window, start a script session so all visible events are preserved in the file you specify. See man script for details.

Your First Move After Install: Run syspatch

There you are, with a fresh install of a still supported release of OpenBSD.

The first thing to do is to check whether any security updates (patches) are available. The easiest way to check is to choose the Patches link from the main OpenBSD website. If you installed your release close enough to the release date, there may be no patches available yet, but you can rest assured that over the lifetime of a release, there will be some. Towards the end of their lifetimes some releases have seen twenty or more updates.

If you are on one of the more common platforms (amd64, arm64 or i386), you could even skip the manual check and let syspatch do the job for you (for the other 11 platforms, the old fashioned patch and make process, managed and verified via signify still applies, see the contents of each patch file).

To run the initial syspatch on a new system, log on with the user you created during the install process, then su to root, and run syspatch with no arguments.

If you have Internet connectivity and there are installable patches available, the command lists them as they are fetched and applied.

If no patches are available, the command exits quietly.

If the messages from syspatch or the patch description indicate that one or more services have been updated, make sure to restart those services to ensure that only the updated binary is loaded and running.

If the messages from syspatch or the patch description indicates that a reboot is required, please do reboot your system before proceeding. In that case, a shutdown -r now is likely appropriate before you go to the next steps.

For Administrative Tasks, doas Likely Fills Your Needs

With all available security in place for your OpenBSD base system, you more likely than not have a few more system administration tasks queued up, such as installing packages.

Performing those tasks require elevated privileges, so logging on as root may seem tempting. Please resist that temptation. It is much better if you only run with higher privileges when the situation actually requires it, and the OpenBSD base system has doas available for that purpose.

OpenBSD, like most of the Unixlikes around, used to rely on sudo for going to higher privileges, but feature creep happened over the years, and by the time OpenBSD 5.8 was released, we had doas available for "about 95% of the things people actually use".

Out of the box, doas comes almost ready to use.

As the man page hints, the command will only work with a valid /etc/doas.conf in place.

Fortunately, the configuration file man page offers an example that is a reasonable starting point. If you do cut and paste that one, please replace the user names aja and tedu with something appropriate for your local environment.

Simpler and more specific configurations are available, but even with those minimal edits, you will no longer need to log in as root or su to root to get things done.

Remove the Tedium From Services Management With rcctl

If your only OpenBSD system is your laptop, you probably do not need to worry about managing services at all. By default, a clean install runs no services.

The installer offered the option of enabling sshd for you, but accepting the offer is not actually a requirement. If you want to enable or otherwise manage services after install, you can get a lot done with rcctl, including enable, disable, start, stop, restart services and even set a service's parameters.

In short, you can get most of the operations you would need on your rc.conf.local file that you would imagine would require a text editor and perhaps a variety of kill commands done by targeted use of rcctl instead. Take a peek at the rcctl man page -- it's short, but useful and friendly.

For Anything Not In Base, Look to Packages with pkg_add and Other pkg_* Tools

A fresh OpenBSD install is a surprisingly full featured operating system. If you specified during install that you would be running the X windowing system, the system will offer a graphical login screen and present you with the fvwm window manager.

However, the default window manager may be perceived as too basic for some tastes, and in a typical end user scenario, you would typically want at least

  • A desktop environment
  • A web browser
  • A suite of office software

This is where the OpenBSD ports and packages system comes into play. For installing packages, the tool you want to use is pkg_add (for some background and examples of how to use the ports and packages system, see my earlier piece You've Installed It. Now What? Packages!, also available prettified and tracked here).

The OpenBSD packages collection offers several options for all three categories, and a common combination is
xfce for desktop environment,
firefox for web browsing and
libreoffice for the office suite.

For package installs on OpenBSD, the general procedure is,

find the package name (your guess is likely right or quite close),
run pkg_add packagename,
read any message the command outputs at the end, and follow the steps indicated.

If the package install outputs instructions, you will likely also find the instructions in /usr/local/share/doc/pkg-readmes/packagename, but the earlier advice to run anything important in a script session applies here too.

So in our desktop scenario the sequence would be

$ doas pkg_add xfce
follow the instructions the package message prints. You may need to log out and back in after this step (and yes, you can have each user specify their own separate desktop environment).

$ doas pkg_add firefox
follow the instructions the package message prints.

$ doas pkg_add libreoffice
follow the instructions the package message prints.

At this point, the packages you installed are ready to use, and you can browse the web and read and produce office documents to your heart's content. If you want a mail client too, several of the well known ones are available as packages. A simple pkg_add thunderbird will add one of the more popular ones to your set of locally installed software.

If you want to find further packages, the You've Installed It. Now What? Packages! article offers some pointers. If you do not want to install a full ports tree for search purposes only, the openbsd.app website offers a nice clickable interface.

Keeping Up to Date: Keep Running syspatch and pkg_add -u

Keeping an OpenBSD system updated is not difficult. You have already seen syspatch in action for pulling in security or reliability updates.

Over the lifetime of a -stable version of the release (which is what your system turns into after your first syspatch), more updates will inevitably become available, and you (your system administrator) should periodically check for any updates and install them in due course.

One useful way to automate the process is to set a cron job that runs syspatch -c (see the syspatch and crontab man pages) at reasonable intervals and mails the output to somebody relevant.

If you run several systems or even more than one OpenBSD version, you would be well advised to appoint one machine per version to be the syspatch canary in order to keep the noise level in your mailboxes or other alerts channels down to reasonable levels.

For keeping installed packages up to date, the command to use is pkg_add with the -u (update) flag.

The pkg_add command offers several other flags that affect its behavior, but the only ones of any real use in a production (stable) environment are the -v (verbose) and -m (print progress bars) options.

If the messages from pkg_add indicate that one or more services have been updated, make sure to restart those services to ensure that only the updated binaries are loaded and running.

At this point, you should have all the pieces in place for keeping your OpenBSD-stable systems in trim with the latest available fixes. Keep up with updates, and you should be OK for the supported lifetime of the code.

Jumping to the Next Release with sysupgrade

All good things come to an end eventually, and when a new release is available, or at the latest, when your present operating system is coming close to end of its supported life, it becomes necessary to upgrade to the next, newer release.

Fortunately, recent OpenBSD versions (since OpenBSD 6.6, in fact - released November 17th 2019), offers a command that offer a smooth upgrade for the most likely scenarios, called sysupgrade.

The sysupgrade command is designed to handle the somewhat complex upgrade process (see the earlier article Keeping Your OpenBSD System In Trim: A Works For Me Guide for some background -- also available tracked and prettified) with minimal user interaction.

The command is designed on the premise that the system to be upgraded is very close to a default install -- if you keep yourself with custom kernels or left out any of the default install sets during install, you are not part of the target audience, and you will be better served by the article referenced in the previous paragraph.

Before proceeding to upgrading to a new release, it is advisable to read the release notes for the new release to identify any changes that may require extra attention. Fortunately, the occasions when manual intervention is strictly needed are rare between releases.

When a new release is available, you upgrade to the next release (numbered by increments of 0.1 per convention) by running

$ doas sysupgrade

The command fetches the install sets for the new release, reboots into the installer, runs sysmerge to perform any needed updates to configuration files and reboots into the upgraded system.

If the sysmerge pass detects any changes that are beyond its automated capability, it will issue a warning that a manual sysmerge is needed. In most cases this will not be needed, however.

When you have the base system upgraded, you will likely want to upgrade to newer versions of any installed packages as well. The command needed is the same as the one you used previously to pull in packages with updates for any identified issues:

$ doas pkg_add -u

When upgrading packages after a system upgrade it is worth paying attention to any package messages and to check for any updates to the package readmes in the /usr/local/share/doc/pkg-readmes/ directory.

Once you have started upgrading packages (if not earlier) you will want to explore other package tools. Try apropos pkg for pointers on where to start exploring.

If you run into any problems, the support channels mentioned earlier in this piece will offer help in response to any reasonably formulated problem reports.

Ready For -current? The Same Tools, Used Slightly Differently

When you have been running OpenBSD stable versions for a while, you may be tempted to explore a bit further, and perhaps even be involved in developing the systems or packages or testing any new features or changes that will become available in upcoming releases.

This is when you may want to explore OpenBSD-current. The way in is to install a snapshot (from the snapshots directory on your favorite mirror). Just how to proceed is really up to you, but if you jump to running -current, you will probably make your life easier in debugging and development contexts if you keep fresh cvs checkout of the src and xenocara source trees as well as the ports tree.

Once you are running a snapshot, the maintenance and upgrade procedure changes slightly. As mentioned, it is advisable to keep sources and ports up to date (start with reading the Building the System from Source part of the FAQ).


Note: Keep in mind that snapshots track -current, and generally switch to post-release code some time before the release becomes available. At that point, upgrading from a snapshot to the upcoming release is no longer a supported option -- if you see a commit messages similar to this one (which marked the transition to 7.7-current), it's already too late.

For -current or snapshots, syspatch is not really relevant anymore. Instead you run the sysupgrade command with the -s flag:

$ doas sysupgrade -s

The command runs much like it would for -stable versions, but with a slightly elevated risk of needing to run a manually supervised sysmerge after booting into the upgraded system.

New snapshots are generally accompanied (or followed soon after) by updated packages, and running pkg_add -u after a successful sysupgrade -s generally makes sense.

Some of the debugging related pkg_add flags make more sense in a snapshot environment.

It is worth noting that for the brief period when -current reports a release equivalent version string (one without -current or -beta suffix) it is necessary to add "-D snap" to the pkg_add arguments in order to update packages correctly.

If you intend to contribute in any way, including testing, it is essentially required that you read the tech@ and bugs@ mailing lists and familiarize yourself with how to interact on those forums before posting.

The Way Forward

Hopefully this piece will clear up any confusion caused by me reposting recently the two pieces Keeping Your OpenBSD System In Trim: A Works For Me Guide for some background -- also available tracked and prettified and You've Installed It. Now What? Packages!, also available prettified and tracked here, which by now are more than a decade old.

The pieces still contain mostly correct reference information, but informed readers will notice that they predate the introduction of syspatch and the availability of updated packages for -stable available via pkg_add -u.

Please keep in mind that our favorite operating system OpenBSD is in constant and rapid developement, and that anything written about that system could be quite out of date even a few years from now. I hope to revisit this and other pieces to keep them reasonably in line with evolving realities. I welcome your comments and corrections via email or other channels such as whatever social medium brought you the link to this article.


Note: Updated several times, last on 2025-10-22 to mark the OpenBSD 7.8 release.

Resources For Further Reading

The OpenBSD FAQ

Michael W Lucas: Absolute OpenBSD, 2nd edition

Ted Unangst: doas Mastery

OpenBSD Journal News items about OpenBSD, generally short with references to material elsewhere.

Peter Hansteen: What every IT person needs to know about OpenBSD Part 1: How it all started,
What every IT person needs to know about OpenBSD Part 2: Why use OpenBSD?,
What every IT person needs to know about OpenBSD Part 3: That packet filter
(or the whole shebang in the raw here or with trackers at bsdly.blogspot.com)

Network Management with the OpenBSD Packet Filter toolset, by Peter N. M. Hansteen, Massimiliano Stucchi and Tom Smyth (A PF tutorial, this is the BSDCan 2024 edition). An earlier, even more extensive set of slides can be found in the 2016-vintage PF tutorial.

That Grumpy BSD Guy Blog posts by Peter N. M. Hansteen (prettified, tracked). New entries as well as still-relevant pieces that started out over there and have warranted updating will also be findable, untracked other than my webserver log, at https://nxdomain.no/~peter/blogposts/. Please let me know if there are pieces you think would warrant liberation to that space.


You Have Installed OpenBSD. Now For The Daily Tasks. is © 2024 Peter N. M. Hansteen (published 2024-09-02, updated several times, last 2026-05-19)
You might also be interested in reading selected pieces via That Grumpy BSD Guy: A Short Reading List (also here).

Separately, The Book of PF, 4th edition is now available. For a little background, see the blog post Yes, The Book of PF, 4th Edition Is Coming Soon (also here).


Sunday, July 1, 2012

Keeping Your OpenBSD System In Trim: A Works For Me Guide

Keeping your OpenBSD systems in trim is dead easy. Occasional reboots are inevitable, but then that's where our famous redundancy features really shine, right? Read on for notes on upgrading your system. (Most of the steps here are relevant for new installs too, but do visit the Install Guide if you're new to OpenBSD.)

Note: If you're looking for a one-stop article, you will be better off with the 2024 update You Have Installed OpenBSD. Now For The Daily Tasks. (also available tracked, prettified), which covers the main care and feeding tasks.

Unless you have very specific requirements such as omitting sets, the base system upgrade can be performed painlessly with the sysupgrade(8) command followed by the sysmerge(8) and pkg_add(8) commands as described in this article. See the man pages or the OpenBSD FAQ for more information. (Updated 2021-07-02).

My upgrades always start with the same couple of commands:

$ cd ~/upgrade
$ ls -l
$ ncftp eu-openbsd
ncftp ...penBSD/snapshots/amd64 > dir

The first two commands of this sequence show me the date of the latest snapshot I downloaded, and the next two give me the date on what is on the OpenBSD European mirror site.

The ncftp bookmark eu-openbsd in this case expands to

ftp://ftp.eu.openbsd.org/pub/OpenBSD/snapshots/amd64/

which is appropriate for a North European like myself with an AMD64 based system on hand. If you're not in Europe, it's likely you're better off with some other choice of mirror. Check the Getting Releases page on the OpenBSD site for a mirror near you. And of course, do pick the correct architecture for your system.

If the files on the mirror server are newer than the ones I have locally, I'll download them with

ncftp ...penBSD/snapshots/amd64 > get *

If there are no updates, well, that means I'll just check back later.

And of course, if you do not have the ncftp package installed, this command will work on any OpenBSD box with a full base system installed:

$ ftp -ia ftp://ftp.eu.openbsd.org/pub/OpenBSD/snapshots/`uname -m`/{index.txt,*tgz,bsd*,INS*,BOOT*,BUILDINFO,SHA*}

(thanks, Pedro Caetano!)

One of the things that makes doing OpenBSD upgrades so amazingly easy is the sysmerge(8) program.  Much inspired by FreeBSD's classic mergemaster(8), this program is, as we shall see by executing the following commands,


$ which sysmerge
/usr/sbin/sysmerge
$ file `which sysmerge`
/usr/sbin/sysmerge: Korn shell script text executable

actually a shell script that makes extensive use of sdiff(1) to highlight the differences between your installed version of a configuration file and the one from the source tree or your install sets, and offers to merge (hence the name) your current customizations into the newer version files and install them on the spot if you like.

Do take a peek with at what the script does:

$ less /usr/sbin/sysmerge

possibly complemented by looking up the sdiff(1) man page if you want. But more about that later.

If you run regular upgrades like I tend to, with snapshots only days or at most a few weeks apart, the differences sysmerge(8) detects are likely few and trivial (but a word of caution: it usually pays to check the Following -current page from time to time).

If you do longer jumps, such as between releases, you will almost certainly find more differences, and in rare cases the changes in the configuration file baselines will be large enough that you will need to take some time out to edit the files by hand. In those cases, studying the upgrade notes relevant to your versions (and all intermediate ones if you do a long jump -- go to http://www.openbsd.org/faq/ and choose the Upgrade Guide link at the top of the left column) will be well worth your time.

The next step is to copy the fresh bsd.rd to the root directory of my boot disk:

$ doas cp bsd.rd /

With the bsd.rd in place, the next step is to reboot your system. Either choose your window manager's reboot option or simply from a shell prompt type

$ doas reboot

When the boot> prompt appears, type b bsd.rd and press Enter.

The familiar bsd.rd boot messages appear (much like the ones illustrated in my earlier installation piece, The Goodness Of Men And Machinery), and the first question you need to answer is:


(I)nstall, (U)pgrade or (S)hell?

Since we're upgrading, we type u (upper or lower case doesn't matter) and press Enter.

The next question up is the choice of keyboard layout:


Choose your keyboard layout ('?' or 'L' for list)

Here I type no for my Norwegian keyboard layout, if you want a different one you can get a list of available choices by typing L instead, and pressing Enter.

Once you've chosen your keyboard layout, the upgrade script prompts you to specify where your root file system is located. The upgrader's guess is only very rarely wrong, so more likely than not you'll just press Enter here.

The upgrader performs a full file system check on the designated root file system, and proceeds to configure any network interfaces it finds configuration files for in the designated root file systems etc directory. You will see the output of DHCP negotiations or similar.

When the network configuration is done, the upgrader prompts you to decide whether you want to perform a full file system check on the other partitions it finds.  The default choice here is no, so if you press enter here, the upgrade script simply runs a fsck -p on each of the file system listed in the system's fstab. You'll see the output for each one of these relatively lightweight checks.

Next, the upgrade script asks where to find the install sets:

Location of sets? (disk http or 'done') [disk]

Here, since I already downloaded the install set files to a local directory, the natural choice is disk. The upgrade script has already mounted all partitions from the system's fstab under /mnt/, so the files I downloaded to /home/peter/upgrade are now available under /mnt/home/peter/upgrade, and that's what I type in response to the prompt for where the sets are to be found.

Unless you have prepared a site.tgz for your site there is normally no reason to add or subtract sets from the default list, so pressing Enter will do nicely. The sets are copied and extracted, and when the extraction is done, you confirm that the upgrade is [done], and when the prompt appears, choose reboot (the default)

to let the system boot into the upgraded operating system.

Watch the system boot, and if you look closely, you will notice that on first boot the updated sysmerge(8) program runs and does the obvious things that do not require manual intervention, and if there are non-obvious things left, a message and an email to root alerts you of the need to do a manual sysmerge(8) run.

I tend to do a sysmerge run anyway after upgrade, if only to see it complete silently:

$ doas sysmerge

That's it! There is a chance that there have been updates to packages you have installed (such as ncftp in my case), so I tend to do a package upgrade pretty soon after rebooting into a freshly upgraded system. The basic update command is pkg_add -u, but I tend to want more verbose output and prompts and generally choose this variant:

$ doas pkg_add -vVuUmr

This command will most likely just work, fetching packages from the site and directory specified in /etc/installurl which is automagically created and maintained by the install program. If the installer somehow guessed wrong, you need to adjust the contents of that file and restart pkg_add (fiddling with the environment variable PKG_PATH as was the procedure in previous releases will not do any good). During the relatively short time when snapshots identify as the release but actual -release packages are not yet available (as in the recent 7.5 release cycle) you may have to adjust the pkg_add command to include -D snap, like this:

$ doas pkg_add -D snap -vuV

For upgrading from one snapshot to the next, there is really not much more to the process. You will occasionally want to run

$ doas pkg_delete -a

to remove packages that were installed as dependencies (mainly libraries) but are no longer needed. In addition, you may want to install and run sysclean to help you indentify other files such as obsolete configuration files that are no longer needed in your current configuration.

If you're upgrading from one release to the next, it makes sense to check the Errata page for any patches you need to apply to the release you're running.

An if you've read this far and found this interesting or useful, please head over to the OpenBSD Donations page to make a donation to the project.

Update 2017-04-17: Minor updates to adjust to the post-6.1 world, such as no more CDs. Thanks to Marc Espie for (as always) valuable input.

Update 2018-06-12: Modern man.openbsd.org links are much simpler now than when this was originally written, links updated. Also small tweaks to make the text reflect the user visible changes to the upgrade program.

Update 2019-04-26 + 2024-09-01: Now that you've read this piece to the end and have probably gone through more than a few manual steps, you will probably be pleased to hear that the process is now about to become significantly simpler in almost all cases.

Only hours after the news of the OpenBSD 6.5 release hit, the new sysupgrade(8) command was added to OpenBSD-current, and so will most likely be part of the OpenBSD 6.6 release, expected in about six months. In its present form, sysupgrade(8)  only performs the base system upgrade, so the pkg_add(8) parts mentioned in this piece will still be needed as a separate step. Further details will be available as development proceeds, but now you know about at least one thing to look forward to in OpenBSD 7.6 (due some time in late October to early November of 2024, with the release page starting to emerge some weeks ahead of that date.