From Newsgroup: muc.lists.freebsd.ports


I am using nvidia packages as an example, because I personally have been affected, but the problem can be more general.

Splitting nvidia-driver into the kernel and userland pieces was the right thing
from the perspective that the kernel driver is obvious coupled with kernel version.

But it seems that nvidia userland and kernel module are also coupled with each other.

Main package repo-s and kmod repo-s are updated at independent cadences.
Also, there can be build failures that can introduce further unpredictability into package update cycles.
So, it can happen and has happened recently that nvidia packages got updated in
one place but remained at an older version in the other.

I overlooked that when doing a package upgrade and ended up with a newer kernel
module and older userland. nvidia didn't like that at all and Xorg could not start properly (it did start but all I saw was a black screen and cursor). Also, there were these messages in the log:
kernel: NVRM: API mismatch: the client 'Xorg' (pid 3447)
kernel: NVRM: has the version 580.95.05, but this kernel module has
kernel: NVRM: the version 580.105.08. Please make sure that this
kernel: NVRM: kernel module and all NVIDIA driver components
kernel: NVRM: have the same version.

It's impossible to prevent such a mismatch across different repositories.
So, maybe, it would be possible to prevent it at upgrade / installation time? E.g., maybe there could be some stricter version dependency between nvidia-driver and nvidia-kmod such that pkg would refuse to upgrade nvidia-kmod
if a newer nvidia-driver is not available (and vice versa?).

As I said in the beginning, there could be other instances of such userland-kernel coupling.
--
Andriy Gapon



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

From Newsgroup: muc.lists.freebsd.ports

On Wed, Nov 12, 2025 at 03:28:28PM +0200, Andriy Gapon wrote:

I am using nvidia packages as an example, because I personally have
been affected, but the problem can be more general.

Splitting nvidia-driver into the kernel and userland pieces was the
right thing from the perspective that the kernel driver is obvious
coupled with kernel version.

But it seems that nvidia userland and kernel module are also coupled
with each other.

Main package repo-s and kmod repo-s are updated at independent cadences. >Also, there can be build failures that can introduce further >unpredictability into package update cycles.
So, it can happen and has happened recently that nvidia packages got
updated in one place but remained at an older version in the other.

