File: [local] / www / faq / upgrade74.html (download) (as text)
Revision 1.6, Thu May 2 19:32:53 2024 UTC (5 weeks ago) by sthen
Branch: MAIN
CVS Tags: HEAD
Changes since 1.5: +2 -2 lines
fix section number for fw_update manual, it moved from 1 to 8 in 7.1
|
<!doctype html>
<html lang=en id=faq>
<title>OpenBSD Upgrade Guide: 7.3 to 7.4</title>
<meta charset=utf-8>
<meta name="description" content="OpenBSD Upgrade Process for 7.3 -> 7.4">
<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/upgrade74.html">
<style>
dt { margin-left: 20px; float: left; }
dd { margin: 0 0 0 8em; }
</style>
<h2 id=OpenBSD>
<a href="../index.html">
<i>Open</i><b>BSD</b></a>
Upgrade Guide: 7.3 to 7.4
</h2>
<hr>
<p>
<a href="index.html">[FAQ Index]</a> |
<a href="upgrade73.html">[7.2 -> 7.3]</a>
<a href="upgrade75.html">[7.4 -> 7.5]</a>
<p>
<blockquote>
<p><i>
Upgrades are only supported from one release to the release immediately
following.</i>
<p>
<strong><i>Read through and understand this process before attempting it.
For critical or physically remote machines, test it on an identical,
local system first.
</i></strong></blockquote>
<h3 id="BeforeUpdate">Before using any upgrade method</h3>
<ul>
<li><b>Check available disk space in /usr.</b>
Verify that the <code>/usr</code> partition has a size of at least 1.1G.
With less space the upgrade may fail and you should consider reinstalling
the system instead.
<p>
<li><b>Read configuration and syntax changes and the
package upgrade instructions.</b>
There were several <a href="#ConfigChanges">configuration changes</a>
and <a href="#SpecialPackages">changes in packages</a> that may
require planning before starting the upgrade.
</ul>
<h3 id="UpgradeMethods">Upgrade Methods</h3>
<ul>
<li><b>Unattended Upgrade:</b>
The easiest method is an unattended upgrade using
<a href="https://man.openbsd.org/OpenBSD-7.4/sysupgrade.8">sysupgrade(8)</a>.
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 <a href="upgrade74.html#AfterSets">below</a>.
<p>
<li><b>Interactive Upgrade:</b>
If you insist on leaving out some of the install sets, you will want to
perform an <a href="#InteractiveUpgrade">interactive upgrade</a>. (sysupgrade
upgrades with all install sets.)
<p>
<li><b>Manual Upgrade:</b>
The final option is using the <a href="#NoInstKern">manual upgrade process</a>.
(This is not recommended as it is the most error-prone method.)
</ul>
<hr>
<h3 id="InteractiveUpgrade">Interactive Upgrade</h3>
<ul>
<li><b>Get and verify <code>bsd.rd</code>.</b>
Download the ramdisk kernel and the cryptographically-signed checksum file
for your architecture.
<p>
<dl>
<dt><code>bsd.rd</code></dt>
<dd>
[<a href="https://cdn.openbsd.org/pub/OpenBSD/7.4/alpha/bsd.rd">alpha</a>]
[<a href="https://cdn.openbsd.org/pub/OpenBSD/7.4/amd64/bsd.rd">amd64</a>]
[<a href="https://cdn.openbsd.org/pub/OpenBSD/7.4/arm64/bsd.rd">arm64</a>]
[<a href="https://cdn.openbsd.org/pub/OpenBSD/7.4/armv7/bsd.rd">armv7</a>]
[<a href="https://cdn.openbsd.org/pub/OpenBSD/7.4/hppa/bsd.rd">hppa</a>]
[<a href="https://cdn.openbsd.org/pub/OpenBSD/7.4/i386/bsd.rd">i386</a>]
[<a href="https://cdn.openbsd.org/pub/OpenBSD/7.4/landisk/bsd.rd">landisk</a>]
[<a href="https://cdn.openbsd.org/pub/OpenBSD/7.4/luna88k/bsd.rd">luna88k</a>]
[<a href="https://cdn.openbsd.org/pub/OpenBSD/7.4/macppc/bsd.rd">macppc</a>]
[<a href="https://cdn.openbsd.org/pub/OpenBSD/7.4/octeon/bsd.rd">octeon</a>]
[<a href="https://cdn.openbsd.org/pub/OpenBSD/7.4/powerpc64/bsd.rd">powerpc64</a>]
[<a href="https://cdn.openbsd.org/pub/OpenBSD/7.4/riscv64/bsd.rd">riscv64</a>]
[<a href="https://cdn.openbsd.org/pub/OpenBSD/7.4/sparc64/bsd.rd">sparc64</a>]
</dd>
<dt><code>SHA256.sig</code></dt>
<dd>
[<a href="https://cdn.openbsd.org/pub/OpenBSD/7.4/alpha/SHA256.sig">alpha</a>]
[<a href="https://cdn.openbsd.org/pub/OpenBSD/7.4/amd64/SHA256.sig">amd64</a>]
[<a href="https://cdn.openbsd.org/pub/OpenBSD/7.4/arm64/SHA256.sig">arm64</a>]
[<a href="https://cdn.openbsd.org/pub/OpenBSD/7.4/armv7/SHA256.sig">armv7</a>]
[<a href="https://cdn.openbsd.org/pub/OpenBSD/7.4/hppa/SHA256.sig">hppa</a>]
[<a href="https://cdn.openbsd.org/pub/OpenBSD/7.4/i386/SHA256.sig">i386</a>]
[<a href="https://cdn.openbsd.org/pub/OpenBSD/7.4/landisk/SHA256.sig">landisk</a>]
[<a href="https://cdn.openbsd.org/pub/OpenBSD/7.4/luna88k/SHA256.sig">luna88k</a>]
[<a href="https://cdn.openbsd.org/pub/OpenBSD/7.4/macppc/SHA256.sig">macppc</a>]
[<a href="https://cdn.openbsd.org/pub/OpenBSD/7.4/octeon/SHA256.sig">octeon</a>]
[<a href="https://cdn.openbsd.org/pub/OpenBSD/7.4/powerpc64/SHA256.sig">powerpc64</a>]
[<a href="https://cdn.openbsd.org/pub/OpenBSD/7.4/riscv64/SHA256.sig">riscv64</a>]
[<a href="https://cdn.openbsd.org/pub/OpenBSD/7.4/sparc64/SHA256.sig">sparc64</a>]
</dd>
</dl>
<p>
Verify <code>bsd.rd</code> and <code>SHA256.sig</code> using
<a href="https://man.openbsd.org/OpenBSD-7.4/signify">signify(1)</a>:
<pre class="cmdbox">
$ <b>signify -C -p /etc/signify/openbsd-74-base.pub -x SHA256.sig bsd.rd</b>
Signature Verified
bsd.rd: OK<!--
--></pre>
<p>
<li> Next, boot from the install kernel, <code>bsd.rd</code>, 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 <code>(U)pgrade</code> option and follow the prompts.
<p>
<li>After the filesets have been installed, the system will reboot with
the upgraded kernel. Now continue <a
href="upgrade74.html#AfterSets">with the next step</a>:
</ul>
<hr>
<h3 id="AfterSets">After the Upgrade</h3>
<p>
After upgrading the sets, the system will reboot with the upgraded
kernel and run <a
href="https://man.openbsd.org/OpenBSD-7.4/sysmerge">sysmerge(8)</a>
during boot. In some cases, configuration files cannot be modified
automatically. Run
<pre class="cmdbox"> # <b>sysmerge</b><!-- --></pre>
to check and perform these <a href="#ConfigChanges">configuration
changes</a>.
<p>Next <a href="#RmFiles">remove the old files</a>.
Finish up by upgrading the packages using <code><b>pkg_add -u</b></code>.
<p>
You may wish to check the <a href="../errata74.html">errata page</a> for
any post-release fixes.
<p>
<hr>
<h2 id="NoInstKern">Manual Upgrade (without the install kernel)</h2>
<b style="color:#e00000">This is NOT the recommended process.
Use the unattended or interactive upgrade methods if at all possible!</b>
<p>
Sometimes, you need to perform an upgrade of a machine for which the normal
unattended or interactive upgrade process is not possible.
<h3>Preparation</h3>
<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 exacerbate the situation as deleted and
overwritten files do not release their space immediately.
Consider disabling the <code>softdep</code> mount option in
<code>/etc/fstab</code> and rebooting before undertaking a manual upgrade.
Having at least 500MB free on <code>/usr</code> would be recommended.
<p>
<li><b>Become root.</b>
While using
<a href="https://man.openbsd.org/OpenBSD-7.4/doas">doas(1)</a>
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
<a href="https://man.openbsd.org/OpenBSD-7.4/su">su(1)</a>.
<p>
<li><b>Stop and/or disable 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.
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.
<p>
<li><b>Install new boot blocks.</b>
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 <a href="https://man.openbsd.org/OpenBSD-7.4/amd64/installboot">
installboot(8)</a>, assuming <code>sd0</code> is your boot disk:
<pre class="cmdbox">
# <b>installboot sd0</b><!--
--></pre>
</ul>
<h3>Upgrading manually</h3>
<ul>
<li><b>Install new kernels.</b>
The extra steps for copying over the primary kernel are done
to ensure that there is always a valid kernel on the disk.
<p>
If using the multiprocessor kernel:
<pre class="cmdbox">
# <b>cd /usr/rel</b> # where you put the release files
# <b>ln -f /bsd /obsd && cp bsd.mp /nbsd && mv /nbsd /bsd</b>
# <b>cp bsd.rd /</b>
# <b>cp bsd /bsd.sp</b><!--
--></pre>
If using the single processor kernel:
<pre class="cmdbox">
# <b>cd /usr/rel</b> # where you put the release files
# <b>ln -f /bsd /obsd && cp bsd /nbsd && mv /nbsd /bsd</b>
# <b>cp bsd.rd bsd.mp /</b> # may give a harmless warning<!--
--></pre>
<p>
<li><b>Enable KARL.</b>
Store the kernel's checksum:
<pre class="cmdbox">
# <b>sha256 -h /var/db/kernel.SHA256 /bsd</b> <!--
--></pre>
<p>
<li><b>Install new userland.</b>
Save a copy of reboot(8), extract and install the release tarballs, reboot.
Install <code>base74.tgz</code> last, because the new base system,
in particular <a href="https://man.openbsd.org/OpenBSD-7.4/tar">tar(1)</a>,
<a href="https://man.openbsd.org/OpenBSD-7.4/gzip">gzip(1)</a> and
<a href="https://man.openbsd.org/OpenBSD-7.4/reboot">reboot(8)</a>,
will not work with the old kernel.
Either untar the needed filesets manually:
<pre class="cmdbox">
# <b>cp /sbin/reboot /sbin/oreboot</b>
# <b>tar -C / -xzphf xshare74.tgz</b>
# <b>tar -C / -xzphf xserv74.tgz</b>
# <b>tar -C / -xzphf xfont74.tgz</b>
# <b>tar -C / -xzphf xbase74.tgz</b>
# <b>tar -C / -xzphf man74.tgz</b>
# <b>tar -C / -xzphf game74.tgz</b>
# <b>tar -C / -xzphf comp74.tgz</b>
# <b>tar -C / -xzphf base74.tgz</b> # Install last!
# <b>/sbin/oreboot</b><!--
--></pre>
or, if you use
<a href="https://man.openbsd.org/OpenBSD-7.4/ksh">ksh(1)</a>, you can do:
<pre class="cmdbox">
# <b>cp /sbin/reboot /sbin/oreboot</b>
# <b>for _f in [!b]*74.tgz base74.tgz; do tar -C / -xzphf "$_f" || break; done</b>
# <b>/sbin/oreboot</b><!--
--></pre>
Note that <a href="https://man.openbsd.org/OpenBSD-7.4/tar">tar(1)</a>
can expand only one archive per invocation, so a simple glob won't work.
<p>
<li><b>After reboot, update <code>/dev</code>.</b>
Run
<a href="https://man.openbsd.org/OpenBSD-7.4/amd64/MAKEDEV">MAKEDEV(8)</a>:
<pre class="cmdbox">
# <b>cd /dev</b>
# <b>./MAKEDEV all</b><!--
--></pre>
<p>
<li><b>Update the boot loader.</b>
Still assuming <code>sd0</code> is your boot disk:
<pre class="cmdbox">
# <b>installboot sd0</b><!--
--></pre>
<p>
<li><b>Update system configuration files.</b>
Run <a href="https://man.openbsd.org/OpenBSD-7.4/sysmerge">sysmerge(8)</a>:
<pre class="cmdbox">
# <b>sysmerge</b><!--
--></pre>
<p>
<li><b>Update firmware.</b>
There may be new firmware for your system.
Update it with
<a href="https://man.openbsd.org/OpenBSD-7.4/fw_update">fw_update(8)</a>:
<pre class="cmdbox">
# <b>fw_update</b><!--
--></pre>
<p>
<li><b>Finish up.</b>
Review the console output from boot (using <code><b>dmesg -s</b></code>)
and correct any failures as necessary.
All the steps following <a href="#ConfigChanges">configuration changes</a>
below also apply to manual upgrades.
Finally, remove <code><b>/sbin/oreboot</b></code> and update packages:
<code><b>pkg_add -u</b></code>.
Reboot once more to make sure you use the newest firmware files
and run on your own kernel generated by KARL.
</ul>
<p>
<hr>
<h3 id="ConfigChanges">Configuration and syntax changes</h3>
<ul>
<li><b>bioctl(8).</b>
<a href="https://man.openbsd.org/bioctl.8">bioctl(8)</a> now defaults to a
system performance based number of KDF iterations for passphrases.
<p>
Update the passphrase on existing <code>CRYPTO</code> and <code>RAID 1C</code>
<a href="https://man.openbsd.org/softraid.4">softraid(4)</a> volumes to update
the number of rounds to a new hardware based default:
<pre class="cmdbox">
# bioctl -v -P sd1<!--
--></pre>
<li><b>pfsync(4).</b>
<a href="https://man.openbsd.org/pfsync.4">pfsync(4)</a> has been rewritten.
In most cases, no change is needed and the protocol is compatible with the
older version.
<p>
However, if you configured it with a <code>hostname.pfsyncX</code>
entry like:
<pre class="cmdbox">
up
syncdev $interface<!--
--></pre>
<p>
Then it will need to be rearranged so the interface is configured before
being brought up:
<pre class="cmdbox">
syncdev $interface
up<!--
--></pre>
<li><b>shutdown(8).</b>
<a href="https://man.openbsd.org/shutdown.8">shutdown(8)</a> has changed
from group <code>operator</code> to group <code>_shutdown</code> to
separate the ability to use shutdown from other privileges <code>operator</code>
grants.
<p>
Those users who were given group <code>operator</code> should be moved to
<code>_shutdown</code> in order to continue using
<a href="https://man.openbsd.org/shutdown.8">shutdown(8)</a>.
</ul>
<h3 id="RmFiles">Files to remove</h3>
<ul>
<li>Nothing to remove this release
</ul>
<h3 id="SpecialPackages">Special packages</h3>
<ul>
<li><b>borgbackup 1.1.x.</b> borgbackup 1.1.x. is end-of-life and has
been removed. A package upgrade will install a 1.2.x version.
<p>
Before upgrading it is
recommended to follow the
<a href="https://github.com/borgbackup/borg/blob/1.2.6/docs/changes.rst#upgrade-notes">
borgbackup upgrade notes</a>.
<p>
<li><b>borgbackup 1.2.x.</b>
A flaw in the cryptographic authentication scheme in borgbackup
versions before 1.2.5 allowed an attacker to fake archives and
potentially indirectly cause backup data loss in the repository.
borgbackup versions 1.2.5 and later enforces checking the TAM
authentication tag of archives at critical places, and now considers
archives without TAM as garbage or an attack.
<p>
Steps you must take to upgrade a repository are detailed in the
<a href="https://github.com/borgbackup/borg/blob/1.2.6/docs/changes.rst#pre-125-archives-spoofing-vulnerability-cve-2023-36811">
borgbackup documentation</a>.
<p>
<li><b>exim.</b> Exim's internal SPF support has been disabled
due to an integer underflow vulnerability in the library used for
SPF processing. If using SPF checks directly in Exim you'll need
to disable that part of configuration (you may be able to replace
this with checks in spam filtering software; at least rspamd and
spamassassin can do SPF checks).
<p>
Additionally, exim's AUTH_SPA (NTLM) support has been disabled in the
port, to match upstream's default.
<p>
<li><b>influxdb.</b> Influxdb has been upgraded to a new major
version, which has several impacts:
<p>
The <code>influx</code> command line interface is now in the separate
<code>influx-cli</code> package, and has a completely different syntax.
<p>
Authentication is now mandatory via token, and the db is multi-tenant
so an organization is also mandatory.
<p>
The web interface is now built-in and accessible on port 8086 by
default.
The database format needs to be upgraded with:
<pre class="cmdbox">
# doas -u _influx influxd upgrade<!--
--></pre>
(Also see
<a href="https://docs.influxdata.com/influxdb/v2.7/upgrade/v1-to-v2/automatic-upgrade/">
the upstream documentation</a>)
<p>
<li><b>nextcloud 23.</b> Nextcloud 23 must be updated <i>before</i>
upgrading.
<p>
Nextcloud 23 and 24 have been removed. As Nextcloud upgrades
are only supported from one major version to the next, users of
Nextcloud 23 must update to at least Nextcloud 24 <b>before upgrading
OpenBSD</b> otherwise they will not be able to follow upstream's
supported process. To do this, first backup your configuration and
database, then <code>pkg_delete nextcloud</code> and <code>pkg_add
nextcloud</code> selecting a 24.x release before following the usual
Nextcloud upgrade procedure via the web interface or <code>occ
upgrade</code>.
<p>
<li><b>telegraf.</b> Telegraf clients will need to be updated to use the
<code>outputs.influxdb_v2</code> plugin (with org, token and bucket)
per
<a href="https://github.com/influxdata/telegraf/blob/release-1.27/plugins/outputs/influxdb_v2/README.md#configuration">
the documentation</a>
<p>
There is no more collectd direct sink in influxdb. collectd now needs
to talk to telegraf with a
<a href="https://docs.influxdata.com/telegraf/v1.9/data_formats/input/collectd/">collectd-enabled</a>
sink. An example configuration for <code>telegraf.conf</code> is provided
below:
<pre class="cmdbox">
[[inputs.socket_listener]]
service_address = "udp://:25826"
data_format = "collectd"
collectd_auth_file = "/etc/collectd/collectd.auth"
collectd_security_level = "encrypt"
collectd_typesdb = ["/usr/local/share/collectd_types.db"]
collectd_parse_multivalue = "split"
[[outputs.influxdb_v2]]
urls = ["http://influxdb:8086"]
token = "$DOCKER_INFLUXDB_INIT_ADMIN_TOKEN"
organization = "$DOCKER_INFLUXDB_INIT_ORG"
bucket = "$DOCKER_INFLUXDB_INIT_BUCKET"<!--
--></pre>
<p>
<li><b>tor browser.</b> Tor Browser has been updated to 12.5.3.
<p>
As of the 12.5 release, <code>torrc</code> has been moved from
<code>~/TorBrowser-Data/torrc</code> to <code>~/TorBrowser-Data/Tor/torrc</code>.
If you wish to preserve your tor configuration (e.g., bridges), please
do the following BEFORE starting <code>tor-browser</code> after you
upgrade:
<pre class="cmdbox">
$ mv ~/TorBrowser-Data/torrc ~/TorBrowser-Data/Tor/<!--
--></pre>
</ul>
<a href="index.html">[FAQ Index]</a> |
<a href="upgrade73.html">[7.2 -> 7.3]</a>
<a href="upgrade75.html">[7.4 -> 7.5]</a>
<hr>
<small>$OpenBSD: upgrade74.html,v 1.6 2024/05/02 19:32:53 sthen Exp $</small>
![[BACK]](/icons/back.gif){kind=icon}
Return to upgrade74.html CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [local] / www / faq