<!doctype html>
<html lang=en id=faq>
<title>OpenBSD Upgrade Guide: 5.4 to 5.5</title>
<meta charset=utf-8>
<meta name="description" content="OpenBSD Upgrade Process for 5.4 -> 5.5">
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="stylesheet" type="text/css" href="../openbsd.css">
<link rel="canonical" href="https://www.openbsd.org/faq/upgrade55.html">
<h2 id=OpenBSD>
<a href="../index.html">
<i>Open</i><b>BSD</b></a>
Upgrade Guide: 5.4 to 5.5
</h2>
<hr>
<p>
<a href="index.html">[FAQ Index]</a> |
<a href="upgrade54.html">[5.3 -> 5.4]</a> |
<a href="upgrade56.html">[5.5 -> 5.6]</a>
<p>
<i>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.</i>
<p><i>
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.
</i>
<p>
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.
<p>
Table of Contents:
<ul>
<li><a href="#before">Before upgrading</a>
<ul>
<li><a href="#time_t">Year 2038 ready</a>
<li><a href="#signed">Releases signed</a>
<li><a href="#popa3d">popa3d removed</a>
<li><a href="#identd">identd(8) replaced</a>
<li><a href="#pfqueue">pf queue changes</a>
<li><a href="#smtpd.conf">smtpd.conf changes</a>
<li><a href="#noi386java">No Java on i386</a>
<li><a href="#multibooters">Multiboot users</a>
<li><a href="#headsup">Advanced notice: Big changes coming!</a>
<li><a href="#chkkern">Check the kernel</a>
</ul>
<li><a href="#upgrade">The upgrade process</a>
<li><a href="#final">Final steps</a>
<ul>
<li><a href="#sysmerge">Merging changed files via sysmerge(8)</a>
<li><a href="#RmFiles">Files to delete and move</a>
<li><a href="#Kernchk">Checking the kernel</a>
<li><a href="#Pkgup">Upgrading packages</a>
</ul>
</ul>
<hr>
<p>
<h2 id="before">Before upgrading: things to think about and be aware of</h2>
This is <i>not</i> 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
<a href="../plus55.html">plus55.html</a> and the CVS change logs.
<ul>
<li id="time_t"><b>Year 2038 ready</b><br>
(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.)
<p>
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.
<p>
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.
<p>
If you are using
<a href="https://man.openbsd.org/ldapd.8">ldapd(8)</a>,
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.
<p>
All packages and user-created binaries must be removed from the system
prior to the upgrade, and reloaded afterwards.
<p>
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.
<p>
Various packages use non-portable data formats in cache files, etc.
If you run into problems it may be necessary to remove these.
<p>
Note that any conversions or data exports may need to be done BEFORE
packages are unloaded and before the upgrade takes place.
<li id="signed"><b>Releases signed</b><br>
OpenBSD releases are now cryptographically signed using the new
<a href="https://man.openbsd.org/signify.1">signify(1)</a>
utility.
However, the install media with all file sets (<code>install55.fs</code>,
<code>install55.iso</code>) 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."
<p>
Instead, you should <a href="faq4.html#Download">verify your install media
file</a> separately, then install without further concern.
<p>
<li id="popa3d"><b>popa3d removed</b><br>
The POP3 daemon has been removed.
Alternatives are available in packages, such as:
<a href="https://www.synflood.at/akpop3d.html">akpop3d</a>,
<a href="http://www.courier-mta.org/pop3d.html">courier-pop3</a>
and others.
Note that sendmail will be <a href="#headsup">removed</a> 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).
<p>
<li id="identd"><b><a href="https://man.openbsd.org/identd.8">identd(8)</a>
has been replaced</b><br>
The new version runs as a daemon, rather than from
<a href="https://man.openbsd.org/inetd.8">inetd(8)</a>.
So, you will need to set your desired flags in <code>/etc/rc.conf.local</code>
and remove them from <code>/etc/inetd.conf</code>.
<p>
<li id="pfqueue"><b>pf queue changes</b>
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
<a href="https://man.openbsd.org/pf.conf.5">pf.conf(5)</a>.
<p>
<li id="smtpd.conf"><b>smtpd.conf changes</b><br>
<a href="https://man.openbsd.org/smtpd.8">smtpd(8)</a>
configuration file parser was updated.
Some changes might require existing setups to be adapted.
<p>
SSL certificates must be explicitly defined,
and the "certificate" keyword becomes "pki" in listen and relay rules.
<pre>
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 auth
</pre>
<p>
The "ssl" keyword in relay URLs becomes "secure".
<pre>
table secrets file:/etc/mail/secrets
accept for any relay via secure+auth://label@some.mx auth <secrets>
</pre>
<p>
Rules matching on source address must use "from source" rather than just "from".
<pre>
accept from source "192.168.0.0/16" for any relay
</pre>
<p>
The "helo" keyword in relay rules becomes "hostnames".
<pre>
accept for any relay source <source> hostnames <htable>
</pre>
<p>
See <a href="https://man.openbsd.org/smtpd.conf.5">smtpd.conf(5)</a>
for more details.
<p>
<li id="noi386java"><b>No Java on i386</b><br>
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.
<p>
<li id="multibooters"><b>Multiboot users: may have to reconfigure for a relocated
<code>/boot</code> file:</b>
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 <code>/boot</code>, so your old PBR
would continue to work.
The upgrade process of 5.5 WILL relocate <code>/boot</code> and 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 "<code>ERR M</code>" at boot.
<p>
<li id="headsup"><b>Advanced notice: Big changes coming for future releases!</b><br>
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.
<ul>
<li>Platforms removed for 5.6: hp300, mvme88k, mvme68k.
This is expected to impact no serious users.
<li>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 <a href="faq15.html">package</a> for
those with applications dependent upon it.
<li>sendmail will be removed from base in favor of
<a href="https://www.opensmtpd.org">OpenSMTPD</a>, but sendmail will be
available as a package.
<li>BIND (named) will be removed from base in 5.7 in favor of
<a href="https://man.openbsd.org/nsd.8">nsd(8)</a>
(authoritative DNS) and
<a href="https://man.openbsd.org/unbound.8">unbound(8)</a>
(recursive resolver).
Packages will exist for BIND.
<li>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.
<li>Kerberos will be removed from base OpenBSD for 5.6, though should be
available as a package.
</ul>
<p>
<li id="chkkern"><b>Check the kernel:</b>
Although <b>most people can skip this step</b>, 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
<a href="https://man.openbsd.org/config.8">config(8)</a>,
or it can involve a recompilation if the option you need is not included
in the GENERIC kernel.
Please consult <a href="faq5.html">FAQ 5 - Building the system from source</a>
before deciding to recompile your kernel.
</ul>
<p>
<hr>
<h2 id="upgrade">The upgrade process</h2>
<h3>*Special process* Before Upgrading: uninstall packages!</h3>
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.
<ul>
<li>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).
<li>Review the <a href="#Pkgup">package notes</a> below, before doing
this, as some packages require prep BEFORE removal.
<li>Save a record of what packages you had installed, manually and
automatically:
<blockquote><pre>
<b>pkg_info -mq >/root/pkg_list_manual
pkg_info -q >/root/pkg_list_full</b>
</pre></blockquote>
<li>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!
<li>Remove all packages (except firmware packages):
<blockquote><pre>
<b>pkg_delete -X /var/db/pkg/*-firmware-[0-9]*</b>
</pre></blockquote>
<li>If you have any other system binaries which you installed without
using the package system, remove those as well.
</ul>
<h3>Upgrading by install kernel</h3>
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
<a href="faq4.html#bsd.rd">bsd.rd</a> and follow the upgrade steps,
which are very similar to the <a href="faq4.html">install process</a>.
<p>
Afterwards, complete the upgrade by following the <a href="#final">final
steps</a> as detailed below.
<p>
One easy way to boot from the install kernel is to place the 5.5 version
of <i>bsd.rd</i> in the root of your boot drive, then instruct the boot loader
to boot using this new <i>bsd.rd</i> file.
On amd64 and i386, you do this by entering "<code>boot bsd.rd</code>" at the
initial <code>boot></code> prompt.
<h3>Upgrading without install kernel</h3>
<i>This is NOT the recommended process. Use the install kernel method
if at all possible!</i>
<p>
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:
<ul>
<li><b>Place install files in a "good" location</b>.
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.
<p>
<li><b>Prepare for first reboot after time_t change</b>.
The time_t change requires rebuilding a some files, including the
<code>/etc/master.password</code> file.
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 <code>/etc/rc.firsttime</code>:
<blockquote><pre>
<b>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</b>
</pre></blockquote>
This will regenerate the password file and delete a couple files that will
not work after the time_t change.
<p>
<li><b>Become root with ksh(1):</b>
While using
<a href="https://man.openbsd.org/sudo.8">sudo(8)</a>
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
<a href="https://man.openbsd.org/ksh.1">ksh(1)</a>
shell is assumed.
<p>
<li><b>Stop any appropriate applications:</b>
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.
<p>
<li><b>Disable package daemons and local shutdown commands:</b>
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.
<p>
<li><b>Install new boot blocks:</b>
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.
<p>
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:
<blockquote><pre>
<b>cd /usr/mdec
cp boot /boot
./installboot -v /boot ./biosboot sd0</b>
</pre></blockquote>
Note that snapshot users may have a very different installboot(8) process!
<p>
<li><b>Install new kernel(s):</b>
<ul>
<li>If using a single processor kernel:
<blockquote><pre>
<b>export RELEASEPATH=</b><i>/usr/rel</i> <i># where you put the files</i>
<b>cd ${RELEASEPATH}</b>
<b>rm /obsd ; ln /bsd /obsd && cp bsd /nbsd && mv /nbsd /bsd</b>
<b>cp bsd.rd bsd.mp /</b>
</pre></blockquote>
(note: you will get a harmless error message if your platform doesn't
have a bsd.mp):
<p>
<li>If you are using the multiprocessor kernel:
<blockquote><pre>
<b>export RELEASEPATH=</b><i>/usr/rel</i> <i># where you put the files</i>
<b>cd ${RELEASEPATH}</b>
<b>rm /obsd ; ln /bsd /obsd && cp bsd.mp /nbsd && mv /nbsd /bsd</b>
<b>cp bsd.rd /</b>
<b>cp bsd /bsd.sp</b>
</pre></blockquote>
</ul>
<p>
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.
<p>
<li><b>Save a copy of reboot(8), install new userland applications.</b>
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.
<i>Do NOT install <code>etc55.tgz</code> and <code>xetc55.tgz</code> now, because
that will overwrite your current configuration files!</i>
Note that we are installing base55.tgz LAST, because it will include a new
<a href="https://man.openbsd.org/tar.1">tar(1)</a>
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.
<blockquote><pre>
<b>cp /sbin/reboot /sbin/oreboot</b>
<b>tar -C / -xzphf xserv55.tgz</b>
<b>tar -C / -xzphf xfont55.tgz</b>
<b>tar -C / -xzphf xshare55.tgz</b>
<b>tar -C / -xzphf xbase55.tgz</b>
<b>tar -C / -xzphf game55.tgz</b>
<b>tar -C / -xzphf comp55.tgz</b>
<b>tar -C / -xzphf man55.tgz</b>
<b>tar -C / -xzphf base55.tgz</b> # Install last!
<b>/sbin/oreboot</b>
</pre></blockquote>
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.
<p>
Again, the files in <code>/etc</code> are handled separately below, so
<code>etc55.tgz</code> and <code>xetc55.tgz</code> are NOT unpacked here.
<p>
<li><b>After reboot completes, upgrade <code>/dev</code>.</b>
The new
<a href="https://man.openbsd.org/OpenBSD-5.5/i386/MAKEDEV">MAKEDEV</a>
file was copied to /dev by the installation of
<code>base55.tgz</code>, so you simply need to do the following:
<blockquote><pre>
<b>cd /dev</b>
<b>./MAKEDEV all</b>
</pre></blockquote>
<li><b>Install the upgraded boot loader:</b>
Note that for OpenBSD 5.5,
<a href="https://man.openbsd.org/installboot.8">installboot(8)</a>
has been "unified" across platforms, so a common (and simplified!) syntax
can be used:
<blockquote><pre>
<b>installboot -v sd0</b>
</pre></blockquote>
assuming "sd0" is your boot disk.
</ul>
<hr>
<h2 id="final">Final steps</h2>
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.
<p>
<h3 id="sysmerge">1. Merging changed files via sysmerge(8)</h3>
The
<a href="https://man.openbsd.org/sysmerge.8">sysmerge(8)</a>
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 <a href="faq5.html#Flavors">points in the
development process</a>, such as from an earlier <i>5.4-current</i> to
<i>5.5-release</i> or from one <i>-current</i> 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
<a href="https://man.openbsd.org/sdiff.1">sdiff</a>.
<p>
Please read the
<a href="https://man.openbsd.org/sysmerge.8">sysmerge(8)</a>
manual page before using it on your system.
You are also advised to read the
<a href="https://man.openbsd.org/diff.1">diff(1)</a>,
<a href="https://man.openbsd.org/sdiff.1">sdiff(1)</a>
and even review
<a href="https://man.openbsd.org/more.1">more(1)</a>
manual pages before continuing.
A wide terminal window (i.e., significantly more than 80 characters), if
available, will make sdiff(1) easier to use.
<p>
Assuming the <code>SHA256.sig</code>, <code>etc55.tgz</code> and <code>xetc55.tgz</code> files exists in
your ${RELEASEPATH}, run it with:
<blockquote><pre>
<b>sysmerge -s ${RELEASEPATH}/etc55.tgz -x ${RELEASEPATH}/xetc55.tgz</b>
</pre></blockquote>
(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
<a href="https://man.openbsd.org/diff.1">diff(1)</a>,
run through your favorite $PAGER (i.e.,
<a href="https://man.openbsd.org/more.1">more(1)</a>)
and ask you if you wish to:
<blockquote><pre>
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
</pre></blockquote>
<p>
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
<a href="https://man.openbsd.org/sdiff.1">sdiff(1)</a>,
where you can manually merge the file.
The default is to come back and deal with the file later, manually.
<p>
Sysmerge(8) saves all your replaced files into a temporary directory,
similar to <code>/var/tmp/sysmerge.24959/backups</code>, so if you accidentally
clobber something that was probably not such a good idea, you have a chance
to recover it. Note that
<a href="https://man.openbsd.org/daily.8">daily(8)</a>
cleans old files from this directory, but it will survive a reboot.
<!-- p>
<b>Sysmerge notes for 5.3 -> 5.4:</b><br>
<ul>
<li><b><code>/etc/sysctl.conf</code>:</b>
The changes to <code>sysctl.conf</code> are all commented out items, so not
installing the changed file will not directly change your system's
behavior.
Blindly installing the new default over your old, customized file
will often cause significant annoyance.
However, the new file shows the defaults and common options that are
available, so you may wish to manually merge the changes into your file,
or install the new file and put your changes back into the new file.
</ul -->
<h3 id="RmFiles">2. Files to delete and move</h3>
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:
<blockquote><pre>
<b>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
</b></pre></blockquote>
Further, for the updated version of
<a href="https://man.openbsd.org/nsd.8">nsd(8)</a>
<ul>
<li>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.
<li>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.
<li>Check nsd_flags in /etc/rc.conf.local; NSD is now started by
<a href="https://man.openbsd.org/nsd-control">nsd-control(8)</a>,
and flags must be from the smaller set valid for this program, rather than
<a href="https://man.openbsd.org/nsd">nsd(8)</a>
as was previously the case.
<li>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.
</ul>
<h3 id="Kernchk">3. Checking the kernel</h3>
Note: <b>most people can skip this step!</b>
<p>
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 <a href="faq5.html">FAQ 5 - Building the system from source</a>
before considering to recompile your kernel.
<p>
<h3 id="Pkgup">4. Upgrading packages</h3>
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.
<p>
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.
<ul>
<li><b>rrdtool:</b>
the binary RRD database file
format on 32-bit architectures will not be compatible.
Export any RRD files to XML format before updating:
<blockquote><pre>
# Single file:
rrdtool dump filename.rrd filename.xml
# To convert a batch:
for i in *.rrd; do rrdtool dump $i ${i%.rrd}.xml; done
</pre></blockquote>
After updating, restore them as follows:
<blockquote><pre>
# Single file:
rrdtool restore filename.xml filename.rrd
# To convert a batch:
for i in *.xml; do rrdtool restore $i ${i%.xml}.rrd; done
</pre></blockquote>
This is not necessary on 64-bit architectures (amd64, sparc64, etc).
<p>
RRDtool 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 <a href="https://cvsweb.openbsd.org/ports/net/rrdtool/pkg/README-main?rev=HEAD">/usr/local/share/doc/pkg-readmes/rrdtool-1.4.8</a>
for more details.
<p>
<li><b>postgresql:</b>
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*).
<b>The old database must be dumped *before* upgrading OpenBSD.</b>
Also note that because all old packages are removed, the normal warning
from pkg_add at update time is not triggered.
<p><li><b>php:</b>
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:
<blockquote><pre>
diff /usr/local/share/examples/php-5.3/php.ini-production /etc/php-5.4.ini
</pre></blockquote>
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.
<blockquote><pre> cd /etc/php-5.4
ls -l ../php-5.4.sample
ln -s ../php-5.4.sample/pdo_mysql.ini .
# (etc)
</pre></blockquote>
If you are currently using PHP with Apache in base, you will also need to
adjust your Apache configuration:
<blockquote><pre>
cd /var/www/conf/modules
ln -fs /var/www/conf/modules.sample/php-5.4.conf /var/www/conf/modules/php.conf
</pre></blockquote>
<p>
<li><b>dspam:</b>
If you were using one of the mysql or pgsql FLAVORS of the <b>dspam</b> 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:
<pre>
pkg_add dspam-pgsql
</pre>
If you were using dspam with the MySQL driver:
<pre>
pkg_add dspam-mysql
</pre>
<p>
<li><b>wordpress 3.6.1:</b>
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:
<pre>
cd /var/www/wordpress/wp-content/themes &&
cp -Rp twentyeleven twentyeleven.bak
</pre>
and restore it after wordpress update:
<pre>
cd /var/www/wordpress/wp-content/themes &&
mv twentyeleven.bak twentyeleven
</pre>
<p>
<li><b>Apache Subversion 1.8.3:</b>
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 <code>svn upgrade</code>
because Subversion 1.8 cannot operate with older working copy formats.
See the <a href="https://subversion.apache.org/docs/release-notes/1.8.html#wc-upgrade"
>section about working copy upgrades</a> 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 <a href="https://subversion.apache.org/docs/release-notes/1.8.html#fsfs-enhancements"
>section about FSFS enhancements</a> for details.
<p>
<li><b>lout-doc:</b>
lout-doc was merged into the lout package, so need not be manually re-added.
<p>
<li><b>ngircd:</b>
ngircd's configuration directory has changed.
If updating from a previous version, you will need to move your old
configuration file into place:
<pre>
mv /etc/ngircd.conf /etc/ngircd/ngircd.conf
</pre>
Additional steps may be needed if you have configured it to use a motd file,
ssl or chroot.
<p>
<li><b>icinga 1.10:</b>
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).
<p>
<li><b>openldap and other packages with persistent Berkeley DB databases:</b>
There are three levels of file formatting/encoding involved in
Berkeley DB (BDB) databases:
<ol>
<li>the Berkeley DB shared memory files <code>__db.*</code>
<li>the Berkeley DB database file formats (<code>*.db</code> and <code>log.*</code>)
<li>the data stored in the database keys and values
</ol>
The first are dependent on the sizes of layout of the systems types.
They are rebuilt whenever database recovery is performed on BDB
databases, which is automatic on each restart for many packages.
If problems arise, they can be deleted whenever the database is not
open by a running process.
<p>
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.)
<p>
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
<code>time_t</code> type, but other applications may require application-level
dump and restore when transitioning from 5.4 to 5.5.
</ul>
<p>
<!-- The package tools support in-place updating using <code>pkg_add -u</code>.
For instance, to update all your packages, make sure <code>PKG_PATH</code> is
pointing to the 5.5 packages directory on your CD or nearest FTP mirror,
and use something like
<blockquote><pre>
<b>pkg_add -u</b>
</pre></blockquote>
where the <code>-u</code> indicates update mode;
pkg_add will prompt you for input when it encounters
some ambiguity.
-->
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:
<blockquote><pre>
pkg_add -z -l /root/pkg_list_manual
pkg_add -za -l /root/pkg_list_full
</pre></blockquote>
Read the
<a href="https://man.openbsd.org/OpenBSD-5.4/pkg_add">pkg_add(1)</a>
manual page and the <a href="faq15.html">package management</a>
chapter of the FAQ for more information.
<p>
<a href="index.html">[FAQ Index]</a> |
<a href="upgrade54.html">[5.3 -> 5.4]</a> |
<a href="upgrade56.html">[5.5 -> 5.6]</a>
<hr>
<small>$OpenBSD: upgrade55.html,v 1.51 2021/03/15 10:18:43 jsg Exp $</small>
![[BACK]](/icons/back.gif){kind=icon}
Return to upgrade55.html CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [local] / www / faq