From: Klemens Nanni <kn@openbsd.org>
Subject: Re: sysupgrade -S siteXY.tgz
To: tech@openbsd.org
Date: Sun, 14 Jun 2026 10:54:10 +0000

12.06.2026 20:01, Stefan Sperling пишет:
> At present, a site set with custom files must be uploaded to the same
> mirror which base sets are fetched from. Else the site set is not
> available during installation and upgrades. This makes it a bit
> difficult to use official installation mirrors with site sets during
> upgrades since a custom mirror is required to serve the site set from.
> 
> With the patch below, sysupgrade can handle a site set locally, while
> fetching sets from official mirrors.
> 
> I wrote this because I was tasked to upgrade outdated systems I did not
> set up myself, which had quite a few customizations made by other people,
> partly unique across each system. An untested in-place upgrade was deemed
> too risky because downtime was a huge concern.
> 
> What I did when moving this fleet of machines from 7.5 to 7.9 was roughly:
> 
>   # on production machine
>   tar -C / -zcvf /tmp/site75.tgz /all/customized/files ...
> 
>   # copy site75.tgz off the procution machine, and merge changes between
>   # 7.5 and 7.9 with their custom changes, much like sysmerge would do
>   # after a successful in-place upgrade:
>   mergesiteset site75.tgz
> 
>   # (see here for mergesiteset:
>   # https://marc.info/?l=openbsd-ports&m=178127596851228&w=2 )
> 
>   # Perform test upgrades in customized 7.5 VMs over and over, fix the
>   # merged site set until everything works as expected.
> 
>   # Eventually, successfully update production systems in-place with
>   # all modifications intact, using a pre-prepared site set and a
>   # sysupgrade which includes the patch below (and some other tweaks
>   # specific to these systems I cannot share):
>   sysupgrade -R 7.9 -S /tmp/site79.tgz
> 
> This could be useful to other people who are managing multiple OpenBSD
> systems with some tweaks applied.
> 
> And if there's no interest, then that's fine, too. It's a small local
> change I can carry with little effort.
> 
> 
>  add support for custom site sets to sysupgrade
>  
> M  usr.sbin/sysupgrade/sysupgrade.8   |   7+  0-
> M  usr.sbin/sysupgrade/sysupgrade.sh  |  18+  3-
> 
> 2 files changed, 25 insertions(+), 3 deletions(-)
> 
> commit - b5f1a9c5e77f3bfe0e6eed9fcd0cf0c458ccac64
> commit + b974289573def6a011ddb7b1456b120de0c9cafc
> blob - 41438ad98167851b352ac80e274b7b4d347fe219
> blob + b32efa8b370cde5425d834bd2e65c33be3e2e277
> --- usr.sbin/sysupgrade/sysupgrade.8
> +++ usr.sbin/sysupgrade/sysupgrade.8
> @@ -25,6 +25,7 @@
>  .Op Fl fkns
>  .Op Fl b Ar base-directory
>  .Op Fl R Ar version
> +.Op Fl S Ar siteXY.tgz
>  .Op Ar installurl | path
>  .Sh DESCRIPTION
>  .Nm
> @@ -73,6 +74,12 @@ Downgrading is unlikely to work.
>  .It Fl s
>  Upgrade to a snapshot.
>  The default is to upgrade to the next release.
> +.It Fl S Ar siteXY.tgz
> +Install a custom
> +.Ar siteXY.tgz
> +set during the upgrade in addition to the regular
> +.Ox
> +release sets.
>  .El
>  .Pp
>  When updating to a release or snapshot which lacks the required signify
> blob - 6d893e5f9e245140768c595fddcc4b7e274ea95d
> blob + 482fe3dd0b1ea2d3af1fc1ebf7d77223b989c023
> --- usr.sbin/sysupgrade/sysupgrade.sh
> +++ usr.sbin/sysupgrade/sysupgrade.sh
> @@ -35,7 +35,7 @@ err()
>  
>  usage()
>  {
> -	echo "usage: ${0##*/} [-fkns] [-b base-directory] [-R version] [installurl | path]" 1>&2
> +	echo "usage: ${0##*/} [-fkns] [-b base-directory] [-R version] [-S siteXY.tgz] [installurl | path]" 1>&2
>  	return 1
>  }
>  
> @@ -79,11 +79,13 @@ FORCE_VERSION=false
>  KEEP=false
>  REBOOT=true
>  WHAT='release'
> +PATH_SITESET=''
> +SITESET=''
>  
>  VERSION=$(uname -r)
>  NEXT_VERSION=$(echo ${VERSION} + 0.1 | bc)
>  
> -while getopts b:fknrR:s arg; do
> +while getopts b:fknrR:sS: arg; do
>  	case ${arg} in
>  	b)	SETSDIR=${OPTARG}/_sysupgrade;;
>  	f)	FORCE=true;;
> @@ -95,6 +97,11 @@ while getopts b:fknrR:s arg; do
>  		    err "invalid version: ${OPTARG}"
>  		NEXT_VERSION=${OPTARG};;
>  	s)	SNAP=true;;
> +	S)	PATH_SITESET=$(realpath "${OPTARG}");
> +		SITESET=$(basename "${OPTARG}");

; are not needed here, the R) does not use them, either.

> +		[[ "${SITESET}" == @(site[0-9][0-9].tgz) ]] || 

Inside [[ quotes are generally not needed, see other uses in this file.

The version check should be the same as for -R...
or could [NEXT_]VERSION be used here?

> +		    err "invalid site set: ${OPTARG}";
> +		;;
>  	*)	usage;;
>  	esac
>  done
> @@ -218,14 +225,22 @@ if [[ -n ${DL} ]]; then
>  	unpriv cksum -qC SHA256 ${DL}
>  fi
>  
> +if [ -n "${PATH_SITESET}" ]; then

Please use [[ consistently.

> +	cp ${PATH_SITESET} .
> +	ls -l > index.txt
> +fi
> +
>  cat <<__EOT >/auto_upgrade.conf
>  Location of sets = disk
>  Pathname to the sets = ${SETSDIR}/
>  Directory does not contain SHA256.sig. Continue without verification = yes
>  __EOT
> +if [ -n "${SITESET}" ]; then

Same here.

> +	echo "Set name(s) = +${SITESET}" >>/auto_upgrade.conf
> +fi
>  
>  if ! ${KEEP}; then
> -	CLEAN=$(echo BUILDINFO SHA256 ${SETS} | sed -e 's/ /,/g')
> +	CLEAN=$(echo BUILDINFO SHA256 ${SETS} index.txt ${SITESET} | sed -e 's/ /,/g')
>  	cat <<__EOT > /etc/rc.firsttime
>  rm -f ${SETSDIR}/{${CLEAN}}
>  __EOT
>