Date: Sat, 27 Jan 2024 15:50:05 +0300 From: Odhiambo Washington <odhiambo@gmail.com> To: questions@freebsd.org Subject: Re: Upgrade 8.4-STABLE to 14-STABLE Message-ID: <CAAdA2WPocrL_gJ8Edt_Oj7NqfZteJv85xnC3a_nSyX6iHQr1FQ@mail.gmail.com> In-Reply-To: <CO1PR11MB4770952A9947D3851A1D0BBFE6782@CO1PR11MB4770.namprd11.prod.outlook.com> References: <CAAdA2WNLg19usv2ryO-s=EavDw%2BA1BQq_m_xUTu8RYCTVpbDzg@mail.gmail.com> <CO1PR11MB477085FF2A427126ED5A07C7E6782@CO1PR11MB4770.namprd11.prod.outlook.com> <CAAdA2WOyv4G7dDn=0UiqdBr_oEXCDtDKbZrzPaLBkhkmNYHMMg@mail.gmail.com> <CO1PR11MB4770952A9947D3851A1D0BBFE6782@CO1PR11MB4770.namprd11.prod.outlook.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Sat, Jan 27, 2024 at 3:45=E2=80=AF= PM Edward Sanford Sutton, III <<a href=3D"mailto:mirror176@hotmail.com">= mirror176@hotmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_qu= ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20= 4);padding-left:1ex">On 1/27/24 04:00, Odhiambo Washington wrote:<br> > On Sat, Jan 27, 2024 at 12:59=E2=80=AFPM Edward Sanford Sutton, III &l= t;<br> > <a href=3D"mailto:mirror176@hotmail.com" target=3D"_blank">mirror176@h= otmail.com</a>> wrote:<br> > <br> >> On 1/27/24 00:55, Odhiambo Washington wrote:<br> >>> Is there a way to upgrade 8.4-STABLE to 14-STABLE, or even cha= nge it to<br> >>> 14-RELEASE?<br> >><br> >>=C2=A0 =C2=A0 =C2=A0Hopefully others have better things to say or a= more brief summary,<br> >> but for now...<br> >>=C2=A0 =C2=A0 =C2=A0"Maybe" other ways work but from a bu= ild+install source approach I<br> >> presume the intended way was to build then install the most up to = date<br> >> 8-STABLE, then 9-STABLE, etc. until you are on 14-STABLE. Where<br= > >> mergemaster used to be used for cvs & svn updates, etcupdate b= ecame a<br> >> thing and I think required once you are on versions only available= <br> >> through git; you will need to run etcupdate starting with a source= tree<br> >> matching the currently installed version before updating the sourc= e tree<br> >> as you start to use it. I do not recall what versions introduced o= r<br> >> required it but it is required when working from a git source repo= sitory<br> >> instead of cvs/svn.<br> >>=C2=A0 =C2=A0 =C2=A0Binary packages require you start and end with = a more formal release<br> >> such as 13.2-RELEASE (or whatever last 13 release was) =3D> 14.= 0-RELEASE.<br> >> If using ZFS, my understanding is that binary updates across major= <br> >> versions seem to be painfully slow. You would need to switch to an= d<br> >> install the nearest -RELEASE version. If using a custom kernel the= n you<br> >> would still be stuck building it from source but otherwise can use= <br> >> binary updates for it too.<br> >>=C2=A0 =C2=A0 =C2=A0Obviously as there would be many updates+reboot= s happening with a #<br> >> of API revisions, I'd make sure 3rd party kernel modules that = aren't<br> >> necessary for the update are not being loaded until after the upda= tes to<br> >> FreeBSD + the modules are completed. For good measure, just shut d= own<br> >> unneeded software from startup, cron, etc. as the won't likely= be API<br> >> compatible until reinstalled or compatibility libraries are instal= led.<br> >>=C2=A0 =C2=A0 =C2=A0Maybe it would be wise to consider 'replaci= ng' the install instead of<br> >> binary updating if not for speed of its multiple steps alone. I pr= esume<br> >> such drastic action is the only single step process but would be<b= r> >> interested if others have suggestions otherwise.<br> >>=C2=A0 =C2=A0 =C2=A0If you have ZFS as root and are planning to upg= rade to newer<br> >> filesystem/pool versions (performed with zfs related commands, not= with<br> >> source installs or FreeBSD's update tool), you should make sur= e you take<br> >> steps to upgrade the boot loader code before that operation is per= formed.<br> >>=C2=A0 =C2=A0 =C2=A0If you have backups, you always have a way to u= ndo what has been done<br> >> in case anything goes wrong or doesn't work. /usr/src/UPDATING= is also<br> >> wise to read/follow for any -STABLE user in addition to the -STABL= E<br> >> mailing list. Nothing comes to mind of what to be aware of from it= <br> >> despite that I probably have done that same upgrade path on the ma= chine<br> >> I am typing this reply on though I migrated when each -STABLE bran= ch was<br> >> new rather than old. I have not yet upgraded to 14 though.<br> >>=C2=A0 =C2=A0 =C2=A0'Maybe' pkg switched through pkgng with= in this timeframe; it has a<br> >> database conversion process that you can go through though I think= it<br> >> leaves behind the old data layout for you to manually dispose of. = Could<br> >> also just uninstall 'all' packages then reinstall/replace = with what is<br> >> now available once upgraded. Handbook at least used to talk of thi= s<br> >> conversion which I 'think' was a thing around v9 or so. To= ols can output<br> >> a list of installed packages including pkgng's `pkg prime-list= ` command<br> >> which can then help reinstall after a bulk removal and portmaster = has a<br> >> documented set of steps which can aid in that too.<br> >><br> >> And for a brief command summary and/or comments I'd use for so= urce<br> >> upgrades (over and over and...modify as your system needs):<br> >><br> >> cd /usr/src<br> >> #if using etcupdate for the first time, you must use its preparati= on<br> >> step before updating the source tree; see other documentation.<br> >> #update the source tree using git, svn, or whatever tool...<br> >> #git switch releng/14.0<br> >> git switch stable/13<br> >> #remove vendor branches; at least one of the updates has requires = this<br> >> git remote prune origin<br> >> #update source tree with git<br> >> git pull --ff-only<br> >> #cleanup the build path; I had to perform this to even go from 13-= STABLE<br> >> to 14-STABLE and have the build not fail, possibly because I accel= erate<br> >> my updates by using things like 'WITH_META_MODE=3Dyes'<br> >> chflags -R noschg /usr/obj/usr;rm -rf /usr/obj/usr;cd /usr/src&= ;&make<br> >> cleandir&&make cleandir<br> >> #slower but more reliable build with a kernel install if successfu= l<br> >> make buildworld&&make buildkernel&&make installker= nel<br> >> #faster build, run in background, provide less output. This will h= ang if<br> >> PORTS_MODULES is used and a dialog comes up during any port build = as<br> >> jobs count is incompatible with PORTS_MODULES + `make comfig` dial= og boxes.<br> >> /usr/bin/nice -n 18 /usr/sbin/idprio 31 make -sj8 buildworld<br> >> buildkernel&&make installkernel<br> >> shutdown now<br> >> fsck -p<br> >> mount -u /<br> >> mount -a<br> >> sh /etc/rc.d/zfs start<br> >> cd /usr/src<br> >> #adjkerntz -i # if CMOS is not UTC<br> >> #mergemaster -iUFp #disabled as I use etcupdate now<br> >> etcupdate -p<br> >> cd /usr/src&&make installworld&&make delete-old&am= p;&etcupdate<br> >> shutdown -r now<br> >><br> >> #These steps should only need to be done at the end.<br> >> #update bootcode for ZFS on root; UEFI requires different steps. T= his<br> >> must be done before zpool/zfs changes for bootable root pools. If = the<br> >> partition is too small, this will fail; I stole swap space with<br= > >> deletes+recreates to work past that. This should be repeated for e= very<br> >> disk that could be asked upon to boot the system.<br> >> gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada1<br> >> #next up, upgrade/replace packages with up to date copies. I have = used<br> >> different ways of doing this over time such as manually uninstalli= ng<br> >> then running `make install clean` in a ports directory, simplified= with<br> >> portupgrade and I was never a big user of portmaster as I found fa= ilures<br> >> of one sort or another too common and it aborts midtask on those, = and<br> >> now currently use pkg form a custom built repository using poudrie= re.<br> >> #once packages are all updated one way or another<br> >> cd /usr/src;make delete-old-libs<br> >><br> > <br> > Thank you very much for the detailed procedure.<br> > By the look of things, this is quite involving and I believe requires = one<br> > to have the machine right next to them.<br> > I am not using ZFS at all.<br> > I was hoping there is a way to switch from STABLE to RELEASE and then = just<br> > use freebsd-update.<br> <br> =C2=A0 =C2=A0Don't see why you couldn't do one last source tree upd= ate to <br> 8.4-RELEASE (if doing the work, "I'd" go to 9.3-RELEASE with = this step <br> myself; doubt you really need to do 9.0 first), rebuild+reinstall so you <b= r> are now on a -RELEASE as freebsd-update would want to work from, then <br> proceed with its steps. Somewhere after 9 (or was it 10) there were <br> compiler changes that have /usr/src/UPDATING saying what steps to take <br> first (so at least that oneintermediate build would be needed).<br> =C2=A0 =C2=A0I thought steps would then be upgrade through each major next = major <br> version, which is safest to perform by reaching the #.0, then go to the <br= > latest #.# (9.0>9.4>10.0>10.4>11.0>11.4>...) but the #.0 = seems like a <br> useless step to me as it technically means you would be rolling between <br= > older and newer releases. If you cannot just do an upgrade by stating <br> the final desired version, even if multiple reboots & runs would be <br= > 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 = <br> elsewhere) as they have documented issues with upgrades that people need <b= r> to be aware of such as 12.4p6 and 13.2p3 having a fix for freebsd-update <b= r> corrupting files since moving to git.<br></blockquote><div><br></div><div>M= ight you have time to detail the steps for this?</div><div>=C2=A0</div></di= v><br clear=3D"all"><div><br></div><span class=3D"gmail_signature_prefix">-= - </span><br><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr"><d= iv dir=3D"ltr"><div>Best regards,<br>Odhiambo WASHINGTON,<br>Nairobi,KE<br>= +254 7 3200 0004/+254 7 2274 3223</div><div><span style=3D"color:rgb(34,34,= 34)">=C2=A0In=C2=A0</span><span style=3D"color:rgb(34,34,34)">an Internet f= ailure case, the #1 suspect is a constant: DNS.</span><br>"<span style= =3D"font-size:12.8px">Oh, the cruft.</span><span style=3D"font-size:12.8px"= >",=C2=A0</span><span style=3D"font-size:12.8px">egrep -v '^$|^.*#= '=C2=A0</span><span style=3D"background-color:rgb(34,34,34);color:rgb(2= 38,238,238);font-family:"Lucida Console",Consolas,"Courier N= ew",monospace;font-size:13.6px">=C2=AF\_(=E3=83=84)_/=C2=AF</span><spa= n style=3D"font-size:12.8px">=C2=A0:-)</span></div><div><span style=3D"font= -size:12.8px">[How to ask smart questions:=C2=A0</span><span style=3D"font-= size:12.8px"><a href=3D"http://www.catb.org/~esr/faqs/smart-questions.html"= target=3D"_blank">http://www.catb.org/~esr/faqs/smart-questions.html</a>]<= /span></div></div></div></div></div> --0000000000002d2074060fecdc42--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAAdA2WPocrL_gJ8Edt_Oj7NqfZteJv85xnC3a_nSyX6iHQr1FQ>