File: [local] / www / faq / upgrade61.html (download) (as text)
Revision 1.30, Sat Jun 1 23:12:52 2019 UTC (4 years, 11 months ago) by deraadt
Branch: MAIN
CVS Tags: HEAD
Changes since 1.29: +11 -11 lines
nasty whitespaces
|
<!doctype html>
<html lang=en id=faq>
<title>OpenBSD Upgrade Guide: 6.0 to 6.1</title>
<meta charset=utf-8>
<meta name="description" content="OpenBSD Upgrade Process for 6.0 -> 6.1">
<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/upgrade61.html">
<style>
ul { list-style: none; }
</style>
<h2 id=OpenBSD>
<a href="../index.html">
<i>Open</i><b>BSD</b></a>
Upgrade Guide: 6.0 to 6.1
</h2>
<hr>
<p>
<a href="index.html">[FAQ Index]</a> |
<a href="upgrade60.html">[5.9 -> 6.0]</a>
<a href="upgrade62.html">[6.1 -> 6.2]</a>
<p>
<blockquote><i>
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.
</i></blockquote>
Start by performing the <a href="#BeforeUpdate">pre-upgrade steps</a>.
Next, boot from the install kernel, <a href="faq4.html#bsd.rd">bsd.rd</a>:
use <a href="faq4.html#MkInsMedia">bootable install media</a>, or place the 6.1
version of <code>bsd.rd</code> 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.
Apply the <a href="#AfterUpgrade">configuration changes</a> and
<a href="#RmFiles">remove the old files</a>.
Finish up by upgrading the packages: <code><b>pkg_add -u</b></code>.
<p>
Alternatively, you can use the <a href="#NoInstKern">manual upgrade process</a>.
<p>
You may wish to check the <a href="../errata61.html">errata page</a> or upgrade
to the <a href="../stable.html">stable branch</a> to get any post-release fixes.
<hr>
<h3 id="BeforeUpdate">Before rebooting into the install kernel</h3>
<ul>
<li><b>clean out <code>/usr/share/man</code>.</b>
To remove all outdated manuals, issue <code><b>rm -rf /usr/share/man</b></code>.
<p>
<li><b>cwm(1) bind function changes.</b>
The configuration syntax for binding functions to keys and mouse buttons has
changed, replacing the <code>bind</code> and <code>mousebind</code> keywords with
<code>bind-key</code>, <code>bind-mouse</code>, <code>unbind-key</code> and
<code>unbind-mouse</code>.
See the <a href="https://man.openbsd.org/OpenBSD-6.1/cwmrc.5">cwmrc(5)</a> man
page for new bind function names.
<p>
<li><b>installer changes.</b>
On amd64, armv7, i386, hppa and macppc, the bsd.rd installer defaults to
fetching sets over https.
Your
<a href="https://man.openbsd.org/OpenBSD-6.1/autoinstall">autoinstall(8)</a>
response file may need the additional line:
<blockquote><pre>
Unable to connect using https. Use http instead = yes # "no" is default<!--
--></pre></blockquote>
between the <code>HTTP Server</code> and <code>Set name(s)</code> responses.
Moreover, the xdm question was changed to
<blockquote><pre>
Do you want the X Window System to be started by xenodm(1) <!--
--></pre></blockquote>
</ul>
<h3 id="AfterUpgrade">After upgrading</h3>
<ul>
<li><b>build system changes.</b>
If you intend to build the system from source in the future, you need to fix
some permissions:
<blockquote><pre>
# <b>rm -rf /usr/obj/* /usr/xobj/*</b>
# <b>chown build:wobj /usr/{,x}obj</b>
# <b>chmod 770 /usr/{,x}obj</b><!--
--></pre></blockquote>
It is recommended that you add users who need to work with the src trees to
the group <code>wobj</code>, so that they can still write to <code>/usr/obj</code>.
<p>
It is best to <a href="../anoncvs.html#getting">check out</a> a fresh source
tree from an <a href="../anoncvs.html">AnonCVS</a> server.
If you need to <a href="../anoncvs.html#updating">update</a> on top of a
pre-existing source tree, you need to do
<a href="https://cvsweb.openbsd.org/www/faq/current.html?rev=1.808#r20161014a">
some cleanup</a> first.
<li><b>new mandoc.db(5) format.</b>
To update all <a href="https://man.openbsd.org/OpenBSD-6.1/mandoc.db.5">
mandoc.db(5)</a>
files to the new format, run:
<blockquote><pre>
<b>makewhatis</b><!--
--></pre></blockquote>
<p>
<li><b>softraid crypto switched to bcrypt PBKDF.</b>
New volumes will be created with bcrypt PBKDF, however existing volumes
will continue to use PKCS5 PBKDF2 until a passphrase change is made.
<p>
If you're booting from softraid crypto, ensure that your boot loader has been
upgraded to a version that supports bcrypt prior to changing your passphrase.
The <a href="https://man.openbsd.org/OpenBSD-6.1/boot.8">boot(8)</a> version
should be at least 3.33 on amd64 and 3.31 on i386.
Also be aware that once the passphrase has been changed, an older version of
<a href="https://man.openbsd.org/OpenBSD-6.1/bioctl.8">bioctl(8)</a> (one that
does not support bcrypt PBKDF) will not be able to "unlock" the volume.
<p>
<li><b>sqlite3 moved back to ports.</b>
SQLite has moved from base back to ports.
Remove the following files <b>after</b> upgrading the OS and updating the
packages, but <b>before</b> building any ports:
<blockquote><pre>
<b>rm /usr/bin/sqlite3</b>
<b>rm /usr/include/sqlite3*.h</b>
<b>rm /usr/lib/pkgconfig/sqlite3.pc</b>
<b>rm /usr/libdata/perl5/site_perl/*-openbsd/sqlite3*.ph</b>
<b>rm /usr/lib/libsqlite3*</b><!--
--></pre></blockquote>
<p><b><code>uucp</code> and <code>news</code> users removed.</b>
The <code>uucp</code> user and the <code>news</code> group have been removed from base.
If you use the <code>net/uucp</code> port, please follow
<a href="#uucp">these instructions</a> first.
Issue
<blockquote><pre>
<b>userdel uucp</b>
<b>groupdel news</b>
<b>rm -rf /var/spool/uucp*</b> # unless you use the net/uucp port<!--
--></pre></blockquote>
<p>
<li><b>uxterm and koi8xterm removed.</b>
The <code>uxterm</code> and <code>koi8rxterm</code> shell scripts have been removed,
as <a href="https://man.openbsd.org/OpenBSD-6.1/xterm.1">xterm(1)</a> on
OpenBSD is already set up to support UTF-8:
<blockquote><pre>
<b>cd /usr/X11R6</b>
<b>rm bin/koi8rxterm bin/uxterm</b>
<b>rm share/X11/app-defaults/KOI8RXTerm share/X11/app-defaults/UXTerm</b>
<b>rm man/man1/koi8rxterm.1 man/man1/uxterm.1</b><!--
--></pre></blockquote>
If you edited any configuration files to call <code>uxterm</code>,
do not forget to change these to call <code>xterm</code> directly.
If you defined X resources for UXTerm, consider moving them to XTerm.
<p>
<li><b>xdm(1) replaced with xenodm(1).</b>
The X Display Manager has been switched to
<a href="https://man.openbsd.org/OpenBSD-6.1/xenodm.1">xenodm(1)</a>.
If you enabled xdm in <code>/etc/rc.conf.local</code>, you need to update your
configuration:
<blockquote><pre>
<b>rcctl disable xdm</b>
<b>rcctl enable xenodm</b><!--
--></pre></blockquote>
If any local configuration change was made to <code>/etc/X11/xdm/</code>, it should
be migrated to the corresponding <code>/etc/X11/xenodm</code> file.
After that the xdm files can be removed:
<blockquote><pre>
<b>rm -rf /etc/X11/xdm</b>
<b>rm /usr/X11R6/bin/xdm /usr/X11R6/man/man1/xdm.1 /etc/rc.d/xdm</b><!--
--></pre></blockquote>
</ul>
<h3 id="ConfigChanges">Configuration and syntax changes</h3>
<ul>
<li><b>iked(8): RFC5114 MODP groups removed.</b>
Support for the additional modular exponential groups specified in RFC5114 was
removed from <a href="https://man.openbsd.org/OpenBSD-6.1/iked.8">iked(8)</a>.
As a result, iked(8) will no longer accept proposals with the MODP2048-256
group (grp24) and thus will not be able to act as a responder for clients
running OpenBSD 6.0 or earlier.
Therefore the configuration <b>on older installations</b> needs to be changed:
select a specific MODP group by adding a line such as
<code>ikesa group modp2048 childsa group modp2048</code> to be able to talk to
endpoints running newer versions.
<p>
For example, if the old configuration in
<a href="https://man.openbsd.org/OpenBSD-6.1/iked.conf.5">iked.conf(5)</a>
looked like this:
<blockquote><pre>
ikev2 active esp from 10.3.0.0/24 to 10.1.0.0/24 \
local 192.168.1.1 peer 192.168.2.1 \
childsa enc aes-128-gcm \
psk "secret"<!--
--></pre></blockquote>
it needs to be amended to look like this:
<blockquote><pre>
ikev2 active esp from 10.3.0.0/24 to 10.1.0.0/24 \
local 192.168.1.1 peer 192.168.2.1 \
ikesa group modp2048 \
childsa enc aes-128-gcm group modp2048 \
psk "secret"<!--
--></pre></blockquote>
<li><b>one lo(4) interface per rdomain.</b>
A loopback interface is now created by default for every
<a href="https://man.openbsd.org/OpenBSD-6.1/rdomain.4">rdomain(4)</a>.
Much like <code>lo0</code> for rdomain 0, it can be used to see and filter local
traffic via <a href="https://man.openbsd.org/OpenBSD-6.1/bpf.4">bpf(4)</a> and
<a href="https://man.openbsd.org/OpenBSD-6.1/pf.4">pf(4)</a>.
<p>
If you were previously using an <code>loX</code> in an rdomain other than
<code>X</code>, it won't be possible to create rdomain <code>X</code> anymore.
You need to either use a different
<a href="https://man.openbsd.org/OpenBSD-6.1/lo.4">lo(4)</a> unit or
<a href="https://man.openbsd.org/OpenBSD-6.1/rdomain.4">rdomain(4)</a> number.
<li><b>pkg.conf(5) no longer supported.</b>
The <code>pkg_*</code> tools now use the
<a href="https://man.openbsd.org/OpenBSD-6.1/installurl.5">installurl(5)</a>
file to find the main package repository.
If you install or upgrade from a mirror, this file is created automatically.
Verify that <code>/etc/installurl</code> points to your preferred mirror
and that the URI does <i>not</i> end in <code>/6.1</code> (which may happen due to
a bug in the installer).
<p>
If necessary, please create the <code>/etc/installurl</code> file manually with
your preferred <a href="../ftp.html">mirror</a>:
<blockquote><pre>
<b>echo 'https://your.mirror/pub/OpenBSD' > /etc/installurl</b><!--
--></pre></blockquote>
Since the
<a href="https://man.openbsd.org/OpenBSD-6.0/pkg.conf.5">pkg.conf(5)</a> file
will no longer be used by tools, you may remove it:
<blockquote><pre>
<b>rm /etc{,/examples}/pkg.conf</b><!--
--></pre></blockquote>
Use the <code>PKG_PATH</code> environment variable in case you need to specify more
than one repository.
<p>
<li><b>sysctl machdep.lidsuspend renamed to machdep.lidaction.</b>
The <code>machdep.lidsuspend</code> sysctl variable has been renamed to
<code>machdep.lidaction</code>.
Setting it to <code>2</code> hibernates the machine when the lid is closed.
Update
<a href="https://man.openbsd.org/OpenBSD-6.1/sysctl.conf.5">sysctl.conf(5)</a>
to use the new name.
</ul>
<h3 id="RmFiles">Files to remove</h3>
The perl distribution was upgraded to version 5.24.1.
Numerous files and directories should be removed:
<blockquote><pre>
<b>rm -rf /usr/libdata/perl5/site_perl \</b>
<b>/usr/bin/perl5* \</b>
<b>/usr/lib/libperl.so.17.* \</b>
<b>/usr/libdata/perl5/*-openbsd/5.*/ \</b>
<b>/usr/bin/a2p \</b>
<b>/usr/bin/config_data \</b>
<b>/usr/bin/find2perl \</b>
<b>/usr/bin/psed \</b>
<b>/usr/bin/s2p \</b>
<b>/usr/libdata/perl5/CGI* \</b>
<b>/usr/libdata/perl5/Locale/Codes/Constants.pod \</b>
<b>/usr/libdata/perl5/Module/Build* \</b>
<b>/usr/libdata/perl5/Package \</b>
<b>/usr/libdata/perl5/inc \</b>
<b>/usr/libdata/perl5/pod/a2p.pod \</b>
<b>/usr/libdata/perl5/unicore/lib/Gc/Lt.pl \</b>
<b>/usr/libdata/perl5/unicore/lib/Hyphen/Y.pl \</b>
<b>/usr/libdata/perl5/unicore/lib/LOE \</b>
<b>/usr/libdata/perl5/unicore/lib/NChar \</b>
<b>/usr/libdata/perl5/unicore/lib/PatWS \</b>
<b>/usr/libdata/perl5/unicore/lib/Perl/_XExtend.pl \</b>
<b>/usr/libdata/perl5/unicore/lib/Perl/_XRegula.pl \</b>
<b>/usr/libdata/perl5/unicore/lib/Perl/_XSpecia.pl \</b>
<b>/usr/libdata/perl5/unicore/lib/Space \</b>
<b>/usr/libdata/perl5/version/vpp.pm</b>
</pre></blockquote>
Remove the unused sound device nodes:
<blockquote><pre>
<b>rm -f /dev/sound*</b>
</pre></blockquote>
<h3 id="SpecPkg">Special packages</h3>
<ul>
<li><b>ansible.</b>
The <code>copy</code> module of Ansible added a newline to the value of
the <code>content</code> attribute in case it was not present.
This behavior is non-standard and was not documented.
It has been reverted in the <em>ansible-2.1.2.0p0</em> package.
If you previously relied on this behavior you will need to explicitly
add <code>\n</code> to your playbooks.
<p>
<li><b>awesome.</b>
Awesome 4.0 comes with a major API break.
Existing configuration and extensions need to be ported.
Please read the official
<a href="https://awesomewm.org/apidoc/documentation/17-porting-tips.md.html#v4">
tips for upgrading your configuration</a>.
<p>
<li><b>courier-authlib.</b>
A configuration change is needed to be able to use latest version of
<code>mail/courier-authlib</code>.
If MySQL or Postgresql is used as authentication source, the following lines
should be appended to the appropriate config files
(<code>/etc/courier/authmysqlrc</code> or <code>/etc/courier/authpgsqlrc</code>).
<blockquote><pre>
##NAME: MARKER:0
#
# Do not remove this section from this configuration file. This section
# must be present at the end of this file.<!--
--></pre></blockquote>
In addition, if MySQL is used, the option <code>MYSQL_OPT 0</code> should also be
set.
<p>
<li><b>leafnode.</b>
The <code>_news</code> account used to run leafnode switched from the
<code>news</code> group to the <code>_news</code> group.
After upgrading to <code>leafnode-1.11.11p0</code>, make sure that no
<code>leafnode</code> process is running, then run
<blockquote><pre>
<b>usermod -g _news _news</b>
<b>chgrp -R _news /var/spool/news/</b><!--
--></pre></blockquote>
<p>
<li><b>letskencrypt.</b>
The <code>security/letskencrypt</code> port was moved to base as the
<a href="https://man.openbsd.org/OpenBSD-6.1/acme-client">acme-client(1)</a>
utility.
Configuration is done via the
<a href="https://man.openbsd.org/OpenBSD-6.1/acme-client.conf.5">
acme-client.conf(5)</a>
file.
Adjust scripts/cronjobs as necessary.
<p>
<li><b>nginx.</b>
The <code>www/nginx</code> port has been converted to use subpackages with dynamic
modules, instead of using flavors.
If you previously were using a flavored version of nginx, or the mail or
stream modules, you need to install the appropriate subpackage(s).
You also need to modify your nginx configuration to use <code>load_module</code>
for each dynamic module you want to load.
<p>
<li><b>postgresql.</b>
There was a major update to PostgreSQL 9.6.2.
Use <code>pg_upgrade</code> as described in the
<a href="https://cvsweb.openbsd.org/ports/databases/postgresql/pkg/README-server?rev=1.21">postgresql-server pkg-readme</a>
or do a dump/restore.
<p>
<li><b>py-elasticsearch-curator.</b>
With the update of Elasticsearch Curator to the 4.x version, the CLI interface
changed.
Instead of parameters, yaml configuration files are used.
Configuration file documentation can be found on the
<a href="https://www.elastic.co/guide/en/elasticsearch/client/curator/4.0/index.html">
curator reference pages</a>.
<p>
<li><b>railo.</b>
Railo has been replaced with Lucee (a fork).
Make notes on your existing Railo configuration before updating.
You will need to adjust Tomcat configuration, and configure Lucee according
to your previous Railo configuration.
<p>
<li><b>sympa.</b>
The <code>mail/sympa</code> mailing list server port was updated to a new version.
The <a href="https://www.sympa.org/faq/upgrade-to-v6.2">upgrade notes</a>
explain how to migrate your setup.
<p>
<li><b>tomcat.</b>
<code>www/tomcat/v8</code> has been updated to 8.5, which now enforces a default
umask of 027 (previously, unless other changes were made, 022 would be used).
This behavior can be controlled by setting the UMASK environment variable.
If using the rc.d script and the previous behaviour is required, the following
can be added to /etc/login.conf:
<blockquote><pre>
tomcat:\
:setenv=UMASK=022:\
:tc=daemon:<!--
--></pre></blockquote>
All branches of <code>www/tomcat</code> now have stricter requirements on
URL encoding to avoid a range of invalid characters (see CVE-2016-6816).
This includes several characters which are quite often used in unencoded
form: <code>{ }</code> and <code>|</code>.
For these three characters only, if callers cannot be fixed, the
restriction can be relaxed by listing the ones you need in this setting
in /etc/rc.conf.local:
<blockquote><pre>
tomcat_flags=-server -Dtomcat.util.http.parser.HttpParser.requestTargetAllow='|'<!--
--></pre></blockquote>
<p>
<li id="uucp"><b>uucp.</b>
Starting with <code>uucp-1.07p4</code>, the uucp suite now runs under the
<code>_uucp</code> account.
Ensure that you have no uucp process running, then adjust the ownership of
some files:
<blockquote><pre>
<b>find /etc/ /var/spool/ -user uucp -exec chown _uucp {} ';'</b><!--
--></pre></blockquote>
</ul>
<hr>
<h2 id="NoInstKern">Upgrade without the install kernel</h2>
<b style="color:#e00000">This is NOT the recommended process.
Use the install kernel method if at all possible!</b>
<p>
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.
<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 exaggerate 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 200MB free on <code>/usr</code> would be recommended.
<p>
<li><b>Become root.</b>
While using
<a href="https://man.openbsd.org/OpenBSD-6.1/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-6.1/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-6.1/amd64/installboot">
installboot(8)</a>, assuming <code>sd0</code> is your boot disk:
<blockquote><pre>
<b>installboot sd0</b><!--
--></pre></blockquote>
</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:
<blockquote><pre>
<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>
</blockquote>
If using the single processor kernel:
<blockquote><pre>
<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></blockquote>
<li><b>Install new userland.</b>
Save a copy of reboot(8), extract and install the release tarballs, reboot.
Install <code>base61.tgz</code> last, because the new base system, in particular
<a href="https://man.openbsd.org/OpenBSD-6.1/tar">tar(1)</a>,
<a href="https://man.openbsd.org/OpenBSD-6.1/gzip">gzip(1)</a> and
<a href="https://man.openbsd.org/OpenBSD-6.1/reboot">reboot(8)</a>,
will not work with the old kernel.
Either untar the needed filesets manually
<blockquote><pre>
<b>cp /sbin/reboot /sbin/oreboot</b>
<b>tar -C / -xzphf xshare61.tgz</b>
<b>tar -C / -xzphf xserv61.tgz</b>
<b>tar -C / -xzphf xfont61.tgz</b>
<b>tar -C / -xzphf xbase61.tgz</b>
<b>tar -C / -xzphf man61.tgz</b>
<b>tar -C / -xzphf game61.tgz</b>
<b>tar -C / -xzphf comp61.tgz</b>
<b>tar -C / -xzphf base61.tgz</b> # Install last!
<b>/sbin/oreboot</b><!--
--></pre></blockquote>
or, if you use ksh(1), you can do
<blockquote><pre>
<b>cp /sbin/reboot /sbin/oreboot</b>
<b>for _f in [!b]*61.tgz base61.tgz; do tar -C / -xzphf "$_f" || break; done</b>
<b>/sbin/oreboot</b><!--
--></pre></blockquote>
Note that tar(1) 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-6.1/amd64/MAKEDEV">MAKEDEV(8)</a>:
<blockquote><pre>
<b>cd /dev</b>
<b>./MAKEDEV all</b><!--
--></pre></blockquote>
<li><b>Update boot loader.</b>
Still assuming <code>sd0</code> is your boot disk:
<blockquote><pre>
<b>installboot sd0</b><!--
--></pre></blockquote>
<li><b>Update system configuration files.</b>
Run <a href="https://man.openbsd.org/OpenBSD-6.1/sysmerge">sysmerge(8)</a>:
<blockquote><pre>
<b>sysmerge</b><!--
--></pre></blockquote>
<li><b>Update firmware.</b>
There may be new firmware for your system.
Update it with
<a href="https://man.openbsd.org/OpenBSD-6.1/fw_update">fw_update(1)</a>:
<blockquote><pre>
<b>fw_update</b><!--
--></pre></blockquote>
<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="#AfterUpgrade">after upgrading</a> above
also apply to manual upgrades.
Finally, remove <code><b>/sbin/oreboot</b></code> and update packages:
<code><b>pkg_add -u</b></code>.
</ul>
<p>
<a href="index.html">[FAQ Index]</a> |
<a href="upgrade60.html">[5.9 -> 6.0]</a>
<a href="upgrade62.html">[6.1 -> 6.2]</a>
<hr>
<small>$OpenBSD: upgrade61.html,v 1.30 2019/06/01 23:12:52 deraadt Exp $</small>
![[BACK]](/icons/back.gif){kind=icon}
Return to upgrade61.html CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [local] / www / faq