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

On 6/17/26 01:43, Takashi Shimizu wrote:
> Following up on this thread with some experimental results.
> 
> I tried to see if it was possible to install the 15.1 version of drm-66-
> kmod before the first reboot, to avoid the panic entirely.

What version of pkg are you using?

) Unfortunately quartertly is at 2.6.2 which predates important changes

) Latest is as 2.7.5 that has important changes, some from 2.7.4 and
some from 2.7.5 itself.

If you are using pkg before 2.7.4 then the enabling and disabling of
repositories needs to be done in the files instead of via -r REPONAME use.

> Here is what
> I found:
> 
> 1. After 'freebsd-update install' (first run, kernel update), 'freebsd-
> version' still reports 15.0-RELEASE-p9, even though the new kernel is
> already installed on disk.
> 
> 2. The FreeBSD-ports-kmods repository URL uses ${VERSION_MINOR}, which
> still resolves to 0 at this point:
> 
>   url: "pkg+https://pkg.FreeBSD.org/FreeBSD:15:amd64/kmods_quarterly_0"
> 
> 3. I tried 'export VERSION_MINOR=1' before running pkg, but this had no
> effect - pkg still resolved the URL using kmods_quarterly_0, and 'pkg
> search -r FreeBSD-ports-kmods drm-66-kmod' only returned the 15.0 build.
> 
> So it appears VERSION_MINOR is computed internally by pkg (likely via
> its own ABI detection) rather than read from the environment, and it
> does not change until after reboot into the new kernel.

In the notation:

# pkg -oABI=FreeBSD:15:$(uname -p) -oOSVERSION=1501000

It is the OSVERSION that specifies 15.1, causing VERSION_MINOR to be 1.
My understanding is that the last 2 digits are basically ignore by pkg
but are part of what defines OSVERSION. stable/15 is -oOSVERSION=1501501
currently. That 2nd "5" is what indicates STABLE as the context. (Stable
does not have/use VERSION_MINOR for pkg.)

My understanding is that the next pkg release will support the likes of:

# pkg -oABI=FreeBSD:15:$(uname -p) -oVERSION_MINOR=1

as an alternative that better matches the notations seen in the file and
that require less knowledge of other OSVERSION encoding details.

For minor upgrades with the same major version, the ABI part likely is
not needed, but for a major upgrade, such as to FreeBSD:16:$(uname -p)
from FreeBSD:15:$(uname -p) , ABI would be required.

(I ignore here the likes of targeting armv7 world code on a aarch64
system that can handle armv7 world code.)

With the ${VERSION_MINOR} still in place in the file, you can see what
repository url's are used via the use of the likes of:

# pkg -oABI=FreeBSD:15:$(uname -p) -oOSVERSION=1501000 repos

The output shows the number used after the $(VERSION_MINOR}
substitution. Below, I will presume $(VERSION_MINOR} notation is in use
in the file. Note, repos is short for: repositories


My normal context is main or stable/15 so in the below I've invented
repository names to reference release repositories. You would not have
the "-release" suffixes.

# pkg -oABI=FreeBSD:15:$(uname -p) -oOSVERSION=1501000 \
      update -rFreeBSD-ports-kmods-release
Updating FreeBSD-ports-kmods-release repository catalogue...
Fetching meta.conf: 100%     179 B   0.2 kB/s    00:01
Fetching data: 100%    35 KiB  36.0 kB/s    00:01
Processing entries: 100%
FreeBSD-ports-kmods-release repository update completed. 240 packages
processed.
FreeBSD-ports-kmods-release is up to date.

NOTE: I had to do that explicit pkg . . . update . . . , it did not get
an implicit update when I first attempted the below sort of command.
After the above the following worked instead of producing an empty list):

# pkg -oABI=FreeBSD:15:$(uname -p) -oOSVERSION=1501000 \
       rquery -a -rFreeBSD-ports-kmods-release %n-%v
