Can't load nvidia-drm.ko on FreeBSD 14.3-RELEASE : unsupported file type.

[T-Aoki]

I (KNOW) this happens because I (literally) just ran (right now - 8/22/2025) pkg upgrade and pkg wanted to downgrade all of my drivers back to 14.2. I have thus pkg lock all of my newly installed (14.3 NVidia drivers) so that they don't get stepped on.

I come to think any cautions with this should be documented at the top of Release Note, as .FreeBSD-kmods repo is new comer starting from 14.2.

And this repo DOES NOT HAVE EVERYTHING STRICTLY DEPENDING ON PRECISE VERSION. This should be documented in conjunction with the above at the same place.
See the quoted parts of linked (old) mail archive at freebsd-ports ML.

 

[T-Aoki]

Anyway, I've done what I can currently on PR 288314. Now it's on admins of kmod pkg builders to accept or not. If not accepted, I have no other way for this at least for now, unfortunately.
It's not on my hand right now.

The patch (for main branch [aka latest] of ports tree) is now under review as D52178. Not yet accepted nor receiving requests for fixes.

Hope it (or with requested fix) lands before next quarterly (2025Q4) is branched on early October.

 

[ZioMario]

Hello.

I'm having serious problems installing the new nvidia driver on FreeBSD 14.3-RELEASE-p2 :

# portsnap fetch update
# cd /usr/ports/graphics/nvidia-drn-61-kmod
# make

 

[scottro]

I use gitup for ports, then I ran

portmaster nvidia-drm-kmod

which pulled in all other needed stuff, like nvdia-drm-61, etc.

 

[T-Aoki]

I

Hello.

I'm having serious problems installing the new nvidia driver on FreeBSD 14.3-RELEASE-p2 :

# portsnap fetch update
# cd /usr/ports/graphics/nvidia-drn-61-kmod
# make

View attachment 23787

Is your /usr/src exactly matches that of 14.3-p2?
I believe yours is at outdated and unfortunate commit of main branch.

This can happen only on main (Current) within around 10 days of broken window. When we (nvidia driver ports team) fixed the issue, usable OSVERSION bump was around 10 days before the offensive commit, so broken window exists.

See review D51340 for details.
And the fix landed at 2025-07-17 02:25:26 +0000 as commit ports 9302fb05a0c6599bbe8963ff5201fd3b99994535.

 

[T-Aoki]

Maybe PR 288236 would be better to track what happened and how it was discussed. Anyway, this IS already fixed issue.

 

[ZioMario]

Worked,thanks.

 

[astyle]

Considering all the visible testimonials of how wonderfully NVidia works with FreeBSD, it's pretty curious to realize that these Forums are stuffed to the brim with horror stories of failure of that. I'd think one would need to match specific GPU models with specific driver versions AND with specific kernel versions.

And yeah, this is one more case for the books where freebsd-update(8) is really oversold as a usable upgrade tool. Survivorship bias is an actual bias of overselling a point that doesn't merit much attention. You'd think that users will gloat en masse over how easy freebsd-update(8) is (if used correctly) - but all I can see is horror stories. If freebsd-update(8) were in fact that easy, there'd be a group-wide self-correction, accompanied by a reduction of associated horror stories. But I'm seeing the exact opposite happen, even for people who actually RTMed. Sometimes, I think that maybe the idea of survivorship bias was just not applied correctly... Everybody wants info to be convenient

People do gloat about stuff like Poudriere, ZFS, and cron - even in the face of horror stories involving those things. Plenty of horror stories about those, but it's not like there's only a select group of users who are staunch supporters and experts with special, limited, optimized setups that consistently hit the sweet spot.

 

[mer]

I'd think one would need to match specific GPU models with specific driver versions AND with specific kernel versions.

Specific hardware drives required version of driver. Version of driver may drive required version of kernel because of linux drm (may not be the correct phrasing).
If a kernel version does not provide the support a version of the driver needs (think older legacy 304/340 versions of driver) then yes a user gets into I have old hardware, the driver is only supported by kernel <= 14.x, now what do I do.

