Re: Upgrade 8.4-STABLE to 14-STABLE

On 1/27/24 05:50, Odhiambo Washington wrote:
> On Sat, Jan 27, 2024 at 3:45 PM Edward Sanford Sutton, III <
> mirror176@hotmail.com> wrote:
> 
>> On 1/27/24 04:00, Odhiambo Washington wrote:
>>> On Sat, Jan 27, 2024 at 12:59 PM Edward Sanford Sutton, III <
>>> mirror176@hotmail.com> wrote:
>>>
>>>> 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
>>>>
>>>
>>> Thank you very much for the detailed procedure.
>>> By the look of things, this is quite involving and I believe requires one
>>> to have the machine right next to them.
>>> I am not using ZFS at all.
>>> I was hoping there is a way to switch from STABLE to RELEASE and then
>> just
>>> use freebsd-update.
>>
>>     Don't see why you couldn't do one last source tree update to
>> 8.4-RELEASE (if doing the work, "I'd" go to 9.3-RELEASE with this step
>> myself; doubt you really need to do 9.0 first), rebuild+reinstall so you
>> are now on a -RELEASE as freebsd-update would want to work from, then
>> proceed with its steps. Somewhere after 9 (or was it 10) there were
>> compiler changes that have /usr/src/UPDATING saying what steps to take
>> first (so at least that oneintermediate build would be needed).
>>     I thought steps would then be upgrade through each major next major
>> version, which is safest to perform by reaching the #.0, then go to the
>> latest #.# (9.0>9.4>10.0>10.4>11.0>11.4>...) but the #.0 seems like a
>> useless step to me as it technically means you would be rolling between
>> older and newer releases. If you cannot just do an upgrade by stating
>> the final desired version, even if multiple reboots & runs would be
>> needed if intermediate versions are required, that seems like a bug to me.
>>     Would be wise to refer to release notes and errata (or was it
>> elsewhere) as they have documented issues with upgrades that people need
>> to be aware of such as 12.4p6 and 13.2p3 having a fix for freebsd-update
>> corrupting files since moving to git.
>>
> 
> Might you have time to detail the steps for this?

   You got me wondering how well freebsd-update does vs my time 
consuming but reliable build+install from source routine. I'll have 
steps out hopefully within the next day or 2, and hopefully remembering 
to add some basic security checks that can be ran to bring trust back to 
the machine.
   Of course this won't include more advanced topics like migrating from 
i386 to amd64, mbr to gpt disk layout, or legacy BIOS to UEFI boot 
loader changes. With such an old system, any of those could be relevant 
topics that need to be considered too.