Solved Locking nvidia driver against upgrades.

C

Cedric62

Well, below is the information I found for the nvidia driver in my machine.
Code: 
nvidia-driver-580.119.02_1     NVidia graphics card binary drivers for hardware OpenGL rendering
nvidia-drm-66-kmod-580.119.02.1500068_2 NVIDIA DRM Kernel Module
nvidia-drm-kmod-580.119.02     NVIDIA DRM Kernel Module
nvidia-kmod-580.119.02.1500068_1 kmod part of NVidia graphics card binary drivers for hardware OpenGL rendering
nvidia-settings-580.119.02     Display Control Panel for X NVidia driver
nvidia-xconfig-580.119.02      Tool to manipulate X configuration files for the NVidia driver

Also, below are the commands which I issued in an attempt to protect my nvidia driver against upgrades.

Code: 
pkg lock nvidia-driver-580.119.02_1
Locking nvidia-driver-580.119.02_1

root@Asus:~ # pkg lock nvidia-drm-66-kmod
nvidia-drm-66-kmod-580.119.02.1500068_2: lock this package? [y/N]: y
Locking nvidia-drm-66-kmod-580.119.02.1500068_2


root@Asus:~ # pkg lock -y nvidia-settings
Locking nvidia-settings-580.119.02

root@Asus:~ # pkg lock -y nvidia-xconfig
Locking nvidia-xconfig-580.119.02

root@Asus:~ # pkg lock -l
Currently locked packages:
nvidia-driver-580.119.02_1
nvidia-drm-66-kmod-580.119.02.1500068_2
nvidia-settings-580.119.02
nvidia-xconfig-580.119.02

I notice that there are six lines in the upper section referencing my video driver, yet i only entered three commands to carry out the locking process. Did I miss anything?
 
I'm not sure what you're asking.

In the transcript, you had one package locked, locked two additional ones, and it reports three packages are locked.
Were you expecting the other three packages to be locked because of some dependency?

And what are you trying to accomplish with this? Is there an upcoming version that you want to avoid?
 
You have not shown the commands for six lines. However considering the output as installed packages. you need to lock nvidia-driver and nvidia-drm-66-kmod. But those are dependent to the corresponding kernel version. At some point you have to upgrade those along with the kernel if you use rolling version.
 
gnath said:
But those are dependent to the corresponding kernel version. At some point you have to upgrade those along with the kernel if you use rolling version.
Click to expand...
Is there a mean to know in advance which minimal version a kernel is going to require before updating it? I have P40 cards, which are not going to be supported anymore by the newest Nvidia drivers (they dropped Pascal support), so I'm going to have to perform as well such lock in on the installs using them.
 
arifer said:
I have P40 cards, which are not going to be supported anymore by the newest Nvidia drivers (they dropped Pascal support)
Click to expand...
I suspect a legacy version Nvidia driver will be kept, like x11/nvidia-driver-470 (forever stuck on 470.x), x11/nvidia-driver-390 (forever stuck on 390.x), etc.

So, instead of following x11/nvidia-driver for the latest NVidia driver version, you switch to the 'new' legacy version driver when that time comes.
 
SirDice said:
I suspect a legacy version Nvidia driver will be kept, like x11/nvidia-driver-470, x11/nvidia-driver-390, etc.

So, instead of following x11/nvidia-driver for the latest NVidia driver version, you switch to the 'new' legacy version driver when that time comes.
Click to expand...
Yes. x11/nvidia-kmod-580, x11-nvidia-driver-580 and x11/linux-nvidia-libs-580 are certainly planned once their master port pointing to Production Branch of drivers switch to 590 or later series of drivers, which drops pre-Turing generarions of architectures.

graphics/nvidia-drm-*-kmod-580 would be wanted, too, but it means additional 6 more to be added, thus, would need discussions. Maybe added, though, but cannot promise for now.

On the other hand, we cannot promise how long existing legacy versions can be provided, as all of them are already EoL'ed upstream (nvidia). So at some point possibly upstream tarball, which are proprietary, could dissappear.

And more, EoL'ed versions wouldn't accept updates even if fatal vulnerabilities are found. In this case, we need to delete affected branches even if upstream tarballs are still available.

Recently, upstream info about legacy drivers are updated and turned out even 470 series are already EoL'ed. Post Kepler (Maxwell and later) GPUs 470 supported are kept to be supported by 580.
 
T-Aoki said:
On the other hand, we cannot promise how long existing legacy versions can be provided, as all of them are already EoL'ed upstream (nvidia). So at some point possibly upstream tarball, which are proprietary, could dissappear.
Click to expand...
Yeah, that's perfectly fine and expected. The most important thing, for me, is that we can tell when we should stop upgrading. If I can lock the driver to nvidia-driver-580 and then trying to update the base system tells me, at least through a warning, that I should probably not do that because my GPU driver is not supported by the kernel in the updated base, everything is fine, I won't upgrade. If, on the other hand, I can update the base as usual and then discover when booting on the new kernel that, woops, the GPU driver won't load with the new kernel and I have to update the driver to a version actually not supporting my GPU, so my only real option is to find a way to downgrade again the base system (which I assume would be such a mess that I'd better do a clean install of an old version of the OS), I'm going to be in a terrible mood. 😂
 
arifer said:
that I should probably not do that because my GPU driver is not supported by the kernel in the updated base
Click to expand...
Kernel has nothing to do with it. Besides the fact that third party kernel modules typically need to be build for your specific kernel version.

