Upgrade Guide: 6.2 to 6.3
[FAQ Index] | [6.1 -> 6.2] [6.3 -> 6.4]
Upgrades are only supported from one release to the release immediately following it. Read through and understand this process before attempting it. For critical or physically remote machines, test it on an identical, local system first.Start by performing the pre-upgrade steps. Next, boot from the install kernel, bsd.rd: use bootable install media, or place the 6.3 version of
bsd.rd in the root of your filesystem and instruct the boot
loader to boot this kernel.
Once this kernel is booted, choose the (U)pgrade option and follow the
prompts.
Apply the configuration changes and
finish up by upgrading the packages: pkg_add -u.
Alternatively, you can use the manual upgrade process.
You may wish to check the errata page or upgrade to the stable branch to get any post-release fixes.
Before rebooting into the install kernel
- Get and verify
bsd.rd. Download the ramdisk kernel and the cryptographically signed checksum file for your architecture.bsd.rd[alpha] [amd64] [arm64] [armv7] [i386] [landisk] [loongson] [luna88k] [macppc] [octeon] [sparc64]SHA256.sig[alpha] [amd64] [arm64] [armv7] [i386] [landisk] [loongson] [luna88k] [macppc] [octeon] [sparc64]
Verify them using signify(1):
$ signify -C -p /etc/signify/openbsd-63-base.pub -x SHA256.sig bsd.rd Signature Verified bsd.rd: OK
- Spring cleaning in
/usr/share. Remove all outdated manuals. Moreover, the relinking of libraries and kernels at boot time now happens in/usr/share/relink. The old relinking directory is no longer used and can be removed.# rm -r /usr/share/man # rm -r /usr/share/compile
- RFC 7217 style IPv6 addresses enabled by default.
Stateless address autoconfiguration and link local IPv6 addresses
historically embedded the layer 2 (ethernet mac) address in the lower
64 bits of the IPv6 address.
This has various downsides and RFC 7217 specifies an alternative scheme
of how to generate autoconfiguration addresses that are stable between
reboots.
This is enabled per default and IPv6 link local addresses will change
if IPv6 is enabled on an interface.
Furthermore, stateless autoconfiguration IPv6 addresses will change if
autoconfiguration is enabled on an interface.
If you need the old style stateless address calculated from the layer 2 address (i.e. ethernet mac address) put
-soiiinto the/etc/hostname.iffile. See also ifconfig(8).
Configuration and syntax changes
ifconfig <if> deletetunneloption deprecated. The ifconfig(8)deletetunneloption was replaced with-tunnel. Adjust your hostname.if(5) configuration and scripts accordingly.- iked(8) and isakmpd(8): ECP group incompatibility.
In the final RFC 5903, the computation for the DH shared secret changed.
The iked(8) and
isakmpd(8)
programs were modified to follow the RFC.
These changes are not backwards compatible, so if you are using ECP groups,
please make sure to upgrade all peers at the same time.
- New default setup for touchpads.
X selects ws(4)
as default driver for touchpads now.
In the setup with ws, touchpad-specific input processing is done by
wsmouse(4).
Touchpad configuration parameters are made available in
wsconsctl(8).
Using the
synaptics(4)
input driver is still possible with a custom
xorg.conffile. - vmd(8): switch configuration.
vmd(8) no longer
automatically creates an underlying bridge interface for virtual switches
defined in
vm.conf(5).
This will require users to create their bridges ahead of time, e.g.
using
/etc/hostname.bridge0. This also requires users to modify their vm.conf(5) files to add an interface line to the switch definition, for example:switch "uplink" { interface bridge0 }
Files to remove
-
Remove libpthread-stubs.
With the integration of the pthread stub functions in libc,
libpthread-stubsis no longer needed in xenocara. After upgrading base and packages, users may want to remove the old installed library, either via the sysclean package or by running the following commands:# cd /usr/X11R6/lib # rm libpthread-stubs.a \ libpthread-stubs.so.2.0 \ pkgconfig/pthread-stubs.pc
Special packages
- Buildbot major update.
There was a major update to Buildbot 0.9.
While the buildslave (renamed to buildworker) workdir is compatible between 0.8
and 0.9, this is not the case for the buildmaster.
On top of this, a 0.9 buildworker
won't work
with a 0.8 buildmaster.
Refer to the upgrade guide for information on how to migrate your configuration. If you want to keep running a 0.8 buildmaster to keep access to your old build logs/history, it's advised to install the 0.8 branch from
pipand run it outside of packages. - memcached defaults to localhost only.
memcached's documentation says, "you must not expose memcached directly
to the internet, or otherwise any untrusted users".
In order to provide sane defaults, the normal command line in memcached's
rc script has been changed to listen on localhost only.
See the pkg-readme file for information about changing this to listen to
external network traffic if this is required.
- neomutt binary renamed.
In neomutt releases since 20171013, binaries and other files have been renamed
so that they can coexist with mutt.
Users may wish to add a shell alias or a symlink for
mutt -> neomutt. - newsbeuter replaced with newsboat.
Upgrading newsbeuter using
pkg_addwill result in newsboat being installed. Upon runningnewsboatfor the first time it will prompt if it should import an existing newsbeuter configuration. - PostgreSQL major update.
There was a major update to PostgreSQL 10.1.
Use
pg_upgradeas described in the postgresql-server pkg-readme or do a dump/restore.
Upgrade without the install kernel
This is NOT the recommended process. Use the install kernel method if at all possible!Sometimes, you need to do an upgrade of a machine for which the normal upgrade process is not possible. The most common case is a machine in a remote location and there is no easy access to the system console.
Preparation
- 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.
Consider disabling the
softdepmount option in/etc/fstaband rebooting before undertaking a manual upgrade. Having at least 500MB free on/usrwould be recommended. - Become root.
While using
doas(1)
before each command is generally a good practice, the command will likely
be broken by the last steps, so you should become root before starting
this process.
It might be good to verify your access to root using a method other than
doas at this point, i.e., direct login or using
su(1).
- Stop and/or disable 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.
You may also have issues with DNS resolution during the first reboot, so
PF rules and NFS mounts dependent upon DNS may cause boot-up problems.
There may be other applications which you wish to keep from running
immediately after the upgrade, stop and disable them as well.
- Install new boot blocks.
This should actually be done at the end of any upgrade.
If this has been neglected, then failure to do this now may break serial
console or other things, depending on your platform.
Use
installboot(8), assuming
sd0is your boot disk:installboot sd0
Upgrading manually
- Install new kernels.
The extra steps for copying over the primary kernel are done
to ensure that there is always a valid kernel on the disk.
If using the multiprocessor kernel:
If using the single processor kernel:cd /usr/rel # where you put the release files ln -f /bsd /obsd && cp bsd.mp /nbsd && mv /nbsd /bsd cp bsd.rd / cp bsd /bsd.spcd /usr/rel # where you put the release files ln -f /bsd /obsd && cp bsd /nbsd && mv /nbsd /bsd cp bsd.rd bsd.mp / # may give a harmless warning - Enable KARL.
Store the kernel's checksum:
sha256 -h /var/db/kernel.SHA256 /bsd - Install new userland.
Save a copy of reboot(8), extract and install the release tarballs, reboot.
Install
base63.tgzlast, because the new base system, in particular tar(1), gzip(1) and reboot(8), will not work with the old kernel. Either untar the needed filesets manually
or, if you use ksh(1), you can docp /sbin/reboot /sbin/oreboot tar -C / -xzphf xshare63.tgz tar -C / -xzphf xserv63.tgz tar -C / -xzphf xfont63.tgz tar -C / -xzphf xbase63.tgz tar -C / -xzphf man63.tgz tar -C / -xzphf game63.tgz tar -C / -xzphf comp63.tgz tar -C / -xzphf base63.tgz # Install last! /sbin/oreboot
Note that tar(1) can expand only one archive per invocation, so a simple glob won't work.cp /sbin/reboot /sbin/oreboot for _f in [!b]*63.tgz base63.tgz; do tar -C / -xzphf "$_f" || break; done /sbin/oreboot - After reboot, update
/dev. Run MAKEDEV(8):cd /dev ./MAKEDEV all - Update boot loader.
Still assuming
sd0is your boot disk:installboot sd0 - Update system configuration files.
Run sysmerge(8):
sysmerge - Update firmware.
There may be new firmware for your system.
Update it with
fw_update(1):
fw_update - Finish up.
Review the console output from boot (using
dmesg -s) and correct any failures as necessary. All the steps following configuration changes above also apply to manual upgrades. Finally, remove/sbin/orebootand update packages:pkg_add -u. Reboot once more to make sure you run on your own kernel generated by KARL.
[FAQ Index] | [6.1 -> 6.2] [6.3 -> 6.4]
$OpenBSD: upgrade63.html,v 1.17 2026/03/10 10:23:28 sthen Exp $