Nvidia driver, CUDA tools and libraries

nvidia-logo-1

Oh no, another Nvidia driver repository? Why? This repository reflects my personal view for the way the driver should be packaged for Fedora and CentOS/RHEL. It’s somewhat different from ELRepo repositories for RHEL/CentOS and from RPMFusion packages for Fedora.

Repository installation

To install the repository on a supported Fedora distribution, run as root the following command:

dnf config-manager --add-repo=https://negativo17.org/repos/fedora-nvidia.repo

To install the repository on CentOS/RHEL:

yum-config-manager --add-repo=https://negativo17.org/repos/epel-nvidia.repo

The Nvidia software packages are available for installation by default also in Gnome Software.

Please note that the driver will show up only if your system matches one of the PCI ID supported by the driver. Otherwise, only the other Nvidia programs (mostly for CUDA development) will show up in the software center.

What’s different?

First of all the packaging is a lot simplified; more stuff is compiled from source, smaller packages and more options. This packages try to comply as maximum to the Fedora Packaging Guidelines; which means they have debuginfo packages, default Fedora’s GCC compile time options (where possible) and standard locations for binaries, data and docs.

What follows below, is a detailed explanation of all the “differences” from the various Nvidia driver packages that I was able to spot on the web and a detailed description on how to install components, etc.

Nvidia drivers

Packaging

  • nvidia-settings, nvidia-persistenced, nvidia-xconfig and nvidia-modprobe are compiled from source.
  • All RPM filters except for GL and OpenCL libraries have been removed, so there is no weird dependency option in the SPEC file. RPM pulls in all correct requirements on its own. This is to avoid pulling in the Nvidia drivers instead of the Mesa libraries or in place of the new open source OpenCL support that’s in Fedora.
  • Simplified packaging with much simpler and readable SPEC file.
  • Dependency on libva-vdpau-driver. So in Totem, or any other libVA supported application you can benefit from VDPAU acceleration.
  • Sources are generated with a script and inserted individually in the various packages; so it can be easily reproduced just by changing the version and rerunning the script.
  • nvidia-xconfig is not required on anything that uses the modular X.org directives, as it writes too much in the configuration file (keyboards, monitors, etc.) and the required entries should be written in separate configuration files under /etc/X11/xorg.conf.d. The package is still available as it’s required to speed up some configuration like multi-monitor setups with SLI Mosaic enabled from the command line, but not installed by default.
  • The NVIDIA OpenGL-based Framebuffer Capture (NvFBCOpenGL) libraries (NvFBC and NvIFR) are private APIs that are only available to NVIDIA approved partners for use in remote graphics scenarios (i.e. Steam In-Home Streaming hardware encoding); so they are packaged in another small package called nvidia-driver-NvFBCOpenGL.
  • The nvidia-settings package now builds the external libXNVCtrl.so library that can be used to control the graphic cards through the NV-CONTROL extension. This library updates the old and obsolete one in Fedora.
  • The nvidia-settings binary is compiled with GTK3 instead of GTK2 on Fedora and RHEL/CentOS 7+.
  • The driver can be installed separately from the nvidia-settings utility, so if you simply want a working driver and do not care about details, your experience should be as close as possible to the one with open source drivers.

Versioning

  • ELRepo ships 32 bit compatibility libraries in a separate package with x86_64 as the architecture and “32bit” in the name. 32 bit libraries should be like in RPMFusion, with an i686 package installable in parallel with the x86_64 one. There are no other packages in the distribution that are built for x86_64, with “32bit” in their name that contain i686 binaries (!), so Nvidia drivers should not be an exception. So no separate “32bit.x86_64” package for 32 bit libraries also on CentOS/RHEL; just install nvidia-driver-libs.i686.
  • Versions are not hidden; all packages have the same driver version.
  • No alternatives system, only the latest version which integrates CUDA support is available. For older releases nouveau works great; and anything below a GeForce 8xxx it’s in my opinion too low end to play anything modern. And Quake 3 and Doom 3 work greatly with nouveau, so that’s not a case!
  • The CentOS/RHEL repository contains the “Long Lived Branch version” where less changes occur; while Fedora repositories contains the “Short Lived Branch version”. Beta CentOS/RHEL and Fedora’s rawhide repositories will contain the “Beta Branch version”

CUDA support

  • CUDA libraries/tools for the driver are split into subpackages. There’s no need to install all the CUDA libraries and tools on a system that has only one adapter and is used for occasional gaming or for simple office use. This can save ~120 MB worth of installed libraries. nvidia-persistenced falls in this category as it’s not needed on a normal laptop or gaming system.
  • Complete packaged CUDA stack has been added for all supported distributions, all the packages provide/require/obsolete the relevant packages in the Nvidia CUDA repository; so you can enable this repository along with the official Nvidia CUDA one (x86_64 systems only).

Kernel modules

  • Multiple choice of kernel module packages; akmod (RPMFusion) for Fedora and binary kmod (Kernel ABI whitelists) for CentOS/RHEL. In addition to this, on both distributions dkms packages are available. This way all cases and personal preferences are covered for both distributions.
  • The Nvidia udev rules leverage nvidia-modprobe command in the system to create devices and set permissions even when the userspace libraries have not been loaded yet, covering the case of Wayland only sessions and compute only system without display userspace components installed.
  • The nvidia-uvm module has a soft dependency on the nvidia module, making sure that these modules are not included in the initrd (thing that would happen by using systemd’s configuration (module-s-load.d). UDev rules make sure the module has proper permissions.
  • Choice of proprietary or open source license kernel modules.

Default configuration

  • Dracut options are depending on the distribution; so no more “vga=normal is an obsolete option” at boot. Each distribution gets its own specific GRUB options for booting.
  • 96 DPI is written in the default xorg.conf config file. Why? Gnome 3 by defaults hard-codes a 96×96 DPI resolution, most of the free drivers do (intel, nouveau, etc.) as the EDID is almost never reliable (please see the excellent Adam’s Jackson post where he explains this). As an example, if you install the Nvidia drivers on a RHEL/CentOS 6 laptop where you used to have nouveau installed (96 DPI hardcoded), the fonts gets 90% of the time supersize and ugly as Gnome 2 and the Nvidia driver do not hard-code 96 DPI like Gnome 3.
  • Make X.org NVIDIA Files section to be loaded latest in case there are other packages providing a custom Files section.
  • Use new OutputClass directive on X.org server 1.16 (and later) to load the driver and do not rely on an edited /etc/X11/xorg.conf file. This also removes editing of the xorg.conf file from the package scriptlets. This does not hardcode the 96 DPI resolution.
  • Add the IgnoreABI directive by default on Fedora rawhide builds.

Kernel modesetting and Wayland support

Kernel mode setting on the nvidia-drm module is enabled by default along with the console frame buffer driver.

Distribution and Nvidia driver version support

Here is a rundown of Nvidia supported drivers and options split by distribution. Basically, CentOS/RHEL will always get a Long Lived branch release if possible, Fedora always a Short Lived branch release, and unreleased distributions will always get a Beta driver.

Operating systemCentOS / RHELFedorarawhide
Driver branchLong LivedShort Lived
Long Lived		Short Lived
Long Lived
Beta
Video Codec SDKYesYesYes
Architectures:

x86_64
aarch64		YesYesYes
Basic nvidia driver:

nvidia-driver
nvidia-driver-libs
nvidia-libXNVCtrl
nvidia-kmod-common		YesYesYes
CUDA libraries and tools:

libnvidia-ml
nvidia-driver-cuda
nvidia-driver-cuda-libs
nvidia-persistenced		YesYesYes
OpenGL Framebuffer Capture:

libnvidia-fbc		YesYesYes
Nvidia tools:

nvidia-modprobe
nvidia-settings
nvidia-xconfig
YesYesYes
Binary kernel
modules (kABI):

kmod-nvidia		YesNoNo
DKMS kernel
modules:

dkms-nvidia		YesYesYes
aKMOD kernel
modules:

akmod-nvidia		NoYesYes
32 bit compatibility on x86_64:

libnvidia-ml
nvidia-libXNVCtrl
nvidia-driver-libs
nvidia-driver-cuda-libs
YesYesYes
VDPAU librariesYesYesYes
EGLStream-based Wayland external platformYesYesYes
GBM EGL external platform libraryYesYesYes

Optimus laptops

The driver should install and operate cleanly whether you are installing it on a system which has one or more discrete Nvidia cards or an Optimus laptop with an Intel and a Nvidia card. Nothing to do to enable or configure Optimus.

This is up to the point that when the drivers are installed, you can even turn off Optimus on or off in your system Bios (if your laptop allows that) and the only difference you should see is that there’s an additional VGA card enabled in your system (check with lspci) and that the Nvidia control panel switches between a PRIME Display, like in this picture:

And a normal RandR managed one, like in this one:

Everything else should not be different from your normal experience.

Limitations with the Nvidia driver

The limitations are the same as provided by the Nvidia driver, this means that if you are running it on an Optimus laptop, the Intel card can never power off. Which means higher power consumption, unfortunately. If you have an Optimus laptop and absolutely need the proprietary drivers, my suggestion is still to disable Optimus in the Bios.

Limitations with the OSS stack

On the contrary, if you use the OSS stack (nouveau/intel) the second card can be powered off if there’s no application running on it or display directly connected to one of the card’s outputs. That’s the best reason to use the OSS drivers at all if you you’re not doing serious gaming or 3D work:

$ sudo cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :DynOff:0000:01:00.0

You also got the nifty selection menu about running your game on the discrete card on Gnome, which is really cool:

It will power up the video card just before launching the process. Launching a program through that menu entry is like starting it from the command line with the DRI_PRIME variable declared. For example, the same as above would be:

$ DRI_PRIME=1 quake3 &
$ sudo cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :DynPwr:0000:01:00.0

As you can see, the discrete video card is turned on. For Steam, you still need to edit each of your game to run on the Nvidia card:

SLI systems

SLI is now enabled by default with the Auto profile, there’s nothing to do if you have a SLI system. If you need any different SLI option (AA, SFR, etc.), just override it in X.org configuration files.

Nouveau fallback

With the new expanded OutputClass support for X, as carried out by Hans, it’s now super easy to switch to the OSS stack if the proprietary Nvidia driver somehow does not work. No user space component is touched, as soon as the Nvidia kernel module is not loaded (check on /sys/module/nvidia), the desktop starts with the normal OSS components you get with a normal installation. Thanks to all the work done on libglvnd, the libraries loaded are the correct one for the driver you are running.

This means that the performance of the Nvidia card would be abysmal, but still you would get a nice desktop and browser to Google around for answers on how to fix it :).

