Re: Recommended upgrade procedure to avoid drm-kmod panic on 15.1-RELEASE

On 6/17/26 19:10, Takashi Shimizu wrote:
> Thanks to Mark Millard's explanation of the -oOSVERSION mechanism, I was
> able to find a procedure that avoids the drm-kmod panic entirely,
> without disabling the GPU driver or rebuilding from ports.
> 
> The key step is, after the first 'freebsd-update install' (kernel
> update) but before rebooting, to explicitly upgrade the kmods packages
> using:
> 
>   pkg -oABI=FreeBSD:15:amd64 -oOSVERSION=1501000 update -r FreeBSD-
> ports-kmods
>   pkg -oABI=FreeBSD:15:amd64 -oOSVERSION=1501000 upgrade -r FreeBSD-
> ports-kmods
> 
> At this point 'uname -r' is still 15.0-RELEASE, so a plain 'pkg
> upgrade' (without -oOSVERSION) only sees 15.0 packages. With -oOSVERSION
> explicitly set to 1501000, pkg correctly fetches the 15.1 builds of
> drm-66-kmod and all related kmods (144 packages in my case, including
> virtualbox-ose-kmod-72).
> 
> After that, rebooting into the new 15.1 kernel works without any panic,
> since the kmod versions already match.
> 
> Full procedure:
> 
> 1. bectl create (save a BE)
> 2. freebsd-update upgrade -r 15.1-RELEASE
> 3. freebsd-update install (1st run, kernel)
> 4. pkg -oABI=FreeBSD:15:amd64 -oOSVERSION=1501000 upgrade -r FreeBSD-
> ports-kmods
> 5. reboot (no panic)
> 6. freebsd-update install (2nd run, userland)
> 7. reboot

[I remind that I do not normally use any kmods. So my notes are untested
and are based on more general background information.]

The above procedure does not cover making sure pkg itself is
sufficiently up to date first. Also you might want pkg-static to avoid
library dependencies possibly preventing pkg from running.

The above procedure did not check for the "pkg install" generating any
*.pkgsave files (copies of the original files that were
replaced/renamed). Any non-configuration files likely could just have
the matching *.pkgsave file deleted. Configuration files, if any, might
need merging first.

> 
> I tested this on my desktop (AMD GPU, amdgpu) and it worked as expected.
> 

Note that the above steps are a mix of mostly freebsd-update use and
style of update with a pkgbase step of a selective update.

It may be that freebsd-update would then refuse to run after the pkgbase
having port packages registered. You may need to add a step to
unregistier the pkgbase information about the FreeBSD-ports-kmods based
installs or some such. At the moment I'm not going to suggest a specific
command syntax to unregsiter just the installed kmods so that pkgbase
ends up no longer in use.

But un-registering also likely makes a later "pkg upgrade" or "pkg
install" with "-r FreeBSD-ports-kmods" do extra things like generate
*.pkgnew files or *.pkgsave files. You would probably want to "pkg
install" and then later delete the *.pkgsave files that would generate
)(copies of the older files that were being replaced). It is not a
command that takes "-r REPONAME" options.

One would not want the normal port-packages unregistered, just the base
packages for this odd, mixed installation sequence.

> This seems like exactly what FreeBSD-ports-kmods was designed for,

Not really: mixing pkgbase and freebsd-update installs was likely never
intended or tested.

In essence, this whole technique is a work around for freebsd-update not
providing its own kmod materials covered by its own steps.

> but
> the -oOSVERSION step is not something I would have discovered without
> this thread. Would it make sense to document this procedure somewhere -
> perhaps in the upgrading guide or as a note next to the existing
> rebuild-from-ports warning - for desktop users running GPU drivers or
> virtualbox-ose-kmod from packages?

I'll note that there are pkgbase installation instructions that have
examples using the "-oABI=FreeBSD:15:amd64" and "-oOSVERSION=1501000"
options. But there is no mention of explicitly running pkg update for
FreeBSD-ports-kmods . Nor would unregistering such a group of pkgbase
installations be appropriate. See:

https://www.freebsd.org/releases/15.1R/upgrading/

and its text for "Upgrading with Base System Packages"

> 
> Thanks again to Mark and vermaden for the help.
> 
> 
> One more question on this topic.
> 
> For users on the pkgbase method (FreeBSD-base repository), is the
> FreeBSD-ports-kmods package automatically installed/upgraded as part of
> the base system upgrade, or does it still require a separate, explicit
> step, similar to what I experienced with freebsd-update?

https://www.freebsd.org/releases/15.1R/upgrading/ documents using:

# pkg upgrade -r FreeBSD-ports-kmods

but I do not know if the procedure always works as written.

The directions definitely do not deal with the quarterly vs. latest
distinction for pkgbase versions relative to "2. Upgrade the Package
Manager", as quarterly need not be recent enough. (Its existing 2.6.2
may not be recent enough compared to to 2.7.5 that is in latest for the
specific upgrade instructions, given that -r REPONAME was
fixed/finally-implemented in 2.7.4, well after 2.6.2 --as a potential
example.)

The instructions also do not split the update into a kernel-stage then a
later world-stage with a reboot between. Nothing in the kernel/world
design has removed the reasons for having such staging as sometimes
required as far as I know. But the procedure documented for pkgbase has
only 1 reboot at the very end, which is also after updating the FreeBSD
efi boot loader installation (for example).

However, minor *.*-RELEASE upgrades may far more rarely actually need
the extra reboot compared to, say main or stable/* upgrades.

By contrast upgrades from 15 to 16 would be more unlikely to allow the
16 world to run under the original 15 kernel.

> 
> I write articles in Japanese introducing FreeBSD to general audiences,
> and I am considering what to recommend to readers regarding this issue.
> If pkgbase handles this automatically and avoids the panic I
> encountered, I would like to recommend that readers consider migrating
> to pkgbase, so they do not run into the same problem.
> 
> Thank you.
> 
> Best regards
> 
> Takashi Shimizu
> 
> 

Another note:

https://www.freebsd.org/releases/15.1R/upgrading/ claims:

"Systems running 14.4-RELEASE or . . . can be upgraded as follows . . ."
for pkgbase. But "3. Upgrade the Base System" leads to running some
15.1-RELEASE world programs on a 14.4-RELEASE kernel until after the
later reboot. I also means that the live system is running a mix of
14.4-RELEASE programs and 15.1-RELEASE programs --such also need not
always be compatible when they interact. That is not supported and is
considered lucky if none of the 15.1-RELEASE programs fail before the
reboot.

Note: running 14.4-RELEASE programs under 15.*-RELEASE kernel is
generally supposed to work --but not 15.*-RELEASE programs on
14.4-RELEASE kernels. That is part of the reason for the historical
kernel, reboot, world, reboot sequencing.


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