I have an old system, has been upgraded many times over the years. Has an old GT220 Nvidia chipset and needs to use x11/nvidia-driver-390. Can't even remember what FreeBSD version I used initially (it's been 15 years), runs 15.0-RELEASE now, with the legacy 390 Nvidia version driver.
 
SirDice said:
Kernel has nothing to do with it. Besides the fact that third party kernel modules typically need to be build for your specific kernel version.

I have an old system, has been upgraded many times over the years. Has an old GT220 Nvidia chipset and needs to use x11/nvidia-driver-390. Can't even remember what FreeBSD version I used initially (it's been 15 years), runs 15.0-RELEASE now, with the legacy 390 Nvidia version driver.
Click to expand...
The breakages should happen on main first.

And once the breakage is reported officially (basically via Bugzilla if the reporter cannot provide patches to fix), or we ourselves encountered the breakage, we would dig into the reason why and try to fix.

An recent example is PR 288236 (review D51340). Note that this happened before stable/15 branched.
 
SirDice said:
Kernel has nothing to do with it. Besides the fact that third party kernel modules typically need to be build for your specific kernel version.
Click to expand...
Awesome. I must have misunderstood gnath's post, I thought it meant a specific kernel version allowed only a range of specific Nvidia driver versions (or even a specific version). Good to know there won't be such nightmare scenario. :)
 
arifer said:
I thought it meant a specific kernel version allowed only a range of specific Nvidia driver versions
Click to expand...
To be honest, it happened before, but as far as I know, only once.

When nvidia switched to current form of "Unified Driver" that supports multiple generations of GPU architectures in single driver package, nvidia needed some (if I recall correctly, 2) kernel functionalities that FreeBSD didn't have at the moment.

Until FreeBSD implemented the functionalities, nvidia stopped providing drivers for FreeBSD that supports cutting edge GPUs. And once FreeBSD implemented them, nvidia restarted providing the same versions of drivers as Linux (with some functionalities like CUDA removed, as it needs functionalities that FreeBSD not yet have or incompatible). But this meant that older branches of FreeBSD cannot use it unless the functionalities are MFC'ed.
Fortunately, this is an old story (except CUDA etc.).
 
Not sure if it's still the case, but at some point I built a custom kernel without all the COMPAT_FREEBSDxx shims. I always build my own package repositories, for their specific FreeBSD version so I figured I didn't need the old version compatibility shims. Everything worked as expected, except the NVidia driver. It loaded just fine but Xorg simply refused to start. For some odd reason it required COMPAT_FREEBSD11 when 11 was EoL for quite some time. Should try a custom kernel again, but I'm guessing it still requires a couple of older COMPAT_FREEBSDxx shims. The GENERIC kernel has COMPAT_FREEBSD4 all the way up to COMPAT_FREEBSD[N-1] so you don't notice this requirement. I also couldn't find any reference or mention in the (NVidia) documentation regarding this COMPAT_FREEBSDxx requirement.

arifer said:
I thought it meant a specific kernel version allowed only a range of specific Nvidia driver versions (or even a specific version)
Click to expand...
Only the DRM drivers have that limitation. Because they rely on specific LINUXKPI features built into the kernel. The NVidia driver itself never used those and was therefor not impacted by the FreeBSD kernel version.

The only real limiting factor of the old(er) NVidia driver versions is the version of X (x11-servers/xorg-server). x11/nvidia-driver-304 for example. Still builds and loads on 15.0, but won't work with a current Xorg. The 390 version still builds and works on 15.0 with a recent Xorg, but I do seem to have lost OpenGL functionality some time ago. Again due to changes in Xorg, not FreeBSD.
 
SirDice said:
The only real limiting factor of the old(er) NVidia driver versions is the version of X (x11-servers/xorg-server). x11/nvidia-driver-304 for example. Still builds and loads on 15.0, but won't work with a current Xorg. The 390 version still builds and works on 15.0 with a recent Xorg, but I do seem to have lost OpenGL functionality some time ago. Again due to changes in Xorg, not FreeBSD.
Click to expand...
Thanks for all the information! 👍️ In my case, this won't be an issue because I don't use X on those homelabs anyway, they're purely local inference servers (the P40 don't even have a video output, anyway 😅).

I bookmark this thread for when I'll start installing FreeBSD on one of those, thanks everyone.
 
SirDice said:
It loaded just fine but Xorg simply refused to start. For some odd reason it required COMPAT_FREEBSD11 when 11 was EoL for quite some time.
Click to expand...
If the kernel modules load fine but Xorg doesn't and any of COMPAT_FREEBSD* are required, it maybe mean the library part (basically provided as pre-built objects) require it.

SirDice said:
The only real limiting factor of the old(er) NVidia driver versions is the version of X (x11-servers/xorg-server).
Click to expand...
This is because EoL'ed versions does not at all upgraded for newer X11 servers that appear after the driver release date. So known but never fixed limitations.
 
jwillia3 said:
Were you expecting the other three packages to be locked because of some dependency?
Click to expand...
Yes, that is what I was thinking.

jwillia3 said:
And what are you trying to accomplish with this? Is there an upcoming version that you want to avoid?
Click to expand...
Not any version in particular, but I have read one or two threads in which users stated that their installation of FreeBSD became unstable, due to an invidia driver issue, after an upgrade.
 
You must log in or register to reply here.
Back
Top