From nobody Sat Jan 27 12:50:05 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 4TMZDN28d6z5897v for ; Sat, 27 Jan 2024 12:50:44 +0000 (UTC) (envelope-from odhiambo@gmail.com) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 4TMZDM3nvtz3wdn for ; Sat, 27 Jan 2024 12:50:43 +0000 (UTC) (envelope-from odhiambo@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=JOiUKZey; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of odhiambo@gmail.com designates 2a00:1450:4864:20::230 as permitted sender) smtp.mailfrom=odhiambo@gmail.com Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-2cf33035d1dso14953931fa.2 for ; Sat, 27 Jan 2024 04:50:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706359841; x=1706964641; 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=we5bTjEkiy5s2eTwSM7UVOegWBS7eXeDN48BhMrB1K0=; b=JOiUKZeyBEMQSJEqTEhWMlb8MbmwNYJT5Sz+b7MY5KTxZNyaHeu7v95HjJOC7vOAvb hvTMDAq1hoh8DCHexAnbXpYvNcboEEIG+wJHpdFBlexuYlZgOLJ9hh+Q9xlmAmA8aJa7 +n92GAxBBrqq5hOkqeDC52TCkPot21kOlay89jMCHRxG5/X9C+Gl6l3ZXNn6odG7OMrV 1LmlnfwNZEOcGx22yPQ74ZrN0enofGth2O32axi1WVqWLP7LaG0SBMiFG0+1z9hZQJk7 Ljz2Up29vxtfmU5N/s3Pmkv1BLZLDIueUn7EMpR/9lcfBUNdBTtT8l3t10qcCHF2B1bf QSVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706359841; x=1706964641; 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=we5bTjEkiy5s2eTwSM7UVOegWBS7eXeDN48BhMrB1K0=; b=ecSPnRf93l8OdNrlCEVEvh/rhsGD0QfqcoZ3CK5+DzVglUrJdUPXE/T23+2TWTrygv tBzhYZ4YOiNm5Pd4ZZNEgva445pHFAKyNu4GRm0S/dRAIJ9HF64fGbmLBYzmLesGNU4l pM14vP5o8O2tF3d15fISzhnSymLfq7DFJLfmblN3nXdD68mt1CFSlTlg6qNjDAauAA2Y V7Jl3NPXxONP2Gubjz4p15ejoVfWy5wPf8x1dcnz6zmT0ZjI4cR1/4wqwhjvJApbxgP8 gId/DnrjbYE0PhoOAKQMDUD1by5yRLhqAKUAF4TVLNv0/Du0NWintafJrX4RocuAFXZs fFmg== X-Gm-Message-State: AOJu0YwDkIfzldbzvp/Wo0z4PnfEOwVMwBOajnqDTdtcyFuGq+ZJ6KVt JmDN6ppZ12qwYMlU7zBfMFmaduvWgoI3VEQrDcGLsCVJr6CLYeJKk1VyG0P6RPlUooyL9r/PU6Q eZEeTyXMdFK225P3UL6TxzRATPSHKmsJkTW8= X-Google-Smtp-Source: AGHT+IGjoZLmMxnMylYeisfSLNSv3LephH7VO0uhXGFtIotAl9w+eHT9MttmXjNBBIG7Qa4R5si/nhv/4JAgm1Bl4Vg= X-Received: by 2002:a2e:bc0f:0:b0:2cc:df75:79b3 with SMTP id b15-20020a2ebc0f000000b002ccdf7579b3mr1371420ljf.12.1706359840906; Sat, 27 Jan 2024 04:50:40 -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 15:50:05 +0300 Message-ID: Subject: Re: Upgrade 8.4-STABLE to 14-STABLE To: questions@freebsd.org Content-Type: multipart/alternative; boundary="0000000000002d2074060fecdc42" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.06 / 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.06)[-0.065]; 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::230:from] X-Rspamd-Queue-Id: 4TMZDM3nvtz3wdn --0000000000002d2074060fecdc42 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jan 27, 2024 at 3:45=E2=80=AFPM 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=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 tre= e > >> matching the currently installed version before updating the source tr= ee > >> 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 reposito= ry > >> instead of cvs/svn. > >> Binary packages require you start and end with a more formal relea= se > >> such as 13.2-RELEASE (or whatever last 13 release was) =3D> 14.0-RELEA= SE. > >> 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 yo= u > >> 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 presum= e > >> 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 wit= h > >> source installs or FreeBSD's update tool), you should make sure you ta= ke > >> 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 machin= e > >> I am typing this reply on though I migrated when each -STABLE branch w= as > >> 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. Coul= d > >> 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 outp= ut > >> a list of installed packages including pkgng's `pkg prime-list` comman= d > >> 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-STAB= LE > >> to 14-STABLE and have the build not fail, possibly because I accelerat= e > >> 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 > 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 wit= h > >> portupgrade and I was never a big user of portmaster as I found failur= es > >> 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 o= ne > > 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? --=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] --0000000000002d2074060fecdc42 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Jan 27, 2024 at 3:45=E2=80=AF= 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=E2=80=AFPM Edward Sanford Sutton, III &l= t;
> mirror176@h= otmail.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 cha= nge it to
>>> 14-RELEASE?
>>
>>=C2=A0 =C2=A0 =C2=A0Hopefully others have better things to say or a= more brief summary,
>> but for now...
>>=C2=A0 =C2=A0 =C2=A0"Maybe" other ways work but from a bu= ild+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 b= ecame 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 sourc= e tree
>> as you start to use it. I do not recall what versions introduced o= r
>> required it but it is required when working from a git source repo= sitory
>> instead of cvs/svn.
>>=C2=A0 =C2=A0 =C2=A0Binary 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 an= d
>> install the nearest -RELEASE version. If using a custom kernel the= n you
>> would still be stuck building it from source but otherwise can use=
>> binary updates for it too.
>>=C2=A0 =C2=A0 =C2=A0Obviously as there would be many updates+reboot= s 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 upda= tes to
>> FreeBSD + the modules are completed. For good measure, just shut d= own
>> unneeded software from startup, cron, etc. as the won't likely= be API
>> compatible until reinstalled or compatibility libraries are instal= led.
>>=C2=A0 =C2=A0 =C2=A0Maybe it would be wise to consider 'replaci= ng' the install instead of
>> binary updating if not for speed of its multiple steps alone. I pr= esume
>> such drastic action is the only single step process but would be >> interested if others have suggestions otherwise.
>>=C2=A0 =C2=A0 =C2=A0If you have ZFS as root and are planning to upg= rade to newer
>> filesystem/pool versions (performed with zfs related commands, not= with
>> source installs or FreeBSD's update tool), you should make sur= e you take
>> steps to upgrade the boot loader code before that operation is per= formed.
>>=C2=A0 =C2=A0 =C2=A0If you have backups, you always have a way to u= ndo 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 -STABL= E
>> 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 ma= chine
>> I am typing this reply on though I migrated when each -STABLE bran= ch was
>> new rather than old. I have not yet upgraded to 14 though.
>>=C2=A0 =C2=A0 =C2=A0'Maybe' pkg switched through pkgng with= in 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 thi= s
>> conversion which I 'think' was a thing around v9 or so. To= ols 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 so= urce
>> upgrades (over and over and...modify as your system needs):
>>
>> cd /usr/src
>> #if using etcupdate for the first time, you must use its preparati= on
>> 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 accel= erate
>> 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 successfu= l
>> make buildworld&&make buildkernel&&make installker= nel
>> #faster build, run in background, provide less output. This will h= ang if
>> PORTS_MODULES is used and a dialog comes up during any port build = as
>> jobs count is incompatible with PORTS_MODULES + `make comfig` dial= og 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&am= p;&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. T= his
>> 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 e= very
>> 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 uninstalli= ng
>> then running `make install clean` in a ports directory, simplified= with
>> portupgrade and I was never a big user of portmaster as I found fa= ilures
>> of one sort or another too common and it aborts midtask on those, = and
>> now currently use pkg form a custom built repository using poudrie= re.
>> #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.

=C2=A0 =C2=A0Don't see why you couldn't do one last source tree upd= ate 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).
=C2=A0 =C2=A0I 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.<= br> =C2=A0 =C2=A0Would 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.

M= ight you have time to detail the steps for this?
=C2=A0


-= -
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
= +254 7 3200 0004/+254 7 2274 3223
=C2=A0In=C2=A0an Internet f= ailure case, the #1 suspect is a constant: DNS.
"Oh, the cruft.",=C2=A0egrep -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-questions.html]<= /span>
--0000000000002d2074060fecdc42--