pkgbasify and pkg, pkgbase installs/upgrades where kernel functionality has changed/grown: not fully handled

I recently did a pkgbasify to get to 14.4-STABLE from notably older
media by content --but from after 14.0 was branched.

pkgbasify installed things and then tried to do various activities based
on the new world it had installed. One of those operations failed and
stopped the progress because the new code it was using happened to try
to use kernel facilities that were newer than the old, booted kernel
supported.

Such issues are why the historical standard procedures have one install
a kernel to use (and any other updates to have it boot if needed) and
then reboot so that such a new kernel is operational --all before
installing the new world to match.

pkg itself has the same installation and partial use of the new world on
the old kernel for how it operates.


So updating to have in place and then booting based on a new kernel (and
such) from (using modern naming terms):

-rFreeBSD-base \
-g FreeBSD-bootloader FreeBSD-kernel-generic\* FreeBSD-dtb

can be a relevant procedure before a more general upgrade of the rest.
(I do not list the FreeBSD-set-kernels because pkg does not to the
dependency analysis on the kernels in the set to cause upgrades to
always happen.)

Note:
FreeBSD-dtb is platform specific for if it is potentially involved at
all. FreeBSD-bootloader usually does not require an update, even if one
is available. One might want FreeBSD-src-sys as reference material as well.


I'm not aware of documented pkg usage procedures for pkgbase dealing
with this type of dependency issue. pkgbasify simply does not use such a
procedure.


In my context, simply rebooting into one of the new kernels was enough
to allow a forced rerun of pkgbasify to complete.

-- 
===
Mark Millard
marklmi at yahoo.com