To me, my opinion only, the simple answer is sometimes you need to update your hardware. And yes I understand "it ain't broke so why fix" but if newer kernel/userland/ports are bringing in needed security updates, you really may want to update hardware as the simple path.

my system with nvidia is using the 470 version of driver, I fully expect I need to buy a new video card or enable onboard i915 at some point in the future.

 

[T-Aoki]

Considering all the visible testimonials of how wonderfully NVidia works with FreeBSD, it's pretty curious to realize that these Forums are stuffed to the brim with horror stories of failure of that. I'd think one would need to match specific GPU models with specific driver versions AND with specific kernel versions.

And yeah, this is one more case for the books where freebsd-update(8) is really oversold as a usable upgrade tool. Survivorship bias is an actual bias of overselling a point that doesn't merit much attention. You'd think that users will gloat en masse over how easy freebsd-update(8) is (if used correctly) - but all I can see is horror stories. If freebsd-update(8) were in fact that easy, there'd be a group-wide self-correction, accompanied by a reduction of associated horror stories. But I'm seeing the exact opposite happen, even for people who actually RTMed. Sometimes, I think that maybe the idea of survivorship bias was just not applied correctly... Everybody wants info to be convenient

Maybe because successful (survived) stories are rarely posted.

 

[T-Aoki]

Specific hardware drives required version of driver. Version of driver may drive required version of kernel because of linux drm (may not be the correct phrasing).
If a kernel version does not provide the support a version of the driver needs (think older legacy 304/340 versions of driver) then yes a user gets into I have old hardware, the driver is only supported by kernel <= 14.x, now what do I do.

To me, my opinion only, the simple answer is sometimes you need to update your hardware. And yes I understand "it ain't broke so why fix" but if newer kernel/userland/ports are bringing in needed security updates, you really may want to update hardware as the simple path.

my system with nvidia is using the 470 version of driver, I fully expect I need to buy a new video card or enable onboard i915 at some point in the future.

You seem to be mixing up something.

For nvidia GPU drivers, any legacy versions (304, 340, 390 and 470) of drivers cannot support graphics/nvidia-drm-*-kmod[-devel], as the upstream driver tarball doesn't contain needed codes.
So DRM codes does NOT matter for legacy versions of drivers. Just needs x11/nvidia-driver-[304|340|390|470] and corresponding x11/nvidia-kmod-[304|340|390|470].
No need for in-base LinuxKPI.

Onboard i915 would want any of graphics/drm-[510|515|61|66]-kmod (or newer versions not in-tree yet). It would be what you described in first paragraph. 510 is no longer supported on at least 15.0 and later, and 66 does NOT support any of pre-15.0 releases with the lack of functionalities in base LinuxKPI.

 

[astyle]

To me, my opinion only, the simple answer is sometimes you need to update your hardware.

Update hardware? Not everybody wants to do that, esp. if it works fine, just needs the correct driver....

Maybe because successful (survived) stories are rarely posted.

I'd say there's kind of a difference between posting a success story and gloating how easy it could have been if the user with the horror story just RTFMed. I'd expect a pretty big crowd of people making off-hand comments about the need to just RTFM. I guess you can compare freebsd-update(8) to a medical study of a pill. No, not many people will post that a specific pill worked. But if the pill was found to have adverse side effects, then oh, yeah, you'll hear about it in the press and on TV. But even then, the pill is only appropriate for a specific medical condition, just like freebsd-update(8) is, unfortunately, only appropriate for very limited scenarios where technical details have been carefully lined up.

 

[T-Aoki]

Update hardware? Not everybody wants to do that, esp. if it works fine, just needs the correct driver....

nvidia already EoL'ed pre-470 versions of their driver.

Why we not yet deleted x11/[linux-]nvidia-[driver|kmod|libs][-304|-340|-390] is simply because the upstream tarballs are still available and no vulnerability infos are found for the latest one of each branch.
As 3xx series of drivers are unlikely to be updated anymore, once any vulnerability is reported for any of them, we'll simply delete it from ports, even if upstream tarballs are still available.

Of course, if the vulnerabilities are found and fixed on somewhere in provided source codes (not binary only part) of supported versions and backport is trivial enough, we'll try backporting the fix and avoid deletion. But we cannot promise about that at least for now.

