Upgrade Guide: 5.4 to 5.5
[FAQ Index] | [5.3 -> 5.4] | [5.5 -> 5.6]
Note: Upgrades are only supported from one release to the release immediately following it. Do not skip releases. If you got lucky skipping releases in the past, you may not this time.
It is highly recommended that you read through and fully understand this process before attempting it. If you are doing it on a critical or physically remote machine, it is recommended that you test this process on an identical, local system to verify its success before attempting on a critical or remote computer.
Upgrading is a convenient way to bring your OpenBSD system up to the most recent version. However, the results are not intended to precisely match the results of a wipe-and-reload installation. Old library files in particular are not removed in the upgrade process, as they may be required by older applications that may or may not be upgraded at this time. If you REALLY wish to get rid of all these old files, you are probably better off reinstalling from scratch.
Table of Contents:
Before upgrading: things to think about and be aware of
This is not a complete list of the changes that took place between 5.4 and 5.5, but rather some of the important things that will impact users in the upgrade process. For a more complete list of changes, see plus55.html and the CVS change logs.- Year 2038 ready
(For those not aware, Unix historically used a signed 32 bit counter to track time. This will roll over in January, 2038, and flip back to December, 1901 if not fixed before then.)OpenBSD 5.5 is year 2038 ready on all platforms, but this required a change to a 64 bit time type, which should cover us for the next 290 billion years. This results in a "flag day" event, where old binaries will not run on the new kernel, and the new binaries won't run on the old kernel, and some file formats will be changing. A remote, no-console upgrade process is provided below, but it will be a more touchy process than usual. If you can possibly do this upgrade with a console, this is highly recommended. This may also be a good time to consider a reload from scratch or to rebuild on new hardware. It is suggested you practice remote upgrades on a similar system with similar applications with a local console before remotely upgrading critical systems.
The system accounting log will change format; extract any needed active accounting data from the system BEFORE upgrade. After the upgrade, you will be deleting a number of old files including the old accounting log file; a new one will be created on your next reboot.
If you are using ldapd(8), the btree database file format will not be compatible. To preserve data you must dump the contents of any databases (for example, to LDIF) and reload them afterward.
All packages and user-created binaries must be removed from the system prior to the upgrade, and reloaded afterwards.
Reminder: if you rely on anything from packages for management access to the system (for example: shells, VPN software, routing daemons, etc), arrange alternative access before removing packages.
Various packages use non-portable data formats in cache files, etc. If you run into problems it may be necessary to remove these.
Note that any conversions or data exports may need to be done BEFORE packages are unloaded and before the upgrade takes place.
- Releases signed
OpenBSD releases are now cryptographically signed using the new signify(1) utility. However, the install media with all file sets (install55.fs,install55.iso) cannot self-check, nor should they. After all, if someone has delivered a compromised install set to you, they would probably have set it to say "all is well."Instead, you should verify your install media file separately, then install without further concern.
- popa3d removed
The POP3 daemon has been removed. Alternatives are available in packages, such as: akpop3d, courier-pop3 and others. Note that sendmail will be removed for 5.6, so this might be a good time to reconsider your entire mail system design (note: OpenSMTPD can deliver directly to a Maildir). - identd(8)
has been replaced
The new version runs as a daemon, rather than from inetd(8). So, you will need to set your desired flags in/etc/rc.conf.localand remove them from/etc/inetd.conf. - pf queue changes
PF has a new implementation of packet queueing - the configuration
syntax is different to that used by altq.
During a transition period, the old mechanism is still available by
replacing "queue" keywords in /etc/pf.conf with "oldqueue".
If instead you wish to switch to the new implementation, review the
documentation in
pf.conf(5).
- smtpd.conf changes
smtpd(8) configuration file parser was updated. Some changes might require existing setups to be adapted.SSL certificates must be explicitly defined, and the "certificate" keyword becomes "pki" in listen and relay rules.
pki mail.example.com certificate "/etc/ssl/mail.example.com.crt" \ key "/etc/ssl/private/mail.example.com.key" listen on egress tls pki mail.example.com authThe "ssl" keyword in relay URLs becomes "secure".
table secrets file:/etc/mail/secrets accept for any relay via secure+auth://label@some.mx auth <secrets>
Rules matching on source address must use "from source" rather than just "from".
accept from source "192.168.0.0/16" for any relay
The "helo" keyword in relay rules becomes "hostnames".
accept for any relay source <source> hostnames <htable>
See smtpd.conf(5) for more details.
- No Java on i386
Be aware that Java is currently broken on i386, so packages are not available. If you rely on Java on OpenBSD, you will either need to make a new installation with the amd64 architecture (which supports 64-bit Intel CPUs as well as AMD CPUs), stay with an older version of OpenBSD, or upgrade to 5.6. - Multiboot users: may have to reconfigure for a relocated
/bootfile: Some multiboot systems utilize the process of grabbing a copy of the partition boot record (PBR) and using that to start the OpenBSD boot process. Historically, upgrades did not relocate/boot, so your old PBR would continue to work. The upgrade process of 5.5 WILL relocate/bootand regenerate the PBR, thus multiboot users that use a stored PBR will have to copy over the new PBR as they did originally. Failure to do this will result in an "ERR M" at boot. - Advanced notice: Big changes coming for future releases!
There are some big changes coming up in OpenBSD 5.6 and 5.7 (NOT 5.5!) that you may wish to think about and plan for.- Platforms removed for 5.6: hp300, mvme88k, mvme68k. This is expected to impact no serious users.
- OpenBSD's version of Apache 1.3 and nginx will be removed from base in favor of an internally developed httpd server in 5.6 and 5.7, respectively. Apache 1.3 and nginx will become a package for those with applications dependent upon it.
- sendmail will be removed from base in favor of OpenSMTPD, but sendmail will be available as a package.
- BIND (named) will be removed from base in 5.7 in favor of nsd(8) (authoritative DNS) and unbound(8) (recursive resolver). Packages will exist for BIND.
- FTP will no longer be an install option for 5.6. Instead, HTTP will be used. This should not impact users of public mirrors, but if you replicate internally, you may wish to make sure your files can be served by HTTP.
- Kerberos will be removed from base OpenBSD for 5.6, though should be available as a package.
- Check the kernel: Although most people can skip this step, if you had a modified kernel in 5.4, it is likely you will need to modify the stock kernel of 5.5. Especially when you are performing the upgrade process remotely, now is the time to make sure the new kernel will work upon rebooting the machine. If any changes must be made to the kernel, the safest thing to do is to make those changes on a local 5.5 system. This can be as simple as modifying a specific device using config(8), or it can involve a recompilation if the option you need is not included in the GENERIC kernel. Please consult FAQ 5 - Building the system from source before deciding to recompile your kernel.
The upgrade process
*Special process* Before Upgrading: uninstall packages!
Due to the time_t change, virtually all old binaries will not work on the upgraded system, so all packages must be removed PRIOR to upgrading.- Review and adjust your system so you can get access to it with NO packages installed -- i.e., not dependent upon added shells or special access systems. You might want to verify you can log in as root and that root uses a standard shell (i.e., ksh).
- Review the package notes below, before doing this, as some packages require prep BEFORE removal.
- Save a record of what packages you had installed, manually and
automatically:
pkg_info -mq >/root/pkg_list_manual pkg_info -q >/root/pkg_list_full
- Stop all packages. The next step will remove the scripts that gracefully shut them down, so they will be "hard-stopped" at the reboot, which may corrupt data if they are not stopped now. This is a good time to make sure that you aren't using any packages to access and maintain the system!
- Remove all packages (except firmware packages):
pkg_delete -X /var/db/pkg/*-firmware-[0-9]*
- If you have any other system binaries which you installed without using the package system, remove those as well.
Upgrading by install kernel
If you have access to the system's console, the easiest and safest way to upgrade is to boot from the install kernel by boot media or bsd.rd and follow the upgrade steps, which are very similar to the install process.Afterwards, complete the upgrade by following the final steps as detailed below.
One easy way to boot from the install kernel is to place the 5.5 version
of bsd.rd in the root of your boot drive, then instruct the boot loader
to boot using this new bsd.rd file.
On amd64 and i386, you do this by entering "boot bsd.rd" at the
initial boot> prompt.
Upgrading without install kernel
This is NOT the recommended process. Use the install kernel method if at all possible!Sometimes, one needs to do an upgrade of a machine when one can't easily use the normal upgrade process. The most common case is when the machine is in a remote location and you don't have easy access to the system console. One can usually do this by carefully following this process:
- Place install files in a "good" location.
Make sure you have sufficient space!
Running out of space on a remote upgrade could be...unfortunate.
Note that using softdeps can exaggerate the situation as deleted and
overwritten files do not release their space immediately.
Having at least 200MB free on /usr would be recommended.
- Prepare for first reboot after time_t change.
The time_t change requires rebuilding a some files, including the
/etc/master.passwordfile. Without this being done, you cannot log in after the reboot! This is done automatically by the upgrade script, but has to be done manually on first boot after upgrade by creating a/etc/rc.firsttime:
This will regenerate the password file and delete a couple files that will not work after the time_t change.echo "/usr/sbin/pwd_mkdb -d /etc /etc/master.passwd" >>/etc/rc.firsttime echo "cp /dev/null /var/log/lastlog" >>/etc/rc.firsttime echo "cp /dev/null /var/log/wtmp" >>/etc/rc.firsttime
- Become root with ksh(1):
While using
sudo(8)
before each command is generally a good practice, the sudo(8) command
will be broken by the last steps, so you should be root before starting
this process.
Also, the use of the OpenBSD
ksh(1)
shell is assumed.
- Stop any appropriate applications:
During this process, all the userland applications will be replaced but
may not be runnable, and strange things may happen as a result.
Shutdown scripts will not be able to run!
There may be other applications which you wish to keep from running
immediately after the upgrade, stop and disable them as well.
- Disable package daemons and local shutdown commands:
The last steps in the upgrade process may result in various commands,
especially those which are dynamically linked, being broken.
In particular, this may prevent a normal shutdown of daemons listed
in pkg_scripts, or additional commands in /etc/rc.shutdown, which may
cause the machine to hang at shutdown.
Before you proceed with the upgrade, edit /etc/rc.conf.local and
comment out any pkg_scripts lines.
Also, inspect /etc/rc.shutdown and comment out any local shutdown commands.
These can be reinstated post upgrade.
- Install new boot blocks:
This should actually be done at the end of any upgrade, but we will
assume this has been neglected.
Failure to do this may break serial console or other things, depending
on platform.
See the man page for installboot(8) for YOUR platform and your current version of OpenBSD, but for i386/amd64 v5.4, assuming you boot from sd0, you will want to do something like this:
Note that snapshot users may have a very different installboot(8) process!cd /usr/mdec cp boot /boot ./installboot -v /boot ./biosboot sd0
- Install new kernel(s):
- If using a single processor kernel:
(note: you will get a harmless error message if your platform doesn't have a bsd.mp):export RELEASEPATH=/usr/rel # where you put the files cd ${RELEASEPATH} rm /obsd ; ln /bsd /obsd && cp bsd /nbsd && mv /nbsd /bsd cp bsd.rd bsd.mp / - If you are using the multiprocessor kernel:
export RELEASEPATH=/usr/rel # where you put the files cd ${RELEASEPATH} rm /obsd ; ln /bsd /obsd && cp bsd.mp /nbsd && mv /nbsd /bsd cp bsd.rd / cp bsd /bsd.sp
Note the extra steps for copying over the primary kernel: those are done to ensure that there is always a valid copy of the kernel on the disk that the system can boot from should there be a really badly timed power outage or system crash. For this upgrade, however, this is not a major concern. You need to upgrade the kernel and userland together here, or things will not work.
- If using a single processor kernel:
- Save a copy of reboot(8), install new userland applications.
You are still running the old kernel, it is possible the new reboot
command will not run on the old kernel, so we will start by saving a
copy of the old reboot command.
Do NOT install
etc55.tgzandxetc55.tgznow, because that will overwrite your current configuration files! Note that we are installing base55.tgz LAST, because it will include a new tar(1) utility, which may or may not run on the old kernel. We reboot immediately, as the system is probably barely runnable after the unpacking of all the new files.
Not all file sets will need to be installed for all applications, however if you installed a file set originally, you should certainly upgrade it with the new file set now.cp /sbin/reboot /sbin/oreboot tar -C / -xzphf xserv55.tgz tar -C / -xzphf xfont55.tgz tar -C / -xzphf xshare55.tgz tar -C / -xzphf xbase55.tgz tar -C / -xzphf game55.tgz tar -C / -xzphf comp55.tgz tar -C / -xzphf man55.tgz tar -C / -xzphf base55.tgz # Install last! /sbin/oreboot
Again, the files in
/etcare handled separately below, soetc55.tgzandxetc55.tgzare NOT unpacked here. - After reboot completes, upgrade
/dev. The new MAKEDEV file was copied to /dev by the installation ofbase55.tgz, so you simply need to do the following:cd /dev ./MAKEDEV all
- Install the upgraded boot loader:
Note that for OpenBSD 5.5,
installboot(8)
has been "unified" across platforms, so a common (and simplified!) syntax
can be used:
assuming "sd0" is your boot disk.installboot -v sd0
Final steps
Whether you upgrade by using an install kernel and doing a formal "upgrade" process, or do a "in-place" binary upgrade, you need to do a few final steps to complete the upgrade.
1. Merging changed files via sysmerge(8)
The sysmerge(8) utility will compare the files that are actually on your system with those that would be installed in a fresh install, and assist you in merging the changes into your system. There are no assumptions made about what is actually on your system, so you can use sysmerge(8) to move between more arbitrary points in the development process, such as from an earlier 5.4-current to 5.5-release or from one -current to a later one. Sysmerge(8) compares the current files on your system with the files that would have been installed with a new install, and what would have been there from the last run of sysmerge. Usually, it can figure out what to do to update your files. If it has difficulty, it will give you the option of keeping the old file, installing the new file, or assisting you in the manual merging of the old and new files, using sdiff.Please read the sysmerge(8) manual page before using it on your system. You are also advised to read the diff(1), sdiff(1) and even review more(1) manual pages before continuing. A wide terminal window (i.e., significantly more than 80 characters), if available, will make sdiff(1) easier to use.
Assuming the SHA256.sig, etc55.tgz and xetc55.tgz files exists in
your ${RELEASEPATH}, run it with:
sysmerge -s ${RELEASEPATH}/etc55.tgz -x ${RELEASEPATH}/xetc55.tgz
(if you don't have SHA256.sig available, use the -S option to skip the
signature check)
For the files sysmerge(8) can't resolve on its own, it will show you a
unified
diff(1),
run through your favorite $PAGER (i.e.,
more(1))
and ask you if you wish to:
Use 'd' to delete the temporary ./var/www/htdocs/index.html Use 'i' to install the temporary ./var/www/htdocs/index.html Use 'm' to merge the temporary and installed versions Use 'v' to view the diff results again Default is to leave the temporary file to deal with by hand
If you wish to retain your existing file, delete the temporary file. If you wish to replace your existing file with the new version, install the temporary file. If you wish to merge the two together, choosing 'm' will put you into sdiff(1), where you can manually merge the file. The default is to come back and deal with the file later, manually.
Sysmerge(8) saves all your replaced files into a temporary directory,
similar to /var/tmp/sysmerge.24959/backups, so if you accidentally
clobber something that was probably not such a good idea, you have a chance
to recover it. Note that
daily(8)
cleans old files from this directory, but it will survive a reboot.
2. Files to delete and move
Some files should be deleted from your system, and others must be moved or updated. Note that some of these may not exist on all systems; that's ok. Copy and paste the following lines:
rm -f /usr/libexec/identd
rm -f /usr/lib/libcompat.a /usr/lib/libcompat_p.a
rm -f /usr/include/{re_comp,regexp,sgtty,sys/timeb}.h
rm -f /usr/share/man/man3/{re_comp,re_exec,rexec,regexp}.3
rm -f /usr/share/man/man3/{cuserid,ftime,gtty,setrgid,setruid,stty}.3
rm -f /etc/rc.d/popa3d
rm -f /usr/bin/{crunchgen,nawk}
rm -f /usr/sbin/{iopctl,popa3d}
rm -f /usr/share/man/man8/{iopctl,popa3d}.8
rm -rf /usr/X11R6/include/freetype2/freetype
rm -f /usr/X11R6/include/ft2build.h
rm -f /usr/mdec/installboot
rm -f /usr/share/man/man8/{amd64,i386}/installboot.8
rm -f /var/account/acct
rm -f /var/games/tetris.scores
mv /etc/nsd.conf /var/nsd/etc/nsd.conf
cd /usr/sbin && rm nsd-notify nsd-patch nsd-xfer nsd-zonec nsdc
cd /usr/share/man/man8 && rm nsd-notify.8 nsd-patch.8 nsd-xfer.8 \
nsd-zonec.8 nsdc.8
chown _nsd /var/nsd/db/nsd.db
printf '\nremote-control:\n\tcontrol-enable: yes\n' >> /var/nsd/etc/nsd.conf
Further, for the updated version of
nsd(8)
- If you use "include" lines in nsd.conf, move the files into the chroot path (/var/nsd) and change the include lines to specify the full path (include: "/var/nsd/etc/nsd.local"). NSD strips the chroot prefix as needed.
- Remove any old cron jobs that run "nsdc patch" as this is no longer needed. If you wish to write slaved zones to the readable data files, you may want to change this for a 'nsd-control write' job.
- Check nsd_flags in /etc/rc.conf.local; NSD is now started by nsd-control(8), and flags must be from the smaller set valid for this program, rather than nsd(8) as was previously the case.
- It is no longer necessary to compile zone files manually with zonec. This is now handled automatically by the main program. Please note that zone files must be readable by either the _nsd user or group.
3. Checking the kernel
Note: most people can skip this step!If you followed the instructions for the upgrade process without install kernel, you have already completed this step. However, if you used the install kernel, and if you had a modified kernel in 5.4, it is likely you will need to modify the stock kernel of 5.5. This can be as simple as modifying a specific device using config(8), or it can involve a recompilation if the option you need is not included in the GENERIC kernel. Please consult FAQ 5 - Building the system from source before considering to recompile your kernel.
4. Upgrading packages
If you installed any packages on your system, you should upgrade them after completing the upgrade of the base system. Be aware, however, many packages will require further setup before and/or after upgrading the package. Check with the application's upgrade guide for details.The following packages are known to have significant upgrade issues that will impact users. The fact that a package is not on this list doesn't mean it will have a trivial upgrade. You must do some homework on the applications YOU use.
- rrdtool:
the binary RRD database file
format on 32-bit architectures will not be compatible.
Export any RRD files to XML format before updating:
After updating, restore them as follows:# Single file: rrdtool dump filename.rrd filename.xml # To convert a batch: for i in *.rrd; do rrdtool dump $i ${i%.rrd}.xml; done
This is not necessary on 64-bit architectures (amd64, sparc64, etc).# Single file: rrdtool restore filename.xml filename.rrd # To convert a batch: for i in *.xml; do rrdtool restore $i ${i%.xml}.rrd; doneRRDtool has changed to using Cairo/Pango for graph and text generation. If using it in a chroot jail (for cgi/php scripts, etc), you will need to take additional steps to install the relevant files. A script is provided to copy the relevant libraries and support files; see /usr/local/share/doc/pkg-readmes/rrdtool-1.4.8 for more details.
- postgresql: Postgresql has had a major version upgrade which requires the usual dump+restore cycle as described in the upgrade notes (see /usr/local/share/doc/pkg-readmes/postgresql*). The old database must be dumped *before* upgrading OpenBSD. Also note that because all old packages are removed, the normal warning from pkg_add at update time is not triggered.
- php:
The primary PHP version used in ports has switched to 5.4.
This change means that if you run PHP applications packaged in ports,
you will need to switch your webserver config to use the newer version
of PHP.
Check /etc/php-5.3.ini for changes from the default configuration:
and carry them across to /etc/php-5.4.ini. You will also need to check for links to any active PHP extension modules in /etc/php-5.3 and re-create them in /etc/php-5.4, e.g.diff /usr/local/share/examples/php-5.3/php.ini-production /etc/php-5.4.ini
If you are currently using PHP with Apache in base, you will also need to adjust your Apache configuration:cd /etc/php-5.4 ls -l ../php-5.4.sample ln -s ../php-5.4.sample/pdo_mysql.ini . # (etc)
cd /var/www/conf/modules ln -fs /var/www/conf/modules.sample/php-5.4.conf /var/www/conf/modules/php.conf
- dspam:
If you were using one of the mysql or pgsql FLAVORS of the dspam package
you will have to manually install the corresponding driver subpackage after the
upgrade to the 3.10.2 version.
If you were using dspam with the PostgreSQL driver:
pkg_add dspam-pgsql
If you were using dspam with the MySQL driver:pkg_add dspam-mysql
- wordpress 3.6.1:
The twentyeleven theme from wordpress 3.5.x is no longer included with
wordpress 3.6.x. If you are using this theme, back it up before updating:
cd /var/www/wordpress/wp-content/themes && cp -Rp twentyeleven twentyeleven.bak
and restore it after wordpress update:cd /var/www/wordpress/wp-content/themes && mv twentyeleven.bak twentyeleven
- Apache Subversion 1.8.3:
Apache Subversion has been upgraded to version 1.8.3.
This release of Subversion updates the working copy format (client-side).
Existing working copies need to be upgraded using
svn upgradebecause Subversion 1.8 cannot operate with older working copy formats. See the section about working copy upgrades in Subversion's release notes for details. The server is fully backwards compatible and will serve existing repositories just fine. However, to take advantage of new FSFS repository features a repository upgrade is necessary. See the section about FSFS enhancements for details. - lout-doc:
lout-doc was merged into the lout package, so need not be manually re-added.
- ngircd:
ngircd's configuration directory has changed.
If updating from a previous version, you will need to move your old
configuration file into place:
mv /etc/ngircd.conf /etc/ngircd/ngircd.conf
Additional steps may be needed if you have configured it to use a motd file, ssl or chroot. - icinga 1.10:
Note that the deprecated (and ignored) "log_external_commands_user" option
has been removed from Icinga.
If this is present in your configuration, Icinga will fail to start until
you remove it.
This is in addition to the database schema upgrades that are needed as
usual for Icinga-web/NDOUtils users (see the pkg-readme for more
information).
- openldap and other packages with persistent Berkeley DB databases:
There are three levels of file formatting/encoding involved in
Berkeley DB (BDB) databases:
- the Berkeley DB shared memory files
__db.* - the Berkeley DB database file formats (
*.dbandlog.*) - the data stored in the database keys and values
The BDB database file formats are independent of the sizes of the system types and therefore don't need any special treatment during the upgrade. (While endian-aware, the files are more efficiently accessed when do so with the same endianness as when originally created.)
The last level, the data stored in the database keys and values, is strictly dependent on the application. OpenLDAP appears to be independent of the sizes of the system
time_ttype, but other applications may require application-level dump and restore when transitioning from 5.4 to 5.5. - the Berkeley DB shared memory files
Usually at this point, you would update the packages, but since they were all unloaded BEFORE the upgrade, you have to reinstall based on your lists of saved packages before:
Read the pkg_add(1) manual page and the package management chapter of the FAQ for more information.pkg_add -z -l /root/pkg_list_manual pkg_add -za -l /root/pkg_list_full
[FAQ Index] | [5.3 -> 5.4] | [5.5 -> 5.6]
$OpenBSD: upgrade55.html,v 1.52 2026/03/10 10:23:28 sthen Exp $