Sample installation

Here is an example. Let’s assume you have a freshly installed CentOS system with a recent Nvidia GPU and you want to:

  • Install the driver for gaming
  • Play Vulkan enabled games
  • Want to be comfortable with the Nvidia control panel
  • Play 32 bit games (Vulkan included) on a 64 bit system
  • Play 32 bit Vulkan games on a 64 bit system
# yum install nvidia-driver nvidia-driver-libs.i686
Last metadata expiration check: 0:05:30 ago on Tue 05 Feb 2019 06:52:50 AM CET.
Dependencies resolved.
================================================================================
 Package                   Arch     Version           Repository           Size
================================================================================
Installing:
 nvidia-driver             x86_64   3:415.27-4.fc29   fedora-multimedia   2.4 M
 nvidia-driver-libs        i686     3:415.27-4.fc29   fedora-multimedia    18 M
Installing dependencies:
 akmod-nvidia              x86_64   3:415.27-1.fc29   fedora-multimedia    10 M
 nvidia-driver-cuda-libs   x86_64   3:415.27-4.fc29   fedora-multimedia    25 M
 nvidia-driver-libs        x86_64   3:415.27-4.fc29   fedora-multimedia    34 M
 nvidia-kmod-common        noarch   3:415.27-1.fc29   fedora-multimedia    10 k
 akmods                    noarch   0.5.6-17.fc29     updates              22 k
 egl-wayland               x86_64   1.1.1-3.fc29      updates              29 k
 kernel-devel              x86_64   4.20.6-200.fc29   updates              13 M
 mesa-libEGL               i686     18.2.8-1.fc29     updates             112 k
 mesa-libgbm               i686     18.2.8-1.fc29     updates              39 k
 libglvnd-egl              i686     1:1.1.0-2.fc29    fedora               45 k
 libglvnd-gles             i686     1:1.1.0-2.fc29    fedora               32 k
 libglvnd-opengl           i686     1:1.1.0-2.fc29    fedora               37 k
 libglvnd-opengl           x86_64   1:1.1.0-2.fc29    fedora               39 k
 libva-vdpau-driver        x86_64   0.7.4-22.fc29     fedora               60 k
 libwayland-server         i686     1.16.0-1.fc29     fedora               38 k

Transaction Summary
================================================================================
Install  17 Packages

Total download size: 103 M
Installed size: 385 M
Is this ok [y/N]:

As you can see, this system has akmod enabled kernel modules and libraries for running 32 bit applications. The amount of data to download for the drivers is really small compared to packages that contain CUDA libraries and tools.

Package installation

If you are booting the system in UEFI mode; as a prerequisite to installing any external module (not built into the kernel package), you have to disable UEFI Secure Boot in the system configuration. All modules contained in the kernel package are signed with keys that are generated during build and deleted when packaging. If you want to preserve Secure Boot, you need to sign the modules yourself and import the keys into your hardware module. Doing so is out of scope here; if you need a decent guide just follow Red Hat’s guide for signing kernel modules.

First of all remove all the Nvidia drivers you might have on your system due to RPMFusion, ELRepo, or the Nvidia CUDA repository. This is usually accomplished with the following root command:

yum -y remove *nvidia*

Then, to install the Nvidia driver and its control panel utility in CentOS/RHEL with the binary kABI (Kernel ABI whitelist) module (this is the default on CentOS/RHEL), perform the following command:

yum -y install nvidia-driver nvidia-settings

To do the same in Fedora, using akmod modules, perform the following command:

dnf -y install nvidia-driver nvidia-settings

Specific driver installations

For both Fedora and CentOS/RHEL distributions it’s possible to install additional packages and / or variant of the basic kernel modules. This paragraph contains some examples. Make sure you have the EPEL repository enabled if you plan to use DKMS modules on CentOS/RHEL.

akmod kernel module variant (Fedora):

dnf -y install nvidia-driver akmod-nvidia

DKMS kernel module variant (Fedora/CentOS/RHEL):

yum/dnf -y install nvidia-driver dkms-nvidia

To add 32 bit libraries on a 64 bit system (for games or applications like Steam):

yum/dnf -y install nvidia-driver-libs.i686

Proprietary and open source kernel modules

Since almost a year, the Nvidia driver ships with two different implementations of the kernel modules, one proprietary and one open source. The open source one as of drivers 545.x is now considered beta quality also for the workstations, so it seems a good moment to start shipping it.

The open source one is supposed to be the only one that will be kept in the future, but at the moment both are available and both differ in terms of functionality. You can read about the main differences in terms of functionality and what chips they support in the official documentation.

I did not want to introduce another variation of the kernel modules beside akmods, kABI and DKMS, this would have created even more confusion and lots of dependencies in the SPEC files for the variations. The new akmod and DKMS packages ship both sources (MIT/GPL and proprietary kernel modules) and allow you to switch between one or the other through a configuration file.

Considering that in the long run only the open source variant will remain, I wanted to make this as transparent as possible for the users. Basically, if you don’t care and just want something that works, nothing has changed for you.

The two sources get referenced as they are referenced inside the Nvidia run file, namely “kernel” for the original proprietary kernel modules and “kernel-open” for the new open source variation.

