From nobody Sat Jan 27 11:00:51 2024 X-Original-To: questions@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TMWpL0pzdz58Crt for ; Sat, 27 Jan 2024 11:01:30 +0000 (UTC) (envelope-from odhiambo@gmail.com) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TMWpK0KkWz4j1f for ; Sat, 27 Jan 2024 11:01:29 +0000 (UTC) (envelope-from odhiambo@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=WOmqaK4X; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of odhiambo@gmail.com designates 2a00:1450:4864:20::12a as permitted sender) smtp.mailfrom=odhiambo@gmail.com Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-5102b43035eso875188e87.1 for ; Sat, 27 Jan 2024 03:01:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706353287; x=1706958087; darn=freebsd.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=HZaFzlZUR74W6AgjjtS0oUnN3owOHUR9nFJAHiaaVRY=; b=WOmqaK4XXl/uMCqjizvccYj+m0FyWi/ZVKcKQu+U+Hbw87sI1Le+VxaJ2lNhibNIAt I6LzosDq2H/nUg3DDM7BsRIsiIJle4l1j77IHpFZGt4iqE/gb1epJsynOs5LvQdDoI9z fFTJC2laovR6TfmXN01HU3W19o5LdbamoqDh892UFX1EVcu0ZqoOtWC/IP+Wm0xVcjS+ wJCOO3Y0iOPy5Si4XG9FeChZai2QI35+tBZDWgLZ4H+KYIDPZgD2pC8cDQ+ExtTOQ30i sD5FuDEX6ZuMxzBBiPzCCQGzmIZDRqdGD9/pcHvzhj875YC5OXOQfX4t5vkkOm4QdxuQ x/Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706353287; x=1706958087; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HZaFzlZUR74W6AgjjtS0oUnN3owOHUR9nFJAHiaaVRY=; b=grNn4B4X18Tq+yRF8IR5ZdmQyyyPHNjQF9Aek6E1cWeiIE271l1Vpf7/FobW/dFprs rTJPWQpOjevQuUQS8YtFIgELyGNDWMCCIZwOaN45AO+LefnTSffSCkYAKCKEhlX5EwgY pElYwvZFTQki9R4uYaoxRP8DXethP7mpU3M0WcKjaOGIfnAG65Yi2PLQDgroW/gX55Py QQ7ISh/iddd392t09bqei2Y6bv97GeMHQ4lEZ3DirGFpeyMfOIijLNbLz1FC2wPtN16C E3+GP1AiQHf3X5z6MtcGQQi6MDp3XtPTHO+ZJpYY0URVy+0fYXCNgcL2mTf5gUhBvyX3 l02g== X-Gm-Message-State: AOJu0YyDnMj0SW25Yan+15S1SvFKYnbh0lhIeeq6GWCVV3zDSBkJg0Jb ITpR29eoENx1sY2bDTwJ+Le1n2vv255xIQLyuXRki/B4mZdezyeez2musc+A6IDqAfFkQImbS4W 2y897CHK8KkaFTkrMFYM4h2PrNQr8Deq/dMo= X-Google-Smtp-Source: AGHT+IGu5Sa0x3wOmuqmWaQ2CKycBI719eVrDQn55OB29fSYsEYC9VX8JLmX6+4pETbLAhEymAMhUO7lBk1TcIC7jho= X-Received: by 2002:a2e:890b:0:b0:2cf:334a:999a with SMTP id d11-20020a2e890b000000b002cf334a999amr692185lji.32.1706353286551; Sat, 27 Jan 2024 03:01:26 -0800 (PST) List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Odhiambo Washington Date: Sat, 27 Jan 2024 14:00:51 +0300 Message-ID: Subject: Re: Upgrade 8.4-STABLE to 14-STABLE To: questions@freebsd.org Content-Type: multipart/alternative; boundary="000000000000819ca0060feb5501" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.10 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_SHORT(-0.10)[-0.098]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[questions@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MLMMJ_DEST(0.00)[questions@freebsd.org]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12a:from] X-Rspamd-Queue-Id: 4TMWpK0KkWz4j1f --000000000000819ca0060feb5501 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jan 27, 2024 at 12:59=E2=80=AFPM 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) =3D> 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=3Dyes' > 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 boxe= s. > /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. --=20 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 '^$|^.*#' =C2=AF\_(=E3=83=84)_/=C2=AF :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html] --000000000000819ca0060feb5501 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Jan 27, 2024 at 12:59=E2=80= =AFPM 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 t= o
> 14-RELEASE?

=C2=A0 =C2=A0Hopefully others have better things to say or a more brief sum= mary,
but for now...
=C2=A0 =C2=A0"Maybe" other ways work but from a build+install sou= rce 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 <= br> 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.
=C2=A0 =C2=A0Binary packages require you start and end with a more formal r= elease
such as 13.2-RELEASE (or whatever last 13 release was) =3D> 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.
=C2=A0 =C2=A0Obviously as there would be many updates+reboots happening wit= h 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 <= br> compatible until reinstalled or compatibility libraries are installed.
=C2=A0 =C2=A0Maybe it would be wise to consider 'replacing' the ins= tall 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.
=C2=A0 =C2=A0If you have ZFS as root and are planning to upgrade to newer <= br> filesystem/pool versions (performed with zfs related commands, not with source installs or FreeBSD's update tool), you should make sure you tak= e
steps to upgrade the boot loader code before that operation is performed. =C2=A0 =C2=A0If you have backups, you always have a way to undo what has be= en 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.
=C2=A0 =C2=A0'Maybe' pkg switched through pkgng within this timefra= me; 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 o= utput
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=3Dyes'
chflags -R noschg /usr/obj/usr;rm -rf /usr/obj/usr;cd /usr/src&&mak= e
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&&et= cupdate
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 righ= t 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.


--
Best regards,
Odhiambo WASHINGTON,<= br>Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
=C2=A0In=C2=A0an Internet failure case, the #1 suspect is a constant: DNS.
= "Oh, the cruft.",=C2=A0egre= p -v '^$|^.*#'=C2=A0=C2=AF\_(=E3=83=84)_/= =C2=AF=C2=A0:-)
[How to ask smart questions:=C2=A0http://www.catb.org/~esr/faqs/smart-que= stions.html]
--000000000000819ca0060feb5501--