Upgrade Guide: 7.1 to 7.2

[FAQ Index] | [7.0 -> 7.1] [7.2 -> 7.3]

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-72-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. Note that using softdeps can exacerbate the situation as deleted and overwritten files do not release their space immediately. Consider disabling the softdep mount option in /etc/fstab and rebooting before undertaking a manual upgrade. 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 base72.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 xshare72.tgz
# tar -C / -xzphf xserv72.tgz
# tar -C / -xzphf xfont72.tgz
# tar -C / -xzphf xbase72.tgz
# tar -C / -xzphf man72.tgz
# tar -C / -xzphf game72.tgz
# tar -C / -xzphf comp72.tgz
# tar -C / -xzphf base72.tgz    # Install last!
# /sbin/oreboot

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

# cp /sbin/reboot /sbin/oreboot
# for _f in [!b]*72.tgz base72.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

pluart(4). Hardware using pluart(4), such as the Raspberry Pi, has the wrong baud rate in /etc/ttys making the serial console unusable.
Change the baud rate from 38400 to 115200 for the console entry in /etc/ttys.
rc.d(8). The use of ${rcexec} in rc.d scripts has been deprecated.
The ${rcexec} variable used to start daemons with rc.d(8) has been replaced with a more complete rc_exec() function.
Handcrafted rc.d(8) scripts must be modified to use this new function:
```
  # sed -i 's/\${rcexec}/rc_exec/' /etc/rc.d/myscript
```
Compatibility will be retained until next release.
snmpd(8) / snmpd.conf(5). snmpd.conf's filter-pf-addresses has been deprecated.
If you have filter-pf-addresses yes in your config, it should be changed to blocklist pfTblAddrTable.
switchd(8). switchd(8) and switch(4) have been removed.

Files to remove

switch(4) and switchd(8) have been removed from the base system.

To cleanup the user, group, and associated files execute the following commands:

    # userdel _switchd
    # groupdel _switchd
    # rm /etc/rc.d/switchd \
         /usr/sbin/switchctl \
         /usr/sbin/switchd \
         /usr/share/man/man4/switch.4 \
         /usr/share/man/man5/switchd.conf.5 \
         /usr/share/man/man8/switchctl.8 \
         /usr/share/man/man8/switchd.8

Special packages

databases/openldap. The OpenLDAP packages have been updated to the 2.6 branch which has changes that will affect many users of the server ("slapd").
Backup before updating, and be prepared for a more complicated upgrade than usual. Some pointers are given here, but you should also consult the upstream documentation regarding upgrades.
OpenLDAP no longer supports the BDB/HDB legacy database formats based on Berkeley DB. If you are using BDB/HDB, you will need to prepare in advance so that you can move to MDB.
Before updating, stop slapd and use slapcat to dump your database(s) to ldif files. (Saving ldif files is recommended as part of your regular maintenance anyway, but particularly important at this time).
Adjust the backend database in your configuration to use mdb instead of bdb/hdb. If you are using the old-style /etc/openldap/slapd.conf config file, this is relatively straightforward. If you are using upstream's recommended online configuration ("cn=config"), this is normally edited "in-band" via LDAP, but you might find it difficult to make this type of change in the usual way. Instead, you can export to ldif with slapcat -n 0, edit the exported file, then reload with slapadd -n 0. Do not edit the ldif files in /etc/openldap/slapd.d directly.
Regarding the actual changes you need to make: for the simplest case you just need to change "bdb" to "mdb". slapd-bdb(5) has various tuning options which are not used by slapd-mdb(5) (for example, cachesize) - these will need to be removed. For more information, consult the upstream documentation.
After restarting with the updated configuration, you will need to reload your database from the ldif file using slapadd (or if you are updating a read-only replica you could let syncrepl pick it up).
The openldap-server package has changed to a modular build.
The most important backend and overlay (mdb and syncprov) are still compiled-in as before, but if you use the less common ones (including backends like back_perl) you will need to adjust your configuration to load them. If you use online configuration, see "olcModuleLoad". If you use slapd.conf, see "moduleload".
editors/vim. Vim includes new colour schemes that aim to be more consistent in different environments (e.g. between text and gui versions), but in some cases result in a significant change, especially for the text version.
If you find the changes unwelcome, the OpenBSD package includes a copy of the old colour schemes under the legacy subdirectory to make it easier to revert if desired. You can use the subdirectory directly in colorscheme in your configuration, but as these are not included as standard in upstream Vim, if you share config files between various machines you may wish to copy the relevant files from /usr/local/share/vim/vim82/colors/legacy to ~/.vim/colors which take priority.
inputmethods/fcitx. Fcitx splits some input methods into different packages and requires manual reconfiguration after upgrade.
PinYin is no longer bundled. You will need to install fcitx-chinese-addons to use it.
Methods previously provided by the fcitx-table package have been split into two packages:
- For CangJie / ShuangPin / WuBi / ErBi / ZiRanMa, install fcitx-chinese-addons.
- For ZhengMa / Boshiamy / Quick and other WuBi / CangJie tables, install fcitx-table-extra.
If you are starting fcitx from .xsession, update it with the following:
```
  export XMODIFIERS=@im=fcitx
  export GTK_IM_MODULE=fcitx
  export QT_IM_MODULE=fcitx
  /usr/local/bin/fcitx5 &
```
You might need to re-run fcitx5-configtool to reconfigure your input method.
To setup an input engine, run fcitx5-configtool after starting fcitx5, then select and add your preferred input method from the Available Input Method panel. You might need to uncheck 'Only Show Current Language' to find your preferred input method.
After restarting with the updated configuration, fcitx should be usable. Refer to /usr/local/share/doc/pkg-readmes/fcitx if something doesn't work or you need to troubleshoot.
lang/python. Python 3.8 has been removed.

net/isc-bind. For the 9.18.x releases, ISC BIND has completely removed a number of obsolete configuration options. The presence of any of these options will cause startup to fail.

  acache-cleaning-interval
  acache-enable
  additional-from-auth
  additional-from-cache
  allow-v6-synthesis
  cleaning-interval
  dnssec-enable
  dnssec-lookaside
  filter-aaaa
  filter-aaaa-on-v4
  filter-aaaa-on-v6
  geoip-use-ecs
  lwres
  max-acache-size
  nosit-udp-size
  queryport-pool-ports
  queryport-pool-updateinterval
  request-sit
  sit-secret
  support-ixfr
  use-queryport-pool
  use-ixfr

www/sogo. With the update of SOGo to 5.7.1, sogod may fail to start if you don't have WOPort explicitly configured. To set the WOPort explicitly to the prior default, execute the following command as the _sogod user.
```
  defaults write sogod WOPort 127.0.0.1:20000
```

[FAQ Index] | [7.0 -> 7.1] [7.2 -> 7.3]

$OpenBSD: upgrade72.html,v 1.7 2024/05/02 19:32:53 sthen Exp $