Upgrade Guide: 7.8 to 7.9

[FAQ Index] | [7.7 -> 7.8]

Upgrades are only supported from one release to the release immediately following.
Read through and understand this process before attempting it. For critical or physically remote machines, test it on an identical, local system first.

Before using any upgrade method

Check available disk space in /usr. Verify that the /usr partition has a size of at least 1.1G. With less space the upgrade may fail and you should consider reinstalling the system instead.
Read configuration and syntax changes and the package upgrade instructions. There were several configuration changes and changes in packages that may require planning before starting the upgrade.

Upgrade Methods

Unattended Upgrade: The easiest method is an unattended upgrade using sysupgrade(8). The program will download all the install sets, verify their signatures, and reboot to perform the upgrade automatically. Once the unattended upgrade has completed, continue below.
Interactive Upgrade: If you insist on leaving out some of the install sets, you will want to perform an interactive upgrade. (sysupgrade upgrades with all install sets.)
Manual Upgrade: The final option is using the manual upgrade process. (This is not recommended as it is the most error-prone method.)

Interactive Upgrade

Get and verify bsd.rd. Download the ramdisk kernel and the cryptographically-signed checksum file for your architecture.

bsd.rd

[alpha] [amd64] [arm64] [armv7] [hppa] [i386] [landisk] [luna88k] [macppc] [octeon] [powerpc64] [riscv64] [sparc64]

SHA256.sig

[alpha] [amd64] [arm64] [armv7] [hppa] [i386] [landisk] [luna88k] [macppc] [octeon] [powerpc64] [riscv64] [sparc64]

Verify bsd.rd and SHA256.sig using signify(1):
```
$ signify -C -p /etc/signify/openbsd-79-base.pub -x SHA256.sig bsd.rd
Signature Verified
bsd.rd: OK
```
Next, boot from the install kernel, bsd.rd, retrieved in the previous step. Place it 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.
After the filesets have been installed, the system will reboot with the upgraded kernel. Now continue with the next step:

After the Upgrade

After upgrading the sets, the system will reboot with the upgraded kernel and run sysmerge(8) during boot. In some cases, configuration files cannot be modified automatically. Run

 # sysmerge

to check and perform these configuration changes.

Next remove the old files. Finish up by upgrading the packages using pkg_add -u.

You may wish to check the errata page for any post-release fixes.

Manual Upgrade (without the install kernel)

This is NOT the recommended process. Use the unattended or interactive upgrade methods if at all possible!

Sometimes, you need to perform an upgrade of a machine for which the normal unattended or interactive upgrade process is not possible.

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. Having at least 500MB free on /usr would 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 sd0 is 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:

# 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.sp

If using the single processor kernel:

# cd /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 base79.tgz last, 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:

# cp /sbin/reboot /sbin/oreboot
# tar -C / -xzphf xshare79.tgz
# tar -C / -xzphf xserv79.tgz
# tar -C / -xzphf xfont79.tgz
# tar -C / -xzphf xbase79.tgz
# tar -C / -xzphf man79.tgz
# tar -C / -xzphf game79.tgz
# tar -C / -xzphf comp79.tgz
# tar -C / -xzphf base79.tgz    # Install last!
# /sbin/oreboot

or, if you use ksh(1), you can do:

# cp /sbin/reboot /sbin/oreboot
# for _f in [!b]*79.tgz base79.tgz; do tar -C / -xzphf "$_f" || break; done
# /sbin/oreboot

Note that tar(1) can expand only one archive per invocation, so a simple glob won't work.

After reboot, update /dev. Run MAKEDEV(8):
```
# cd /dev
# ./MAKEDEV all
```
Update the boot loader. Still assuming sd0 is 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(8):
```
# 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 below also apply to manual upgrades. Finally, remove /sbin/oreboot and update packages: pkg_add -u. Reboot once more to make sure you use the newest firmware files and run on your own kernel generated by KARL.

Configuration and syntax changes

LACP removed from trunk(4).
IEEE 802.3ad/802.1AX Link Aggregation Control Protocol support has been removed from trunk(4). trunk(4) LACP configuration can be moved to aggr(4), the dedicated IEEE 802.1AX Link Aggregation network interface driver.
aggr(4) is compatible with trunk(4) with two exceptions:
1. aggr(4) uses a random MAC by default, whereas trunk(4) uses the MAC of the first-added child port.
2. aggr(4) needs to be configured up explicitly.
An example of migrating configuration from trunk0 to aggr0:
```
  # cd /etc
  # ifconfig trunk0 | awk '/lladdr/ { print $1, $2 }' > hostname.aggr0
  # cat hostname.trunk0 >> hostname.aggr0
  # echo up >> hostname.aggr0
  # rm hostname.trunk0
```

Files to remove

Nothing of note this release

Special packages

aide caddy icinga lldpd postgresql puppet*

aide. Some options have been changed since the previous v0.16.2; configuration will need updating to match. Search aide.conf(5) for 'REMOVED' for more information. Common ones: database replaced with database_in, verbose <number> replaced with log_level <error/warning/..>, various hashsum types have been removed: crc32, crc32b, haval, tiger, whirlpool.
caddy. The HTTP Host: header passed to an upstream server when Caddy is configured as a proxy has changed. If this causes problems with your configuration, you may need to use header_up Host {hostport} to revert to previous behaviour.
exim. The exim port has been removed from the tree.
icinga. Icinga Web no longer includes the older/default "monitoring" module in the main package. Unless you are already using Icinga DB and icingadb-web instead, you will want install the icinga-web2-module-monitoring package otherwise the monitoring interface will be empty.
lldpd. The rc script for the lldpd package has been renamed to elldpd to free up the rc script name for future use in base. Adjust pkg_scripts in /etc/rc.conf.local if you use it.
postgresql. There was a major update to PostgreSQL 18.1. The new version defaults to using data checksums.
For ease of using pg_upgrade, if you have an existing database using 17.x, it is recommended to enable data checksums before upgrading OpenBSD:
```
  # rcctl stop postgresql
  # su _postgresql -c '/usr/local/bin/pg_checksums -e -D /var/postgresql/data'
  # rcctl start postgresql
```
After upgrading, use pg_upgrade as described in the postgresql-server pkg-readme or do a dump/restore.
puppet. Core Puppet ports have been removed and replaced by their OpenVox equivalents. Additionally, several Puppet and OpenVox-related ports have had the Ruby flavor removed, resulting in changes to package and binary names.
Action Required: Users transitioning to OpenVox should thoroughly verify their Puppet modules and Hiera configurations. Due to the removal of the Ruby flavor and the shift in underlying binaries, testing in a non-production environment prior to upgrading is strongly recommended.

[FAQ Index] | [7.7 -> 7.8]

$OpenBSD: upgrade79.html,v 1.4 2026/06/17 22:21:02 tj Exp $