Re: sysupgrade -S siteXY.tgz

Klemens Nanni <[email protected]>
Newsgroups gmane.os.openbsd.tech
Message-ID <[email protected]>
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
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.