acerhdf-kmod-0.1.4.1501000_1
acpi_call-1.0.1.1501000_2
amnezia-kmod-2.0.11.1501000
aquantia-atlantic-kmod-0.0.5.1501000_3
biosfont-1.3.1.1501000
devctl-jail-kmod-g20190521.1501000
drm-515-kmod-5.15.160.1501000_9
drm-61-kmod-6.1.128.1501000_9
drm-66-kmod-6.6.25.1501000_9
drm-latest-kmod-6.9.1501000_1
gpu-firmware-amd-kmod-aldebaran-20250109.1501000
gpu-firmware-amd-kmod-arcturus-20250109.1501000
gpu-firmware-amd-kmod-banks-20250109.1501000
. . .
gpu-firmware-radeon-kmod-turks-20220511.1501000
gpu-firmware-radeon-kmod-verde-20220511.1501000
hammer2-1.2.13.1501000
intel-ixv-kmod-1.5.34.1501000_2
isboot-kmod-0.2.15.1501000
isboot-kmod-devel-0.2.16.b1.1501000
linux_dvbwrapper-kmod-1.0.1501000_2
mac_nonet-kmod-g20150821.1501000
mac_rtprio-kmod-g20170417.1501000
mbgtools-f.1.0.0.1501000_1
nbd-client-kmod-g20251201.1501000
ndproxy-3.3.1501000
ng_ipacct-20210316.1501000_2
ng_mikrotik_eoip-1.0.1501000
nvidia-kmod-595.71.05.1501000
open-vm-kmod-13.0.10.1501000,2
opencbm-kmod-0.4.99.104.1501000_2
openzfs-kmod-2.4.2.1501000,1
plasma-kmod-0.1.1501000_4
ptx-kmod-0.0.20111212.1501000_2
pwcbsd-1.4.1.1501000_15
quantis-kmod-v18.03.08.1501000
realtek-re-kmod-1101.00.1501000
realtek-re-kmod198-198.00.1501000
realtek-rge-kmod-20260222.1501000
sysctlbyname-improved-kmod-20221211.1501000
sysctlinfo-kmod-20221211.1501000_1
tcpstats-kmod-1.0.4.1501000
twa-kmod-20230821.1501000
uarduno-1.02.1501000_1
utouch-kmod-0.0.5.1501000
virtualbox-ose-kmod-6.1.50.1501000_1
virtualbox-ose-kmod-70-7.0.26.1501000
virtualbox-ose-kmod-71-7.1.18.1501000
virtualbox-ose-kmod-72-7.2.8.1501000
virtualbox-ose-kmod-legacy-5.2.44.1501000_7
wifi-firmware-ath10k-kmod-20251125
wifi-firmware-ath10k-kmod-qca4019_hw10-20251125
. . .
wifi-firmware-rtw89-kmod-rtw8852b-20251125
wifi-firmware-rtw89-kmod-rtw8852bt-20251125
wifi-firmware-rtw89-kmod-rtw8852c-20251125
wifi-firmware-rtw89-kmod-rtw8922a-20251125

# pkg -oABI=FreeBSD:15:$(uname -p) -oOSVERSION=1501000 \
      rquery -a -rFreeBSD-ports-kmods-release %n-%v \
| wc -l
     240

Thus one can see what all is available at what version. Some of the
versions encode dates. The example context was: amd64.

If you get to the point of seeing what is available, other activities
using the repository should work --but I've no clue if the versions
present are actually appropriate.

Note: I do not normally use any kmods.

> 
> This suggests there is currently no way to pre-stage the matching 15.1
> kmod package before the reboot that activates the new kernel - the
> panic-prone window between 'reboot into new kernel' and 'pkg upgrade
> drm-66-kmod' seems unavoidable with the current tooling.
> 
> Is my understanding correct, or is there a way to override the ABI/
> VERSION_MINOR detection that I am missing? If this is indeed a gap,
> would it be reasonable to suggest that freebsd-update or the upgrading
> instructions recommend disabling the affected kld_list entries and
> display manager before the first reboot, for systems with GPU kmods
> installed from packages?
> 
> Thank you again for your time.
> 
> Best regards
> 
> Takashi Shimizu
> 
> 


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