Re: Upgrade 8.4-STABLE to 14-STABLE

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?



-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
 In an Internet failure case, the #1 suspect is a constant: DNS.
"Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)
[How to ask smart questions:
http://www.catb.org/~esr/faqs/smart-questions.html]