The following instructions show you how to switch between one implementation or the other.

DKMS

Check which version you have installed:

# modinfo -l nvidia
NVIDIA

Change the type of modules you want to use and trigger a rebuild and a reinstall:

# sed -i -e 's/kernel$/kernel-open/g' /etc/nvidia/kernel.conf
# dkms build -m nvidia/545.29.02 --force
# dkms install -m nvidia/545.29.02 --force

Now check again the license and you should see that it has changed to MIT/GPL:

# modinfo -l nvidia
Dual MIT/GPL
# reboot

To switch back, change the configuration again and then trigger the same process for rebuilding installing:

# sed -i -e 's/kernel-open$/kernel/g' /etc/nvidia/kernel.conf
# dkms build -m nvidia/545.29.02 --force
# dkms install -m nvidia/545.29.02 --force
# reboot

akmods

Check which version you have installed:

# modinfo -l nvidia
NVIDIA

Change the type of modules you want to use and trigger a rebuild and a reinstall:

# sed -i -e 's/kernel$/kernel-open/g' /etc/nvidia/kernel.conf
# akmods --rebuild

Now check again the license and you should see that it has changed to MIT/GPL:

# modinfo -l nvidia
Dual MIT/GPL
# reboot

To switch back, change the configuration again and then trigger the same process for rebuilding installing:

# sed -i -e 's/kernel-open$/kernel/g' /etc/nvidia/kernel.conf
# akmods --rebuild
# reboot

Additional driver configuration to your system

To add additional configuration to your system, just create the /etc/X11/xorg.conf file. For example:

Section "Device"
  Identifier  "Device0"
  Driver      "nvidia"
  Option      "NoLogo" "true"
  Option      "DPI" "96 x 96"
  Option      "SLI" "Auto"
  Option      "nvidiaXineramaInfoOrder" "DFP-0"
  Option      "metamodes" "GPU-a493fbbb-7d76-86a2-8764-d76d487a75a7.DVI-I-1: nvidia-auto-select +0+0, GPU-c02960a4-be28-d5ce-8b02-be04b5e2550b.DVI-I-1: nvidia-auto-select +1680+0"
  Option      "BaseMosaic" "on"
EndSection

In this example we have 2 video cards with one monitor each, so we enabled SLI, Base Mosaic to have multi monitor support on SLI and make a layout with the second GPU monitor on the right of the first one. Also, we fix the DPI to 96×96, which is the hardcoded default in Gnome and in Open Source drivers.

Configuration for CUDA only systems

Your system might only be used for CUDA development and not require the X server to be running the DDX driver at all, so you might want to tweak the configuration a bit to make the system load (for example) the Intel driver as the main display and just the Nvidia driver for GPU workloads. In this case you have two options.

Option with only CUDA components installed

To install just the CUDA components of the driver and not the OpenGL libraries and all files required by the DDX part of the driver, proceed to install as follows:

# yum install nvidia-driver-cuda
Last metadata expiration check: 0:22:51 ago on Tue 05 Feb 2019 06:52:50 AM CET.
Dependencies resolved.
================================================================================
 Package                   Arch     Version           Repository           Size
================================================================================
Installing:
 nvidia-driver-cuda        x86_64   3:415.27-4.fc29   fedora-multimedia   308 k
Installing dependencies:
 akmod-nvidia              x86_64   3:415.27-1.fc29   fedora-multimedia    10 M
 nvidia-driver-NVML        x86_64   3:415.27-4.fc29   fedora-multimedia   457 k
 nvidia-driver-cuda-libs   x86_64   3:415.27-4.fc29   fedora-multimedia    25 M
 nvidia-kmod-common        noarch   3:415.27-1.fc29   fedora-multimedia    10 k
 nvidia-persistenced       x86_64   3:415.27-2.fc29   fedora-multimedia    40 k
 akmods                    noarch   0.5.6-17.fc29     updates              22 k
 kernel-devel              x86_64   4.20.6-200.fc29   updates              13 M

Transaction Summary
================================================================================
Install  8 Packages

Total download size: 49 M
Installed size: 168 M
Is this ok [y/N]:

As you can see, there are no components providing OpenGL or DDX drivers installed on the system. This will not use any X (or Wayland) configuration compared to what has been installed by default on your system.

On top of this, you can still select what kind of kernel modules you want ot have installed (kABI, akmods and dkms).

The device files are created by the udev rules that call the nvidia-modprobe command, it contains a SUID binary that creates the device files and set the appropriate permissions. The same binary is called directly by Nvidia libraries when accessing a user space component that would require device files access:

$ for i in $(rpm -ql nvidia-driver-libs.x86_64 nvidia-driver-cuda-libs.x86_64 | grep \.so); do
  strings $i | grep nvidia-modprobe > /dev/null && echo $i
done
/usr/lib64/gbm/nvidia-drm_gbm.so
/usr/lib64/libnvidia-allocator.so.1
/usr/lib64/libnvidia-allocator.so.545.29.02
/usr/lib64/libnvidia-api.so.1
/usr/lib64/libnvidia-cfg.so.1
/usr/lib64/libnvidia-cfg.so.545.29.02
/usr/lib64/libnvidia-eglcore.so.545.29.02
/usr/lib64/libnvidia-glcore.so.545.29.02
/usr/lib64/libnvidia-glsi.so.545.29.02
/usr/lib64/vdpau/libvdpau_nvidia.so.1
/usr/lib64/vdpau/libvdpau_nvidia.so.545.29.02
/usr/lib64/libcuda.so
/usr/lib64/libcuda.so.1
/usr/lib64/libcuda.so.545.29.02
/usr/lib64/libnvcuvid.so
/usr/lib64/libnvcuvid.so.1
/usr/lib64/libnvcuvid.so.545.29.02
/usr/lib64/libnvidia-opencl.so.1
/usr/lib64/libnvidia-opencl.so.545.29.02

This requires some testing and adjustments with specifics to your setup, but is definitely possible to use the integrated Intel card and or rely on a system without X installed to run the CUDA components.

CUDA

Packaging

  • Previously in the repository was included the GPU Deployment kit. This was constructed with NVML (NVIDIA Management Library) headers, docs and samples from a separate tarball. The separate tarball was using a different version number than the drivers and was packaged in the nvidia-driver-NVML and nvidia-driver-NVML-devel packages. Starting from CUDA version 8, the NVML header is provided by a CUDA subpackage (cuda-nvml-devel) and no longer provided as part of the GPU Deployment kit.
  • Included is also the Video Codec SDK (Decoder/Encoder) headers, docs and code samples. Again, this uses a different version than the drivers.
  • All the libraries are split into subpackages, much like in the original Nvidia CUDA repository. This allows you to install and build software relying on specific components without the need to install all the CUDA toolkit just to satisfy a library dependency. Also, for the same reason, static libraries have been included in each respective static subpackage.
  • In addition to the libraries bundled in the CUDA toolkit, also the cuDNN library for distributed neural networks is included in the repository. See the table below for details.

Distribution and CUDA version support

All the currently supported Red Hat Enterprise Linux versions (including rebuilds and similar forks – CentOS Stream, AlmaLinux, RockyLinux, EuroLinux, etc.) and Fedora versions are available.

In case of yet unsupported compilers in recent distributions, a compatibility cuda-gcc package is available that brings the distribution to a working level with nvcc.

By installing the cuda-gcc package, a variable is loaded automatically that adds the appropriate NVCC options to override the default system GCC when compiling:

$ cat /etc/profile.d/cuda-gcc.sh 
export NVCC_PREPEND_FLAGS='-ccbin /usr/bin/cuda'

CUDA installations

To install just a runtime CUDA support (required for running CUDA enabled programs), without DDX drivers:

yum -y install cuda nvidia-driver-cuda

To just install packages required for enabling CUDA development:

yum -y install cuda-devel

Or if you just want to enable everything:

