From Newsgroup: muc.lists.freebsd.stable

Dear freebsd-stable,

I recently upgraded my desktop system from 15.0-RELEASE to 15.1-RELEASE
using freebsd-update(8), and encountered a kernel panic on the first
reboot after the first 'freebsd-update install'.

The panic was caused by drm-66-kmod, which was installed from a binary
package built against the 15.0 kernel. After the kernel was updated to
15.1, the module could no longer be loaded.

I was able to recover by following these steps:

1. Booted into the previous Boot Environment created before the upgrade.
2. Commented out kld_list and the display manager entry in /etc/rc.conf
to boot into console mode.
3. Rebooted.
4. Ran 'freebsd-update install' for the second time to update userland.
5. Removed drm-66-kmod installed from pkg, then rebuilt and installed it
from ports (graphics/drm-66-kmod).
6. Restored /etc/rc.conf and rebooted successfully.

I also found that all kernel modules listed by 'pkg info | grep kmod'
require rebuilding from ports after a point release upgrade. In my case, emulators/virtualbox-ose-kmod was also affected.

This procedure worked for me, but it requires knowledge of Boot
Environments, ports, and manual kernel module management. I am not sure
this is something a less experienced FreeBSD user could handle without difficulty.

Is there a simpler or more beginner-friendly procedure recommended for upgrading between point releases when drm-kmod or other kernel modules
are installed from packages?

Thank you for your time.

Best regards

Takashi Shimizu



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

Is there a simpler or more beginner-friendly procedure recommended
for upgrading between point releases when drm-kmod or other kernel
modules are installed from packages?

Thank you for your time.
Best regards
Takashi Shimizu

As FreeBSD project treats 15.0 and 15.1 the same the solution is to
use GhostBSD as 'backend' for your FreeBSD desktop because
GhostBSD ALWAYS builds its packages - including kernel related
ones against the FreeBSD version they use - no no such problems.

I mean - install default MATE GhostBSD and then setup your
FreeBSD desktop any way you want with dwm or Openbox or KDE.

You can also use GhostBSD repos on FreeBSD but its risky:
- https://vermaden.wordpress.com/2025/02/13/ghostbsd-pkg-repository-on-freebsd/

FreeBSD - to not build separate packages for 15.0 and 15.1 and 15.2
introduced additional 'FreeBSD-ports-kmods' pkg(8)repository - where
all kernel related (about 60+ of them) packages are rebuilt against
proper 15.1 or 15.0 version - but if someone forgets to update them
along with kernel upgrade - sometimes kernel panic as in Your case
happens.

Hope that helps.

Regards,
vermaden


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

Thank you, Mark.

That is very helpful. So packages for 15.1 were already being built in FreeBSD-ports-kmods well before the RELEASE, during the RC stage.

I will check the current state with 'pkg info -r FreeBSD-ports-kmods drm-66-kmod' and try the upgrade again, this time updating drm-66-kmod
via FreeBSD-ports-kmods before running freebsd-update upgrade.

I will report back with the result.

Best regards

Takashi Shimizu


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

This is a multi-part message in MIME format. --------------0ks4wjFuQtvYZuhveYc7gbYY
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit


On 6/17/26 02:40, Mark Millard wrote:

https://people.freebsd.org/~dbaio/pkg-master-report.html indicates
that the most recent kmods_* updates are from 2026-May-21 (and 20).

The situation that the KMOD repositor is being upgraded asyncronusly from the base and the ports
repositories is responsible for many support calls on the freebsd forums and other community platforms such as discord.

Typical scenario :

Nvidia releases updated driver. which updates the ports repository.
Old version Nvidia KMOD persists in KMOD repo for weeks, months......
This means a binary update is not possible.

Only solution is to build driver+Kmod packages locally using the /usr/ports and make install on your own computer.

similar situations with AMDGPU and intel915 GPU and associated DRM version.

the KMOD part of a GPU card driver update is so often lagging in availability time that it has
become one of the major issues with installing a graphical desktop environment.


*_When a PORT package is updated that requier its corresponding KMOD to
be updated this has to happend in sync. _*
this should be an administrative issue that is solvable with proper action plan for updating the repos.
--
-------------------------
Lars Tunkrans
Oracle SPARC/Solaris System Administrator
Fujitsu M12 SPARC Specilaist

--------------0ks4wjFuQtvYZuhveYc7gbYY
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 6/17/26 02:40, Mark Millard wrote:</div>
<blockquote type="cite"
cite="mid:7512bec3-ea40-4929-90f9-e16896a12c86@yahoo.com">
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre"><a class="moz-txt-link-freetext" href="https://people.freebsd.org/~dbaio/pkg-master-report.html">https://people.freebsd.org/~dbaio/pkg-master-report.html</a> indicates
that the most recent kmods_* updates are from 2026-May-21 (and 20).


</pre>
</blockquote>
</blockquote>
<pre class="moz-signature" cols="72">
The situation that the KMOD repositor is being upgraded asyncronusly from the base and the ports
repositories is responsible for many support calls on the freebsd forums and other community platforms such as discord.

Typical scenario :

Nvidia releases updated driver. which updates the ports repository.
Old version Nvidia KMOD persists in KMOD repo for weeks, months......
This means a binary update is not possible.

Only solution is to build driver+Kmod packages locally using the /usr/ports and make install on your own computer.

similar situations with AMDGPU and intel915 GPU and associated DRM version.

the KMOD part of a GPU card driver update is so often lagging in availability time that it has
become one of the major issues with installing a graphical desktop environment.


<b><u>When a PORT package is updated that requier its corresponding KMOD to be updated this has to happend in sync.
</u></b>
this should be an administrative issue that is solvable with proper action plan for updating the repos.


--
-------------------------
Lars Tunkrans
Oracle SPARC/Solaris System Administrator
Fujitsu M12 SPARC Specilaist</pre>
</body>
</html>

--------------0ks4wjFuQtvYZuhveYc7gbYY--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

Thank you for the kind and thoughtful advice.

You make a fair point about the definition of "successfully" - I had
only confirmed that the immediate upgrade completed without a panic, not
that the system would behave normally with freebsd-update going forward.
I will keep an eye on this and report back if I run into any issues with future freebsd-update runs.

I appreciate you confirming that avoiding the freebsd-update/pkgbase mix
is the right approach for now. I will continue to treat the -oOSVERSION workaround as exactly that - a workaround, not a documented or fully
supported procedure - when I write about this.

Given everything discussed in this thread, it seems that for
freebsd-update users, the safest approach at this point is the
traditional one: disable the affected kld_list entries and display
manager, complete the upgrade, then rebuild the kmods from ports. This
avoids mixing freebsd-update with any pkgbase-style repository selection.

That said, I have to say this is not a comfortable situation for less experienced desktop users. Disabling drivers, rebuilding from ports, and understanding the distinction between freebsd-update and pkgbase are all things that require a fair amount of FreeBSD-specific knowledge. I hope
this can be improved over time, whether through better documentation or through pkgbase eventually handling kmods transparently once it matures.

Thank you again for your time and detailed explanations throughout this thread.

Best regards

Takashi Shimizu



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2