So users of old nvidia GPUs that can be driven pre-470 series of drivers is encouraged to switch their GPUs before required driver is gone.

And note that, starting from 4xx series, nvidia dropped support for i386.

 

[mer]

You seem to be mixing up something.

For nvidia GPU drivers, any legacy versions (304, 340, 390 and 470) of drivers cannot support graphics/nvidia-drm-*-kmod[-devel], as the upstream driver tarball doesn't contain needed codes.
So DRM codes does NOT matter for legacy versions of drivers. Just needs x11/nvidia-driver-[304|340|390|470] and corresponding x11/nvidia-kmod-[304|340|390|470].
No need for in-base LinuxKPI.

Onboard i915 would want any of graphics/drm-[510|515|61|66]-kmod (or newer versions not in-tree yet). It would be what you described in first paragraph. 510 is no longer supported on at least 15.0 and later, and 66 does NOT support any of pre-15.0 releases with the lack of functionalities in base LinuxKPI.

If I'm mixing things up, good, then I'm learning and thank you.
For me, and yes it could just be me, is the relationship between the different nvidia hardware, nvidia driver versions and kernels and "drm" is not clear.

Hard example, my Nvidia system:
nvidia-driver-470-470.256.02.1402000_1
14.3-RELEASE-p2
kld_list="/boot/modules/nvidia-modeset.ko"
Running X not Wayland.

So moving forward to say 15.x what do I need to be worried about? Do I need to change any of this configuration?
Asking because other threads on this imply I may need to

 

[astyle]

So moving forward to say 15.x what do I need to be worried about?

dropped support for older NVidia cards, for starters.

Oh, and the usual dependency hell that come with freebsd-update(8)...

 

[T-Aoki]

For me, and yes it could just be me, is the relationship between the different nvidia hardware, nvidia driver versions and kernels and "drm" is not clear.

Basically, legacy nvidia driver, nvidia.ko, is built for old-school X11 interface, so called "user mode setting". And this is really a kernel side driver part.

nvidia-modeset.ko implements "kernel mode setting" (KMS) interface with missing staff wrapping nvidia.ko around. But this is specially crafted KMS staff for nvidia proprietary drivers and libraries and in-ports X11 does NOT know how to determine it (it assumes its genuine nv driver or nouveau driver and does NOT sniff nvidia proprietary driver, thus, need additional configs). These depends on FreeBSD kernel but does NOT require LinuxKPI support.

On the other hand, nvidia-drm.ko, which is installed by graphics/nvidia-drm-*-kmod[-devel] and does not (cannot) support legacy versions of drivers, implements generic "direct rendering manager" (DRM) interface with additional generic KMS wrapper for it by wrapping around nvidia-modeset.ko.
This is achieved by using codes from corresponding graphics/drm-*-kmod.
And this results in depending on base LinuxKPI.

nvidia-driver-470-470.256.02.1402000_1
14.3-RELEASE-p2

This is basically wrong and if you're using DRM driver, it shouldn't work at all, as interface of LinuxKPI (mimics Linux kernel programming interface, thus, far more fragile than native FreeBSD KPI, often changes with backward incompatible way) is used.
But as KPI of native FreeBSD is relatively stable and backward compatible, nvidia drivers without DRM often works fine in this kind of minor version minmatches if NOT rejected on kldloading.

 

[astyle]

For me, and yes it could just be me, is the relationship between the different nvidia hardware, nvidia driver versions and kernels and "drm" is not clear.

For me, that sounds like an excuse to invite you over to Team Red. Over there, we have unique code names for every generation of GPUs. Sometimes, it's generation (age), sometimes it's a specific GPU architecture like Polaris. And it's possible to use those codenames to figure out if a specific model GPU is supported or not. For example, RX 6800 / RX 6800 XT / RX 6900 XT are all supported by the sienna_cichlid driver... Once you do enough research, you'll see patterns emerge. And those things work pretty reliably on kldloading

 

[T-Aoki]

To look for GPU names supported by legacy versions of nvidia drivers, this page would be helpful.