Hi. > PkgBase does not remove the issue that updating > the kernel first, rebooting, and then updating the > world can be a requirement. > (World should get a later reboot as well.)
Not related to PKGBASE - but as you will be doing a reboot after the update/upgrade anyway - its safer and easier to do the upgrade inside separate ZFS Boot Environment - as running kernel does not 'conflict' with the one installed/upgraded inside the ZFS BE. So you do all the possible steps needed - upgrading base - upgrading packages ... Details: https://vermaden.wordpress.com/2021/02/23/upgrade-freebsd-with-zfs-boot-environments/ Another good aspect of doing it this way is limiting downtime to just a reboot time - because while you were doing the upgrade - the 'host' system still works untouched - then after you are done - you reboot into upgraded ZFS BE and check if everything works - and if not you just reboot again into the ZFS BE that worked perfectly before the upgrade and have 'endless' time to figure out what the issue with the upgrade was. Hope that helps. Regards, vermaden Temat: Re: PKGBASE Removes FreeBSD Base System Feature Data: 2025-08-04 16:52 Nadawca: "Mark Millard" <mark...@yahoo.com> Adresat: "David Chisnall" <thera...@freebsd.org>; DW: "Miroslav Lachman" <000.f...@quip.cz>; "vermaden" <verma...@interia.pl>; "Shawn Webb" <shawn.w...@hardenedbsd.org>; "freebsd-pkgb...@freebsd.org" <freebsd-pkgb...@freebsd.org>; "freebsd-sta...@freebsd.org" <freebsd-sta...@freebsd.org>; "freebsd-...@freebsd.org" <freebsd-...@freebsd.org>; "freebsd-curr...@freebsd.org" <freebsd-curr...@freebsd.org>; p...@nomadlogic.org; b...@freebsd.org; b...@pmf.uns.ac.rs; > >> > > On Aug 1, 2025, at 07:22, David Chisnall wrote: > >> On 31 Jul 2025, at 02:57, Miroslav Lachman <000.f...@quip.cz> wrote: >>> >>> I would also like to separate it. Use one command to update (upgrade) 3rd party packages and another to update (upgrade) base packages. It is our workflow for the last 25+ years thus running one command to update both is really unexpected and unwanted. >> >> I disagree here. If you *want* to separate them, then you can: you can specify the repository that you want to upgrade explicitly. But if you do then you risk things like: >> >> - I’ve upgraded my base system, but not my ports-kmods things, so now my GUI doesn’t start. > > PkgBase does not remove the issue that updating the kernel > first, rebooting, and then updating the world can be a > requirement. (World should get a later reboot as well.) > > Last I knew PkgBase did not manage this sequence of itself, > even for when kmods are not involved. I selectively update > the kernels first and reboot before updating teh other > PkgBase packages. (The plural 'kernels' is because I'm > using main and have all the PkgBase kernels installed. > One can not do that for non-main for contexts with .dtb > files involved: conflicts.) > > Is it always safe to update all the ports-kmods before the > world is updated so they are in place for the after-kernel > reboot with the old world? > > If not, then PkgBase is not of itself a way of making the > handling automatic as far as I can tell. > >> - I’ve upgraded ports, but the ports tree is built on a newer point release and I need to upgrade to make some symbols exist. >> - I’ve upgraded the base system and now some kmods from ports don’t work. >> >> All of these are things that users have complained about publicly in the last year or so. >> >> I have avoided them by always doing `freebsd-update install && pkg upgrade` and keeping that in my shell history[1] so I don’t accidentally forget to upgrade both together. >> >> Given a choice between a thing that works for users, or something that *can* work for users but comes with a bunch of footguns that they need to avoid, I’d pick the former. >> >> David >> >> [1] I’ve noticed on fresh installs, the default shell no longer has working persistent history, which is a *big* POLA violation, if people want to complain about something. >> > > > === > Mark Millard > marklmi at yahoo.com > > >