dnf/yum -y install nvidia-driver nvidia-driver-cuda cuda-devel

A couple of examples. Just the basic tools:

# yum install cuda
Last metadata expiration check: 0:30:55 ago on Tue 05 Feb 2019 06:52:50 AM CET.
Dependencies resolved.
================================================================================
 Package                  Arch    Version              Repository          Size

================================================================================
Installing:
 cuda                     x86_64  1:10.0.130-1.fc29    fedora-multimedia   17 M
Installing dependencies:
 cuda-libs                x86_64  1:10.0.130-1.fc29    fedora-multimedia  8.6 M
 nvidia-driver-cuda-libs  x86_64  3:415.27-4.fc29      fedora-multimedia   25 M

Transaction Summary
================================================================================
Install  3 Packages

Total download size: 51 M
Installed size: 178 M
Is this ok [y/N]:

The basic tools along with all the libraries (note that the NVML headers are included):

# yum install cuda-devel
Last metadata expiration check: 0:35:09 ago on Tue 05 Feb 2019 06:52:50 AM CET.
Dependencies resolved.
================================================================================
 Package                  Arch    Version              Repository          Size
================================================================================
Installing:
 cuda-devel               x86_64  1:10.0.130-1.fc29    fedora-multimedia  1.6 M
Installing dependencies:
 cuda                     x86_64  1:10.0.130-1.fc29    fedora-multimedia   17 M
 cuda-cublas              x86_64  1:10.0.130-1.fc29    fedora-multimedia   31 M
 cuda-cublas-devel        x86_64  1:10.0.130-1.fc29    fedora-multimedia   32 M
 cuda-cudart              x86_64  1:10.0.130-1.fc29    fedora-multimedia  135 k
 cuda-cudart-devel        x86_64  1:10.0.130-1.fc29    fedora-multimedia  533 k
 cuda-cufft               x86_64  1:10.0.130-1.fc29    fedora-multimedia   64 M
 cuda-cufft-devel         x86_64  1:10.0.130-1.fc29    fedora-multimedia  127 M
 cuda-cupti               x86_64  1:10.0.130-1.fc29    fedora-multimedia  1.4 M
 cuda-cupti-devel         x86_64  1:10.0.130-1.fc29    fedora-multimedia  226 k
 cuda-curand              x86_64  1:10.0.130-1.fc29    fedora-multimedia   38 M
 cuda-curand-devel        x86_64  1:10.0.130-1.fc29    fedora-multimedia   61 M
 cuda-cusolver            x86_64  1:10.0.130-1.fc29    fedora-multimedia   40 M
 cuda-cusolver-devel      x86_64  1:10.0.130-1.fc29    fedora-multimedia   15 M
 cuda-cusparse            x86_64  1:10.0.130-1.fc29    fedora-multimedia   27 M
 cuda-cusparse-devel      x86_64  1:10.0.130-1.fc29    fedora-multimedia   28 M
 cuda-libs                x86_64  1:10.0.130-1.fc29    fedora-multimedia  8.6 M
 cuda-npp-devel           x86_64  1:10.0.130-1.fc29    fedora-multimedia   58 M
 cuda-nvgraph             x86_64  1:10.0.130-1.fc29    fedora-multimedia   68 M
 cuda-nvgraph-devel       x86_64  1:10.0.130-1.fc29    fedora-multimedia   13 k
 cuda-nvjpeg              x86_64  1:10.0.130-1.fc29    fedora-multimedia  372 k
 cuda-nvjpeg-devel        x86_64  1:10.0.130-1.fc29    fedora-multimedia   14 k
 cuda-nvml-devel          x86_64  1:10.0.130-1.fc29    fedora-multimedia   53 k
 cuda-nvrtc               x86_64  1:10.0.130-1.fc29    fedora-multimedia  6.3 M
 cuda-nvrtc-devel         x86_64  1:10.0.130-1.fc29    fedora-multimedia   15 k
 cuda-nvtx                x86_64  1:10.0.130-1.fc29    fedora-multimedia   33 k
 cuda-nvtx-devel          x86_64  1:10.0.130-1.fc29    fedora-multimedia   41 k
 nvidia-driver-NVML       x86_64  3:415.27-4.fc29      fedora-multimedia  457 k
 nvidia-driver-cuda-libs  x86_64  3:415.27-4.fc29      fedora-multimedia   25 M

Transaction Summary
================================================================================
Install  29 Packages

Total download size: 650 M
Installed size: 1.6 G
Is this ok [y/N]:

An example where your CUDA application just uses the CUDA Runtime API and not the kernel runtime:

$ sudo dnf install cuda-cudart
Last metadata expiration check: 0:13:10 ago on Sun Oct 23 13:11:01 2016.
Dependencies resolved.
================================================================================
 Package           Arch         Version               Repository           Size
================================================================================
Installing:
 cuda-cudart       x86_64       1:8.0.44-4.fc24       fedora-nvidia       131 k

Transaction Summary
================================================================================
Install  1 Package

Total size: 131 k
Installed size: 536 k
Is this ok [y/N]:

This will avoid you pulling in all the libraries as before just because you need a single library. This is useful for example for programs that leverage just some part of the CUDA toolkit, like the Nvidia Performance Primitives for image and signal processing in FFmpeg, and similar things.

Bugs

Just open an issue to the specific package on GitHub.