Yikes! :(

I don't use repos/pkgs, and build everything from source.
Although everything in a port gets built into a pkg before it
installs.

On a desktop, the x11/nvidia-driver-470 port gets rebuilt and
reinstalled every time the kernel gets rebuilt and reinstalled.
It does this because of a PORTS_MODULES+= line
in /etc/src.conf containing x11/nvidia-driver-470

Will this still take care of everything required or is
"userland" something else, does it need to build something else
in addition to make sure userland and the kmod don't go out of sync
like you describe?
--



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

From Newsgroup: muc.lists.freebsd.ports

On Wed, 12 Nov 2025 21:09:50 +0000
void <void@f-m.fm> wrote:

On Wed, Nov 12, 2025 at 03:28:28PM +0200, Andriy Gapon wrote:

I am using nvidia packages as an example, because I personally have
been affected, but the problem can be more general.

Splitting nvidia-driver into the kernel and userland pieces was the
right thing from the perspective that the kernel driver is obvious
coupled with kernel version.

But it seems that nvidia userland and kernel module are also coupled
with each other.

Correct.
Just like the version of x11/inux-nvidia-libs* (if installed) must be
in sync with x11/nvidia-driver*.

Main package repo-s and kmod repo-s are updated at independent cadences. >Also, there can be build failures that can introduce further >unpredictability into package update cycles.
So, it can happen and has happened recently that nvidia packages got >updated in one place but remained at an older version in the other.

Hope this is an extraordinary situation in preparation of new
*.0-Release. I'm not using official pkg repos, but IIRC, nvidia
driver things on main repo are usually built quickly after commits.

Yikes! :(

I don't use repos/pkgs, and build everything from source.
Although everything in a port gets built into a pkg before it
installs.

On a desktop, the x11/nvidia-driver-470 port gets rebuilt and
reinstalled every time the kernel gets rebuilt and reinstalled.
It does this because of a PORTS_MODULES+= line
in /etc/src.conf containing x11/nvidia-driver-470

Will this still take care of everything required or is
"userland" something else, does it need to build something else
in addition to make sure userland and the kmod don't go out of sync
like you describe?

Not sure it works or not (I'm not using PORTS_MODULES), but possibly
abusing PORTS_MODULES for x11/nvidia-driver* help, if related codes
does NOT checking if the specified ports are actually kmod ones or not.

--

--
Tomoaki AOKI <junchoon@dec.sakura.ne.jp>


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

From Newsgroup: muc.lists.freebsd.ports

On 13/11/2025 01:17, Tomoaki AOKI wrote:

On Wed, Nov 12, 2025 at 03:28:28PM +0200, Andriy Gapon wrote:

Main package repo-s and kmod repo-s are updated at independent cadences. >>> Also, there can be build failures that can introduce further
unpredictability into package update cycles.
So, it can happen and has happened recently that nvidia packages got
updated in one place but remained at an older version in the other.

Hope this is an extraordinary situation in preparation of new
*.0-Release. I'm not using official pkg repos, but IIRC, nvidia
driver things on main repo are usually built quickly after commits.

There is nothing extraordinary about this situation, it's a natural consequence
of packages being in different repositories which are built independently.
It's bound to happen again.
So, it's better to prevent the desynchronization by means of pkg(8).
--
Andriy Gapon


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

From Newsgroup: muc.lists.freebsd.ports

On 13/11/2025 08:31, Andriy Gapon wrote:

On 13/11/2025 01:17, Tomoaki AOKI wrote:

On Wed, Nov 12, 2025 at 03:28:28PM +0200, Andriy Gapon wrote:

Main package repo-s and kmod repo-s are updated at independent cadences. >>> Also, there can be build failures that can introduce further
unpredictability into package update cycles.
So, it can happen and has happened recently that nvidia packages got
updated in one place but remained at an older version in the other.

Hope this is an extraordinary situation in preparation of new
*.0-Release. I'm not using official pkg repos, but IIRC, nvidia
driver things on main repo are usually built quickly after commits.

There is nothing extraordinary about this situation, it's a natural consequence
of packages being in different repositories which are built independently. It's bound to happen again.
So, it's better to prevent the desynchronization by means of pkg(8).

When there are two supported minor releases of the same branch,
you could find yourself in a no-man's-land scenario where
*no workable set of packages* is available.
For example, say that we are in the three-month overlap period of
14.3-RELEASE and 14.4-RELEASE and the Nvidia driver _packages_
are in the process of transitioning from version:
580.95.05
to
580.105.08
On 14.3-RELEASE and 14.4-RELEASE respectively we have the following
packages available.
On 14.3-RELEASE:
[0-0] # freebsd-version -r
14.3-RELEASE-p5
[1-0] # pkg rquery -x '[%R] %o %n %v' '^drm-(61-)?kmod|(^nvidia-)' | \
egrep -v 'nvidia-(driver|kmod|drm-515)-...|-devel|-settings|-xconfig|-tools' | \
column -t
[FreeBSD] graphics/drm-61-kmod drm-61-kmod
6.1.128.1403000_7
[FreeBSD] graphics/drm-kmod drm-kmod 20250428 [FreeBSD] x11/nvidia-driver nvidia-driver
580.95.05 <-- usable
[FreeBSD] graphics/nvidia-drm-61-kmod nvidia-drm-61-kmod 580.95.05.1403000
[FreeBSD] graphics/nvidia-drm-kmod nvidia-drm-kmod 580.95.05 [FreeBSD] x11/nvidia-kmod nvidia-kmod
580.95.05.1403000 <-- usable
[FreeBSD-kmods] graphics/drm-61-kmod drm-61-kmod
6.1.128.1403000_7
[FreeBSD-kmods] x11/nvidia-kmod nvidia-kmod
580.105.08.1403000 <-- NOT usable
On 14.4-RELEASE:
[0-0] # freebsd-version -r
14.4-RELEASE
[1-0] # pkg rquery -x '[%R] %o %n %v' '^drm-(61-)?kmod|(^nvidia-)' | \
egrep -v 'nvidia-(driver|kmod|drm-515)-...|-devel|-settings|-xconfig|-tools' | \
column -t
[FreeBSD] graphics/drm-61-kmod drm-61-kmod
6.1.128.1403000_7
[FreeBSD] graphics/drm-kmod drm-kmod 20250428 [FreeBSD] x11/nvidia-driver nvidia-driver
580.95.05 <-- NOT usable
[FreeBSD] graphics/nvidia-drm-61-kmod nvidia-drm-61-kmod 580.95.05.1403000
[FreeBSD] graphics/nvidia-drm-kmod nvidia-drm-kmod 580.95.05 [FreeBSD] x11/nvidia-kmod nvidia-kmod
580.95.05.1403000 <-- NOT usable
[FreeBSD-kmods] graphics/drm-61-kmod drm-61-kmod
6.1.128.1404000_7
[FreeBSD-kmods] x11/nvidia-kmod nvidia-kmod
580.105.08.1404000 <-- NOT usable
"NOT usable" here means that the package cannot be used as a
part of an aligned combination, given the available packages.
For 14.4-RELEASE we should have rCoas a working set of packagesrCoeither: [FreeBSD] x11/nvidia-driver nvidia-driver 580.95.05 [FreeBSD-kmods] x11/nvidia-kmod nvidia-kmod
580.95.05.1404000
or
[FreeBSD] x11/nvidia-driver nvidia-driver 580.105.08 [FreeBSD-kmods] x11/nvidia-kmod nvidia-kmod
580.105.08.1404000
Therefore, an aligned, working combination of nvidia-driver and
nvidia-kmod cannot be installed from the remote repositories
because neither combination is available. This will also affect
pkg upgrade actions.
Eric
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2