Re: Upgrade 8.4-STABLE to 14-STABLE

On 1/27/24 00:55, Odhiambo Washington wrote:
> Is there a way to upgrade 8.4-STABLE to 14-STABLE, or even change it to
> 14-RELEASE?

   Hopefully others have better things to say or a more brief summary, 
but for now...
   "Maybe" other ways work but from a build+install source approach I 
presume the intended way was to build then install the most up to date 
8-STABLE, then 9-STABLE, etc. until you are on 14-STABLE. Where 
mergemaster used to be used for cvs & svn updates, etcupdate became a 
thing and I think required once you are on versions only available 
through git; you will need to run etcupdate starting with a source tree 
matching the currently installed version before updating the source tree 
as you start to use it. I do not recall what versions introduced or 
required it but it is required when working from a git source repository 
instead of cvs/svn.
   Binary packages require you start and end with a more formal release 
such as 13.2-RELEASE (or whatever last 13 release was) => 14.0-RELEASE. 
If using ZFS, my understanding is that binary updates across major 
versions seem to be painfully slow. You would need to switch to and 
install the nearest -RELEASE version. If using a custom kernel then you 
would still be stuck building it from source but otherwise can use 
binary updates for it too.
   Obviously as there would be many updates+reboots happening with a # 
of API revisions, I'd make sure 3rd party kernel modules that aren't 
necessary for the update are not being loaded until after the updates to 
FreeBSD + the modules are completed. For good measure, just shut down 
unneeded software from startup, cron, etc. as the won't likely be API 
compatible until reinstalled or compatibility libraries are installed.
   Maybe it would be wise to consider 'replacing' the install instead of 
binary updating if not for speed of its multiple steps alone. I presume 
such drastic action is the only single step process but would be 
interested if others have suggestions otherwise.
   If you have ZFS as root and are planning to upgrade to newer 
filesystem/pool versions (performed with zfs related commands, not with 
source installs or FreeBSD's update tool), you should make sure you take 
steps to upgrade the boot loader code before that operation is performed.
   If you have backups, you always have a way to undo what has been done 
in case anything goes wrong or doesn't work. /usr/src/UPDATING is also 
wise to read/follow for any -STABLE user in addition to the -STABLE 
mailing list. Nothing comes to mind of what to be aware of from it 
despite that I probably have done that same upgrade path on the machine 
I am typing this reply on though I migrated when each -STABLE branch was 
new rather than old. I have not yet upgraded to 14 though.
   'Maybe' pkg switched through pkgng within this timeframe; it has a 
database conversion process that you can go through though I think it 
leaves behind the old data layout for you to manually dispose of. Could 
also just uninstall 'all' packages then reinstall/replace with what is 
now available once upgraded. Handbook at least used to talk of this 
conversion which I 'think' was a thing around v9 or so. Tools can output 
a list of installed packages including pkgng's `pkg prime-list` command 
which can then help reinstall after a bulk removal and portmaster has a 
documented set of steps which can aid in that too.

And for a brief command summary and/or comments I'd use for source 
upgrades (over and over and...modify as your system needs):

cd /usr/src
#if using etcupdate for the first time, you must use its preparation 
step before updating the source tree; see other documentation.
#update the source tree using git, svn, or whatever tool...
#git switch releng/14.0
git switch stable/13
#remove vendor branches; at least one of the updates has requires this
git remote prune origin
#update source tree with git
git pull --ff-only
#cleanup the build path; I had to perform this to even go from 13-STABLE 
to 14-STABLE and have the build not fail, possibly because I accelerate 
my updates by using things like 'WITH_META_MODE=yes'
chflags -R noschg /usr/obj/usr;rm -rf /usr/obj/usr;cd /usr/src&&make 
cleandir&&make cleandir
#slower but more reliable build with a kernel install if successful
make buildworld&&make buildkernel&&make installkernel
#faster build, run in background, provide less output. This will hang if 
PORTS_MODULES is used and a dialog comes up during any port build as 
jobs count is incompatible with PORTS_MODULES + `make comfig` dialog boxes.
/usr/bin/nice -n 18 /usr/sbin/idprio 31 make -sj8 buildworld 
buildkernel&&make installkernel
shutdown now
fsck -p
mount -u /
mount -a
sh /etc/rc.d/zfs start
cd /usr/src
#adjkerntz -i # if CMOS is not UTC
#mergemaster -iUFp #disabled as I use etcupdate now
etcupdate -p
cd /usr/src&&make installworld&&make delete-old&&etcupdate
shutdown -r now

#These steps should only need to be done at the end.
#update bootcode for ZFS on root; UEFI requires different steps. This 
must be done before zpool/zfs changes for bootable root pools. If the 
partition is too small, this will fail; I stole swap space with 
deletes+recreates to work past that. This should be repeated for every 
disk that could be asked upon to boot the system.
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada1
#next up, upgrade/replace packages with up to date copies. I have used 
different ways of doing this over time such as manually uninstalling 
then running `make install clean` in a ports directory, simplified with 
portupgrade and I was never a big user of portmaster as I found failures 
of one sort or another too common and it aborts midtask on those, and 
now currently use pkg form a custom built repository using poudriere.
#once packages are all updated one way or another
cd /usr/src;make delete-old-libs