[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:
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.
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.
/etc/rc.conf.local
and remove them from /etc/inetd.conf.
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 auth
The "ssl" keyword in relay URLs becomes "secure".
table secrets file:/etc/mail/secrets accept for any relay via secure+auth://[email protected] 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.
/boot file:
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 /boot 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 "ERR M" at boot.
pkg_info -mq >/root/pkg_list_manual pkg_info -q >/root/pkg_list_full
pkg_delete -X /var/db/pkg/*-firmware-[0-9]*
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.
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:
/etc/master.password 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 /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
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
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 /
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.
etc55.tgz and xetc55.tgz now, 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 /etc are handled separately below, so
etc55.tgz and xetc55.tgz are NOT unpacked here.
/dev.
The new
MAKEDEV
file was copied to /dev by the installation of
base55.tgz, so you simply need to do the following:
cd /dev ./MAKEDEV all
assuming "sd0" is your boot disk.installboot -v sd0
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
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.
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
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.
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.
# Single file:
rrdtool dump filename.rrd filename.xml
# To convert a batch:
for i in *.rrd; do rrdtool dump $i ${i%.rrd}.xml; done
# Single file:
rrdtool restore filename.xml filename.rrd
# To convert a batch:
for i in *.xml; do rrdtool restore $i ${i%.xml}.rrd; done
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 /usr/local/share/doc/pkg-readmes/rrdtool-1.4.8 for more details.
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
pkg_add dspam-pgsqlIf you were using dspam with the MySQL driver:
pkg_add dspam-mysql
cd /var/www/wordpress/wp-content/themes && cp -Rp twentyeleven twentyeleven.bakand restore it after wordpress update:
cd /var/www/wordpress/wp-content/themes && mv twentyeleven.bak twentyeleven
svn upgrade
because 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.
mv /etc/ngircd.conf /etc/ngircd/ngircd.confAdditional steps may be needed if you have configured it to use a motd file, ssl or chroot.
__db.*
*.db and log.*)
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_t type, but other applications may require application-level
dump and restore when transitioning from 5.4 to 5.5.
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]