Date: Sat, 27 Jan 2024 14:00:51 +0300 From: Odhiambo Washington <odhiambo@gmail.com> To: questions@freebsd.org Subject: Re: Upgrade 8.4-STABLE to 14-STABLE Message-ID: <CAAdA2WOyv4G7dDn=0UiqdBr_oEXCDtDKbZrzPaLBkhkmNYHMMg@mail.gmail.com> In-Reply-To: <CO1PR11MB477085FF2A427126ED5A07C7E6782@CO1PR11MB4770.namprd11.prod.outlook.com> References: <CAAdA2WNLg19usv2ryO-s=EavDw%2BA1BQq_m_xUTu8RYCTVpbDzg@mail.gmail.com> <CO1PR11MB477085FF2A427126ED5A07C7E6782@CO1PR11MB4770.namprd11.prod.outlook.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <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 12:59=E2=80= =AFPM Edward Sanford Sutton, III <<a href=3D"mailto:mirror176@hotmail.co= m">mirror176@hotmail.com</a>> wrote:<br></div><blockquote class=3D"gmail= _quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204= ,204);padding-left:1ex">On 1/27/24 00:55, Odhiambo Washington wrote:<br> > Is there a way to upgrade 8.4-STABLE to 14-STABLE, or even change it t= o<br> > 14-RELEASE?<br> <br> =C2=A0 =C2=A0Hopefully others have better things to say or a more brief sum= mary, <br> but for now...<br> =C2=A0 =C2=A0"Maybe" other ways work but from a build+install sou= rce 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 became 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 source tree <b= r> as you start to use it. I do not recall what versions introduced or <br> required it but it is required when working from a git source repository <b= r> instead of cvs/svn.<br> =C2=A0 =C2=A0Binary packages require you start and end with a more formal r= elease <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 and <br> install the nearest -RELEASE version. If using a custom kernel then you <br= > would still be stuck building it from source but otherwise can use <br> binary updates for it too.<br> =C2=A0 =C2=A0Obviously as there would be many updates+reboots happening wit= h 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 updates to <b= r> FreeBSD + the modules are completed. For good measure, just shut down <br> unneeded software from startup, cron, etc. as the won't likely be API <= br> compatible until reinstalled or compatibility libraries are installed.<br> =C2=A0 =C2=A0Maybe it would be wise to consider 'replacing' the ins= tall instead of <br> binary updating if not for speed of its multiple steps alone. I presume <br= > such drastic action is the only single step process but would be <br> interested if others have suggestions otherwise.<br> =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 <br= > source installs or FreeBSD's update tool), you should make sure you tak= e <br> steps to upgrade the boot loader code before that operation is performed.<b= r> =C2=A0 =C2=A0If you have backups, you always have a way to undo what has be= en 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 -STABLE <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 machine <br= > I am typing this reply on though I migrated when each -STABLE branch was <b= r> new rather than old. I have not yet upgraded to 14 though.<br> =C2=A0 =C2=A0'Maybe' pkg switched through pkgng within this timefra= me; 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 this <br> conversion which I 'think' was a thing around v9 or so. Tools can o= utput <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 source <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 preparation <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 <b= r> to 14-STABLE and have the build not fail, possibly because I accelerate <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&&mak= e <br> cleandir&&make cleandir<br> #slower but more reliable build with a kernel install if successful<br> make buildworld&&make buildkernel&&make installkernel<br> #faster build, run in background, provide less output. This will hang if <b= r> PORTS_MODULES is used and a dialog comes up during any port build as <br> jobs count is incompatible with PORTS_MODULES + `make comfig` dialog 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&&et= cupdate<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. This <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 every <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 uninstalling <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 failures <b= r> 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 poudriere.<br> #once packages are all updated one way or another<br> cd /usr/src;make delete-old-libs<br></blockquote><div><br></div><div>Thank = you very much for the detailed procedure.</div><div>By the look of things, = this is quite involving and I believe requires one to have the machine righ= t next to them.</div><div>I am not using ZFS at all.</div><div>I was hoping= there is a way to switch from STABLE to RELEASE and then just use freebsd-= update.</div></div><br clear=3D"all"><div><br></div><span class=3D"gmail_si= gnature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><d= iv dir=3D"ltr"><div 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,3= 4)">an Internet failure 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">egre= p -v '^$|^.*#'=C2=A0</span><span style=3D"background-color:rgb(34,3= 4,34);color:rgb(238,238,238);font-family:"Lucida Console",Consola= s,"Courier New",monospace;font-size:13.6px">=C2=AF\_(=E3=83=84)_/= =C2=AF</span><span style=3D"font-size:12.8px">=C2=A0:-)</span></div><div><s= pan style=3D"font-size:12.8px">[How to ask smart questions:=C2=A0</span><sp= an style=3D"font-size:12.8px"><a href=3D"http://www.catb.org/~esr/faqs/smar= t-questions.html" target=3D"_blank">http://www.catb.org/~esr/faqs/smart-que= stions.html</a>]</span></div></div></div></div></div> --000000000000819ca0060feb5501--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAAdA2WOyv4G7dDn=0UiqdBr_oEXCDtDKbZrzPaLBkhkmNYHMMg>