1,271 thoughts to “Nvidia driver, CUDA tools and libraries”

  1. I’m on Fedora 23 and got a 404 when I tried to install runtime CUDA support as per the instructions:

    $ sudo dnf install -y cuda nvidia-driver-cuda
    …
    [MIRROR] nvidia-driver-cuda-358.16-1.fc23.x86_64.rpm: Status code: 404 for http://negativo17.org/repos/nvidia/fedora-23/x86_64/nvidia-driver-cuda-358.16-1.fc23.x86_64.rpm
    [FAILED] nvidia-driver-cuda-358.16-1.fc23.x86_64.rpm: No more mirrors to try – All mirrors were already tried without success

    The second time I tried it, dnf couldn’t find the package!

    $ sudo dnf install nvidia-driver-cuda
    Last metadata expiration check performed 0:14:09 ago on Tue Jan 26 23:34:32 2016.
    No package nvidia-driver-cuda available.
    Error: Unable to find a match.

    Any ideas on why I cannot install the nvidia-driver-cuda?

    Reply

  3. Hi, I have lenovo w550s laptop with f23 and i can’t get nvidia drivers to work. i tried all kinds of installation methods: official drivers 352|358|361, bumblebee, negativo17 and can’t get the drivers to work. i installed cuda and it works fine but cuda executables give errors.

    “`
    > lspci |grep -E “VGA|3D”
    00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated Graphics (rev 09)
    08:00.0 3D controller: NVIDIA Corporation GM108GLM [Quadro K620M] (rev a2)
    15:09:41seer~/Downloads
    > uname -a
    Linux seer 4.3.3-301.fc23.x86_64 #1 SMP Fri Jan 15 14:03:17 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
    15:09:47seer~/Downloads
    > rpm -qa | grep -E ‘nvidia|bumblebee|bbswitch|primus|VirtualGL’
    nvidia-settings-358.16-2.fc23.x86_64
    nvidia-driver-cuda-libs-358.16-1.fc23.x86_64
    nvidia-validation-suite-352.55-1.fc23.x86_64
    bumblebee-nonfree-unmanaged-release-1.2-1.noarch
    akmod-nvidia-358.16-1.fc23.x86_64
    nvidia-driver-NvFBCOpenGL-358.16-1.fc23.x86_64
    nvidia-xconfig-358.16-1.fc23.x86_64
    nvidia-driver-358.16-1.fc23.x86_64
    nvidia-texture-tools-devel-2.0.8-11.fc23.x86_64
    kmod-nvidia-358.16-1.fc23.x86_64
    nvidia-libXNVCtrl-358.16-2.fc23.x86_64
    nvidia-persistenced-358.16-1.fc23.x86_64
    nvidia-driver-NVML-devel-352.55-1.fc23.x86_64
    nvidia-healthmon-352.55-1.fc23.x86_64
    dkms-nvidia-358.16-2.fc23.x86_64
    nvidia-driver-libs-358.16-1.fc23.x86_64
    nvidia-driver-devel-358.16-1.fc23.x86_64
    VirtualGL-2.4-5.fc23.x86_64
    nvidia-libXNVCtrl-devel-358.16-2.fc23.x86_64
    kmod-nvidia-4.3.3-301.fc23.x86_64-358.16-1.fc23.x86_64
    nvidia-driver-cuda-358.16-1.fc23.x86_64
    nvidia-texture-tools-2.0.8-11.fc23.x86_64
    nvidia-driver-libs-358.16-1.fc23.i686
    nvidia-driver-NVML-358.16-1.fc23.x86_64
    nvidia-modprobe-358.16-1.fc23.x86_64
    15:09:55seer~/Downloads
    > sudo dnf repolist
    Last metadata expiration check performed 0:46:07 ago on Fri Jan 22 14:24:02 2016.
    repo id repo name status
    *fedora Fedora 23 – x86_64 46,074
    fedora-nvidia negativo17 – Nvidia 49
    google-chrome google-chrome 3
    rpmfusion-free RPM Fusion for Fedora 23 – Free 692
    rpmfusion-free-updates-testing RPM Fusion for Fedora 23 – Free – Test Updates 236
    rpmfusion-nonfree RPM Fusion for Fedora 23 – Nonfree 206
    rpmfusion-nonfree-updates-testing RPM Fusion for Fedora 23 – Nonfree – Test Updates 77
    *updates Fedora 23 – x86_64 – Updates 14,647

    > sudo nvidia-smi
    modprobe: ERROR: could not insert ‘nvidia’: Unknown symbol in module, or unknown parameter (see dmesg)
    NVIDIA-SMI has failed because it couldn’t communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.

    “`

    I will appreciate any kind of guidance. Thank you.
    and thank you for creating this project.

    Reply

  5. I have updated to Fedora 23 from 22. Since completing the update instead of gdm loading I get the “oh no! something has gone wrong” message. I’ve tried the wayland uncomment in gdm custom.conf mentioned above. I am using a GTX650 on a desktop running kernel 4.3. Any suggestions as to what I can do beyond removing and reinstalling the nvidia drivers.

    Reply

  6. Has anyone got this to work with RHEL/Centos 7.2 yet? The packages work well on my machine with kernel 3.10.0-229.20 but no matter what I do they fail on 3.10.0-327.4.4 with:

    NVIDIA: Failed to initialize the NVIDIA kernel module.

    Reply

  7. Hi,

    First of all I would like to thank you for this repository. It’s really great!
    I’m on Fedora 22 with one Nvidia GTX 770 and until now it was working perfectly. But yesterday I updated my system which in particular updated the kernel from 4.1.6 to 4.2.8 and gcc from 5.1.1 to 5.3.1. And now the system doesn’t start anymore.
    When I update the kernel and reboot, the kernel fails to load the modules but that’s normal. I need to sign the nvidia and nvidia-uvm because of the BIOS secure boot. This always solved the problem before but this time it seems to not be enough.

    uname -r: 4.2.8-200.fc22.x86_64
    journalctl -b Xorg.0.log and akmods.log can be found here:
    https://gist.github.com/anonymous/e2600e4e6c07d44d55f2

    It seems it is not able to find nvidia-uvm but the module is there and signed correctly. With modinfo I can see they are in /lib/modules/4.2.8-200.fc.22.x86_64/extra/nvidia/nvidia(-uvm).ko

    Also there is a complain about Wayland and GDM in the logs attached and I saw in an earlier post that it should be fixed.

    What should I do? If you need other information I’m happy to share anything you need.

    Thanks a lot in advance!

    Reply

    1. Curious. Does rebooting in the previous kernel fix the issue? There are also systemd errors. Was it also upgraded?

      Reply

      1. I just found the solution by chance. There is apparently a new module called nvidia-modeset. Since I only signed nvidia and nvidia-uvm but not this one it was not able to load it. Somehow it was not mentioned in the log. Is this something new?

        Thank you anyway. So happy to see my screen again 😀

        Reply

          1. I am running Fedora 22. But I jumped from 355.11 to 358.16 when I updated my system. So that’s why. Thank you again!

  8. If anyone has been having trouble with modules being built by DKMS with the wrong module magic, for example, after upgrading the kernel, it seems there’s an error in the DKMS make command. It causes modules to be built for the running kernel regardless of the target kernel chosen, and then fail to load at your next boot.

    To fix it temporarily you can create a file at /etc/dkms/nvidia.conf with the following content (delimited by the dashes, but don’t actually include them)

    MAKE[0]="'make' -j2 module SYSSRC=${kernel_source_dir} IGNORE_XEN_PRESENCE=1 IGNORE_PREEMPT_RT_PRESENCE=1"

    It ensures the builds always use the correct kernel sources.

    Reply

    1. Oops I ended up removing the dashes accidentally, but the content is just that one like with the make command.

      Reply

    2. Thanks for spotting it! I’ve added the parameter to the dkms.conf file that is bundled with the dkms-nvidia package.
      That was present before Nvidia removed the instantiated module builds from their makefile and I probably removed that by accident when rewriting it for the new build system.

      Reply

  9. Hi, thank you for this repository. I’m using it for installing nvidia drivers without problem. But now I’m trying to install cuda-devel and I encountered following problem with nvcc when trying to compile some pyCuda tests.

    nvcc --cubin -arch sm_52 -I/usr/lib64/python2.7/site-packages/pycuda-2015.1.3-py2.7-linux-x86_64.egg/pycuda/cuda kernel.cu]
    nvcc fatal : Path to libdevice library not specified

    Most solutions for this problem I found with google are updating nvcc.profile, but I can’t find it with where is.

    Reply

    1. Ignore my previous post. Today it is working without problems. I don’t know what happened, maybe new version of gcc solved this problem.

      Reply

      1. Actually it’s working just because you freshly logged in your system.
        Cuda base package includes an environment profile that is sourced when you start a new login shell:

        # cat /etc/profile.d/cuda.sh
        [ -x /usr/bin/nvcc ] && export NVVMIR_LIBRARY_DIR=/usr/share/cuda
        [ -x /usr/libexec/cuda/open64/bin/nvopencc ] && export PATH=$PATH:/usr/libexec/cuda/open64/bin
        [ -d /usr/include/cuda ] && export CUDA_INC_PATH=/usr/include/cuda

        Without it, you get the error you posted.

        Reply

  11. Hello i am using your nvidia repo in my fedora 23 installation. I am using the akmod kernel module. Everytime when a kernel update shows up if i install it my computer boots but i see an error that is saying “failed to load kernel module bla bla” but it boots. whats this? for example this happened when i updated my kernel to the latest 4.2.6.301

    Reply

        1. The first: /var/log/Xorg.0.log (or some old logs).
          The second: /var/cache/akmods/akmods.log
          For kernel packages, at least:
          $uname -r
          and
          $rpm -qa kernel

          Try out a terminal.

          Reply

  12. Most happily I’ve received my new thinkpad but am having issues with using the proprietary driver. Mostly because I don’t really understand how to deal with dual GPUs. I’m running a new installation of fc23.

    lspci output:

    00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated Graphics (rev 09)
    08:00.0 3D controller: NVIDIA Corporation GM108GLM [Quadro K620M] (rev a2)

    I understand that the proprietary driver should “provide intelligent powering down and up of the discrete nVidia card” but I can’t figure out how to get kmod-nvidia to replace nouveau. Any suggestions would be greatly appreciated.

    And thank you for your work.

    Reply

      2. It appears that the kernel is unaware of the fact that I have a discrete GPU. Or maybe the kernel knows but the DM doesn’t. Not sure what’s happening. lsmod | grep i915 says:

        i915 1110016 9
        i2c_algo_bit 16384 2 i915,nouveau
        drm_kms_helper 118784 2 i915,nouveau
        drm 335872 12 ttm,i915,drm_kms_helper,nouveau
        video 36864 3 i915,thinkpad_acpi,nouveau

        So the module is loaded but output from xrandr –listproviders says:

        Providers: number : 1
        Provider 0: id: 0x49 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 6 associated providers: 0 name:Intel

        I placed “video=VGA-2:d” in the kernel command line but nothing happened. Could it be that lspci returns a “3D controller” for the chipset instead of “VGA controller?”

        Additionally, there doesn’t exist a /sys/kernel/debug/vgaswitcheroo/switch file.

        I’m about to try only using the nvidia GPU standalone per your instructions but I’m pretty befuddled. Any thoughts are appreciated.

        Reply

        1. The fact that is listed as a 3d controller it probably means that simply it has no outputs attached to it.

          The fact that you’re not seeing the vgaswitcheroo folder means the arbiter module is not loaded (vgaarb). Don’t know why, that is built in the kernel, so maybe your system is not recognized properly. At this point, without a mechanism to turn on/off the cards properly, you’re welcome to try using the nvidia driver directly configured with Output Sink.

          Make sure that you do not have additional spurious kernel parameters around.

          Reply

          1. Thank you.
            dmesg | grep vgaarb says:

            [ 0.140863] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=mem,locks=none
            [ 0.140866] vgaarb: loaded
            [ 0.140867] vgaarb: setting as boot device: PCI:0000:00:02.0
            [ 0.140868] vgaarb: bridge control possible 0000:00:02.0
            [ 1.327250] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=mem

            so vgaarb is there but, as you say, the system isn’t properly recognized. Perhaps I’ll look at compiling a kernel with a patch for recognizing a “3d Controller” I think I read about somewhere, if I can find it. And still probably try out the nvidia driver standalone.

            Also, I noticed that there was an xorg conf file, 10-disable_prime.conf which I imagine is there for the same reason. I rendered it unusable but, since it’s clearly a lower level issue, nothing happened, naturally.

            Thanks for you thoughts and comments.

          2. Oh yeah. I installed bumblebee and this does show up in dmesg:

            [ 3.861785] bbswitch: Found integrated VGA device 0000:00:02.0: \_SB_.PCI0.VID_
            [ 3.861790] bbswitch: Found discrete VGA device 0000:08:00.0: \_SB_.PCI0.PEG_.VID_

  13. I tried installing nvidia-driver through your repo on Fedora 23, but after rebooting I end up getting a black screen.
    How can I fix this?

    Reply

  14. Regarding the libva-vdpau-driver dependency, I consistently get crashes in Firefox with the crash reports consistently pointing to libvdpau_nvidia.so.358.16 as the culprit. Here are the facts:

    1) I don’t have an intel CPU or AMD graphics card.
    2) Most people point to either Flash or HTML5 being the cause of the crash, however, I seem to crash even if Flash is disabled.
    3) I’ve disabled hardware acceleration in flash.
    4) Using RPM Fusion makes no difference. I can definitely say that lib-vdpau-driver is responsible for the crashes.

    Now it seems like people keep throwing bad advice around, from removing Gstreamer to removing Libva. As far as I can see, it has nothing to do with Gstreamer. I can run Chromium with lib-vdpau-driver installed fine as well as VLC. It’s only Firefox that crashes.

    Judging from the trail of zombie bug reports and the massive amount of spam in said bug reports from clueless users, it doesn’t look like this will be fixed anytime soon.

    Therefore, I respectfully ask that you remove the dependency and let us decide whether or not to install the lib-vdpau-driver. Thank you.

    Reply

  16. I’m having issues getting the drivers to work on Fedora 23 Cinnamon Spin. All the packages install correctly, but on reboot Cinnamon crashes and goes into fallback mode. When trying to run glxgears I get the following error:
    Xlib: extension “GLX” missing on display “:0”.
    Error: couldn’t get an RGB, Double-buffered visual

    My laptop is an ASUS N550JV, so is an optimus with a 750m. Any ideas or suggestions would be greatly appreciated.

    Reply

      1. Thanks for the reply. I’ve just moved over from Ubuntu and using that I was able to get the drivers to work out-of-the-box on my laptop so didn’t realise the full implications of running optimus. Fortunately, I’ve managed to get things working using bumblebee for now so am happy.

        Cheers.

        Reply

  18. I can’t log into Fedora 23 without changing hitting ctrl+alt+F2 once after putting my login/password in at GDM. This is after the latest 358.16 release (and with SELinux still set to permissive).

    Also having a fair few crashes in Steam with the Nvidia 358.16 driver. Simple things like adding a game to a category cause it to exit. I can’t seem to run any unity based games (such as Shadowrun, Satellite Reign, etc). They just exit before loading.

    Using the 355 driver was fine, so I think perhaps the 358 driver is the issue. Any chance we can get the 355 driver in the Fedora 23 repository? At least until the fixes are through for the 358 series.

    Alternatively – if someone has a workaround for these issues, I’d love to hear about it.

    Reply

    1. Driver 355 has been superseded by 358 (it is the new short lived version) and there is no support for X.org 1.18 nor for the SELinux policy workaround in it.

      Reply

    2. Hi,

      as for the gdm login issue I know how to handle this. There seems to be a bug with gdm and wayland on some systems. I had the same issue on my workstation. Laptop seems fine though.

      Alt + F2 and log in with your credentials. As root, edit /etc/gdm/custom.conf and uncomment #WaylandEnabled=false. That disables wayland for the login and runs now on X.

      Good luck and report back if this did solve the issue.

      Reply

      1. Actually this should be the case if you are using binary drivers; X.org will switch to “normal” mode, run as root and GDM etc. are not started under Wayland.

        Reply

  19. When installing to we have to specify which driver we want? Confused on how to get negativo nvidia driver package up and running. Tried in once, but reboot came back with “something went wrong”

    Reply

  20. Im, find now ver. driver Linux x64 (AMD64/EM64T) Display Driver NVIDIA Certified 358.16
    Added support for X.Org xserver ABI 20 (xorg-server 1.18).

    Reply

  23. Any ETA for 352.63 on F23? I don’t mean to rush anything, just trying to schedule when I will upgrade to F23 (decided to wait until proper support for Xorg 1.18 was out).

    As always, thank you so much for all your work on these repos! =)

    Reply

    1. They will not end up in Fedora 23, but they are already in the repositories for RedHat/CentOS 6/7. Please see the table in the Nvidia driver page.

      Reply

      1. Sorry, didn’t realize they were not meant for F23. I just saw 358.16 is out, and you’re already working on them. Cool! =)

        Reply

        1. Actually the source tarballs for nvidia-{xconfig,modprobe,settings,persistenced} have not been pushed to the FTP nor to the Github repositories yet. 352.64 is also missing from Github, but at least is available from the FTP.

          Reply

          1. They appear to have been now, not in the Github however. I think we’re all pretty excited since 358.16 is a significant update. Looking forward to the next push to the repo.

  24. I had some problems with nvidia-driver-351.11-4 and kernel-4.2.6-200 using dkms on fedora 22.

    First a “dnf update” said it could not find an updated driver on the mirror. I had to uninstall dkms-nvidia and nvidia-driver and install again for dnf to be happy.

    Second the kernel module for 4.2.6 was not built when the new driver packages were installed. GNOME presented the “Oops something bad has happened…” error. I had to uninstall kernel-4.2.5 and reboot for the module to be built and GNOME to run correctly.

    I have been through a few kernel updates without this happening so it seems it might have been a result of recent packaging changes?

    My install is fedora 22 Workstation x86_64 and the negativo17/fedora-nvidia repository is the only non-fedora repository I have on the system.

    Reply

    1. This can happen when installing the driver and update the kernel at the same time. The new module is built and THEN the new kernel is installed for which a module is not built. Was that the case?
      I might need to look if I can add to the DKMS driver the trigger script that is in the aKMOD variant.

      Reply

      1. That seems a likely cause of the problem. I will take your assessment as being correct.

        A fix would be nice but at least I was able to get things working so it is not a big problem.

        Reply

      2. Same problem here: kernel 4.2.6 installed, system rebooted, Gnome error. By looking at the “modinfo nvidia” output, the module is in place but it has the wrong vermagic (for the 4.2.5 kernel). I suspect that DKMS skipped the rebuilding and just installed the already built module for the old kernel.

        Reply

  27. Hi!!

    First of all thanks for your work!

    Also: are there any plans for updating the 340xx repo to fedora 23? Or have you stopped maintaining the legacy driver?

    Thanks!

    Reply

  28. Heya,

    Installed driver :

    dnf -y install nvidia-driver akmod-nvidia kernel-devel nvidia-driver-libs.i686

    … rebooted but had to create xorg .conf

    I get this error with games from wine :

    err:winediag:X11DRV_WineGL_InitOpenglInfo Unable to activate OpenGL context, most likely your 32-bit OpenGL drivers haven’t been installed correctly

    Can you help ?

    Reply

    1. No, I’m sorry. Everybody would like to have a different version on a different system. It’s not maintainable for me.

      Reply

  31. Hi there,

    Thanks for providing the driver for F23, however I have a few issues with it.
    First, the gdm login screen shows up with only a grey background, but I can:
    – either hit enter, and my password, then I get logged
    – either alt+ctl+f2, and then back to alt+ctl+f1, then it shows the usual gdm login icns, but nothing can get clicked. I can however hit Enter + type my login, and get through to my gnome session.

    Then, the gnome session lasts only for a few moments. For instance starting firefox of google chrome will crash the session.

    Would you like some logs or more details ?

    Reply

      1. Thanks for the hint! It does sort out the login screen issue, but the gnome session still crashes after a few random minutes

        Reply

        1. I’ve run into a similar issue after login the gnome session starts to load, apparently crashes, then returns to the login screen.

          Reply

  32. Tried installing on fedora 23, but after rebooting, cinnamon keeps crashing. Any idea why this is or how I can fix it?

    All I did was installing nvidia-drive akmod-nvidia and kernel-devel and then reboot, is there anything else I should have done?

    Reply

  33. Legacy drivers 340.xx don’t appear to exist for FC23 yet.

    causing me a bit of a problem as i’m using a somewhat older GPU on one of my systems.

    Reply

    1. I’m currently travelling, I will update them through the weekend along with the latest packaging enhancements from the 358.x branch.
      Don’t expect anything spectacular, as there is no support for X.org 1.18 nor kernel 4.2 in the legacy drivers, I don’t even know if it works.

      Reply

      1. You’d think it would be the kernel & X.org’s job to make that work given these are LEGACY drivers, but still somewhat recent enough to expect users to exist, and unlikely to be updated by the manufacturers specifically for linux requirements.

        Reply

      2. still getting messages about missing repodata/repomd.xml

        Will you put an update posting on the site when you do push this?

        Reply

  34. Error: Transaction check error:
    file /usr/share/man/man3/deprecated.3.gz from install of cuda-devel-1:7.0.28-1.fc23.x86_64 conflicts with file from package qwt5-qt4-devel-5.2.2-28.fc23.x86_64

    just thought you should know

    Reply

  35. My nouveau drivers came back with the dnf upgrade from F22 to F23, which prevented X11 from starting. I removed them with “dnf erase xorg-x11-drv-nouveau”.

    Reply

    1. There is no need to remove them, they are not loaded when installing the drivers. Keep in mind though that Video Driver ABI = 20 (X.org 1.18) is not supported by the Nvidia drivers yet.

      Reply

  36. Cannot make it work on asus with 740m.
    Get error
    (EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not found), but i see nvidia in lsmod.
    Any ideas?

    Reply

      1. Fedora 22
        kernel 4.2.3
        As for config – I haven’t changed anything – stanard 99-nvidia-modules.conf and 99-nvidia-driver.conf. Xorg logs show only these errors:
        (EE) Failed to load module “nv” (module does not exist, 0)
        (EE) [drm] KMS not enabled
        (EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not found)
        Latest driver version, installed today (355.11)
        Yes, multicard, with Intel. Maybe its impossible with asus and optimus?

        Reply

  39. Seems on F23 im hitting a snag as 355 exists on the repos but nvidia-settings-358 🙁

    1✗ ~/src $ sudo dnf install nvidia-driver –allowerasing
    Last metadata expiration check performed 0:15:03 ago on Tue Oct 27 09:15:52 2015.
    Error: nothing provides nvidia-settings = 2:355.11 needed by nvidia-driver-2:355.11-3.fc23.x86_64

    Reply

  40. I’m on Fedora 22. The driver is working fine and has been for months, but I recently tried to open nvidia-settings and got this series of error messages (and no nvidia-settings):

    » nvidia-settings

    ERROR: The requested operation is not available on target device

    ERROR: The requested operation is not available on target device

    ERROR: The requested operation is not available on target device

    ERROR: The requested operation is not available on target device

    ERROR: The requested operation is not available on target device

    nvidia-settings: libXNVCtrlAttributes/NvCtrlAttributesNvml.c:1616: NvCtrlNvmlGetValidAttributeValues: Assertion `ret2 == NvCtrlAttributeNotAvailable’ failed.
    [1] 5825 abort (core dumped) nvidia-settings

    Reply

    1. That’s due to the NVML linking, if the card does not support it, you will get the error. What card do you have?

      Reply

      1. It’s a GTX 660. Nvidia-settings used to work fine with this same card. I have an extra .nvidia-settings-rc at a different location that is used by a script that calls “nvidia-settings –config=$that_other_path -l”. The script still works, and that file was last modified (with the working GUI) on October 24, 2014. I don’t edit my .nvidia-settings-rc manually, so unless there’s some circumstance where it gets automatically modified without the settings being changed in the GUI, the last time it worked was Aug 16 of this year, the last modified time of my .nvidia-settings-rc at the default location.

        It still crashes with “nvidia-settings –no-config”. Nvidia-smi does not have any problems.

        Reply

      2. I seem to have the same problem:

        % nvidia-settings
        nvidia-settings: libXNVCtrlAttributes/NvCtrlAttributesNvml.c:1616: NvCtrlNvmlGetValidAttributeValues: Assertion `ret2 == NvCtrlAttributeNotAvailable’ failed.
        zsh: abort (core dumped) nvidia-settings

        Fedora 23, NVIDIA driver 358.16, Xorg 1.18.0, two GTX 970 cards. It used to work with Fedora 22 and RPM Fusion packaged drivers.

        Reply

          1. It’s ok… but it still doesn’t work. It looks like NVML_AVAILABLE=0 is needed, not NVML_AVAILABLE=1. 😉

  41. I’m on Fedora 22 x64. It’s my first install of Fedora and I test it because I want to switch to it. I was on Xubuntu before, and I have to say that I tried many different Nvidia drivers installation.

    Before knowing your repo I tried the Nvidia driver work from the RMP-Fusion repo (sudo dnf install akmod-nvidia “kernel-devel-uname-r == $(uname -r)”) but I couldn’t make it work (black screen at boot or something like that).

    After that I tried the Nvidia driver from your repo. After many test (RPM-Fusion, Your Repo, Nouveau drivers) the only working way to install the Nvidia driver is now “sudo dnf install nvidia-driver”.

    I don’t know why but this don’t work anymore (“sudo dnf install nvidia-driver akmod-nvidia kernel-devel nvidia-driver-libs.i686”) (black screen at boot or something like that).

    All that to say that I made a lot of test but I don’t think it infer with the crash.

    So, I agree that VAAPI should not crash, but if there is a bug it’s safer to remove the dependency, at least for now.

    The crash happen on Youtube with the HTML5 player if I seek in the video or if I switch to fullscreen.

    Reply

    1. Just to be clear the first time I tried your drivers the installation with this command (“sudo dnf install nvidia-driver akmod-nvidia kernel-devel nvidia-driver-libs.i686”) works perfectly. No problem with your Nvidia drivers 😉

      Reply

  42. Hello,
    I installed the Nvidia drivers but Firefox keep crashing now. It seems to work if I uninstall them.
    I’m new to Fedora. I used this command to install the drivers:
    $ sudo dnf install nvidia-driver akmod-nvidia kernel-devel nvidia-driver-libs.i686
    I have found this bug report but I don’t know if it’s related: https://bugzilla.redhat.com/show_bug.cgi?id=1219068
    What can I do ?

    Reply

      1. The Firefox devs say that I need to remove libva-vdpau-driver and closed the bug.

        I said to them that I disagree because you shouldn’t have to remove softwares to make an other soft work. Plus, I use VDPAU in MPV so I don’t want to remove it. And even if I try to remove libva-vdpau-driver the whole Nvidia driver will be removed.

        If you agree with me don’t hesitate to say it to them:
        https://bugzilla.mozilla.org/show_bug.cgi?id=1192900

        Reply

        1. Ok I had an explanation and it’s not Firefox that crash but :
          “It is gstreamer itself that is crashing because one of its plugin, designed by Intel to work with their VAAPI adapter happen to call another piece of software that is using libva-vdpau which itself is crashing. Someone thought it would be a good idea to make a nvidia card appear like an intel one.”

          And he said “I’m not sure what distribution you are using, but I don’t see libva-vdpau-driver being a dependency for the vdpau drivers. It’s should be the other way round. If libva-vdpau-driver is a dependency for the nvidia drivers, you should report that bug to the packager.”

          So maybe we should avoid to have libva-vdpau-driver as a dependency of the Nvidia driver ?

          https://bugzilla.mozilla.org/show_bug.cgi?id=1192900#c13

          Reply

          1. That’s interesting. If I remove that package as a dependency, would mean that out of the box you would not be able to use VAAPI acceleration for programs that use that (instead of VDPAU) with Nvidia drivers.
            As a side note, whether this is good or bad, the component using VAAPI should not crash.

            It’s not crashing for me, btw. Can you tell me which distribution are you using and point me to the site that is making your Firefox crash?

            Thanks.

  43. Hi.

    I’m trying to install you driver, but it look like the kernel module is trying to compile for the 4.0.2 kernel instead of the 4.2.2 kernel, making the xserver crash.

    Reply

  45. However I tried I could not make Nvidia drivers work on Fedora 23 beta. (including RPMFusion, which crashes the system completely and the only way it can be fixed is using `chroot` on system drive and externally removing installed packages)

    With Negativo, after `dnf` installation, kmod-x.xxx.xxx package is automatically installed. (can see this in `dnf history`). When I install `nvidia-driver`, `akmod-nvidia` is pulled from the RPMFusion repo.

    After reboot things seem to work but when I login to Gnome it hangs a bit and then returns with a crash to login page over again.

    I tried manually disabling `nouveau` manually in grub.cfg and blocklisting it in modprobe but nothings seems to work.

    Any advice please?

    P.S. Thank you very much for your work!

    Reply

  46. Hi,
    im asking you to make some legacy repo for fedora 23 nvidia drivers since my card is not in supported list for 355 .
    Ive made changes in you 340 repo file and installed the one from fc22 but it gave the same result, perhaps i did something wrong.
    this is what it show
    “Oh no! Something has gone wrong. A problem has occurred and the system can’t recover. Please log out and try again.”

    Reply

  47. First, I really love what you have done with the nvidia driver. I have one request for RHEL6: nvidia-driver-352.41-1.el6.
    It’s putting blacklist-nouveau.conf in /usr/lib/modprobe.d/ instead of /etc/modprobe.d/ On RHEL6, dracut isn’t using that file. If I copy it to /etc/modprobe.d/ dracut works as expected.

    Reply

    1. Thanks for reporting, I really missed that. Will push an update in the next days. Sorry for the late reply & thanks again!

      Reply

      1. Fantastic. I should mention that nvidia-uvm.conf in the nvidia-driver-cuda package has the same problem.
        I also found the binary driver installs libGL.so and libEGL.so. Maya2016 doesn’t run without them, so if we could get those links added to nvidia-driver-libs, that would be awesome. Last issue is that nvidia-settings only gets installed if I install nvidia-driver-cuda. If I want nvidia-smi, but not the cuda driver (or nvidia-uvm kernel module) I am unable to do that. Could nvidia-smi be moved to nvidia-driver instead of nvidia-driver-cuda? I apologize for all this at once, but if all these issues were resolved, I’d be a super happy camper.

        Reply

          1. You mean the fact that Maya 2016 requires both libGL.so and libEGL.so symlinks?
            That’s not correct, as unversioned system libraries are available only in devel subpackages, and Maya should not require them.

            To workaround this, you can just install nvidia-driver-devel.

          4. Using Maya 2016 on CentOS 7.5 with the Negativo rolled Nvidia drivers, we were having Maya fail to launch. It turns out the libraries under /usr/lib64/libglvnd
            libGL.so.1.0.0
            libEGL.so.1.0.0
            are only symlinked to
            libGL.so.1
            libEGL.so.1
            Once we symlinked them to
            libGL.so
            libEGL.so

            [root@test16 libglvnd]# ls -la /usr/lib64/libGL.*
            lrwxrwxrwx 1 root root 14 Aug 6 11:08 /usr/lib64/libGL.so -> libGL.so.1.2.0
            lrwxrwxrwx 1 root root 14 Aug 6 11:08 /usr/lib64/libGL.so.1 -> libGL.so.1.2.0
            -rwxr-xr-x 1 root root 480816 Apr 11 09:25 /usr/lib64/libGL.so.1.2.0
            [root@test16 libglvnd]#

            [root@test16 libglvnd]# ls -la /usr/lib64/libEGL.*
            lrwxrwxrwx 1 root root 15 Aug 6 11:11 /usr/lib64/libEGL.so -> libEGL.so.1.0.0
            lrwxrwxrwx 1 root root 15 Aug 6 11:08 /usr/lib64/libEGL.so.1 -> libEGL.so.1.0.0
            -rwxr-xr-x 1 root root 227792 Apr 11 09:25 /usr/lib64/libEGL.so.1.0.0
            [root@test16 libglvnd]#

            Maya then launches fine.
            Can this be fixed in the next Negativo release?

          5. Hello, this is not related to the way the drivers are packaged. First of all Maya should look for the versioned libraries (libGL.so.1 and libEGL.so.1) and not the unversioned ones. Second thing, these libraries and links are not part of the Nvidia drivers. To get the symlinks, you can just install libglvnd-devel on Fedora or mesa-libGL-devel and mesa-libEGL-devel in CentOS.

          6. Thanks for replying, I agree with you that MAYA should use versioned libraries, but for this version I doubt Autodesk will make any changes.
            For the second part, we already have these packages (mesa-libGL-devel and mesa-libEGL-devel) installed, it didn’t help, since those are for MESA OpenGL.
            I had to install the libglvnd-devel package, which installs the correct symlinks here
            /usr/lib64/libglvnd/libEGL.so
            /usr/lib64/libglvnd/libGL.so
            Now Maya launches without issue.

            Thanks

  49. getting warnings in Xorg.0.log on fedora 23 about the ABI.

    warning: this version of xorg has ABI 22 but the driver requires ABI 20. driver will continue to load but will behave strangely.

    this is with 355.11

    Reply

    1. Nvidia drivers do not support (yet) X.org server version 1.18. See /etc/X11/xorg.conf.d/99-nvidia-ignoreabi.conf on your system.

      Reply

Leave a Reply