Nvidia driver, CUDA tools and libraries

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 system	CentOS / RHEL	Fedora	rawhide
Driver branch	Long Lived	Short Lived Long Lived	Short Lived Long Lived Beta
Video Codec SDK	Yes	Yes	Yes
Architectures: x86_64	Yes	Yes	Yes
Basic nvidia driver: nvidia-driver nvidia-driver-libs nvidia-libXNVCtrl nvidia-kmod-common	Yes	Yes	Yes
CUDA libraries and tools: nvidia-driver-cuda nvidia-driver-cuda-libs nvidia-driver-NVML nvidia-persistenced	Yes	Yes	Yes
OpenGL Framebuffer Capture: nvidia-driver-NvFBCOpenGL	Yes	Yes	Yes
Nvidia tools: nvidia-modprobe nvidia-settings nvidia-xconfig	Yes	Yes	Yes
Binary kernel modules (kABI): kmod-nvidia	Yes	No	No
DKMS kernel modules: dkms-nvidia	Yes	Yes	Yes
aKMOD kernel modules: akmod-nvidia	No	Yes	Yes
32 bit compatibility on x86_64: nvidia-libXNVCtrl nvidia-driver-libs nvidia-driver-cuda-libs nvidia-driver-NVML	Yes	Yes	Yes
Development nvidia-driver-devel nvenc nvenc-samples	Yes	Yes	Yes
GLVND libraries	Yes	Yes	Yes
VDPAU libraries	Yes	Yes	Yes
EGLStream-based Wayland external platform	Yes	Yes	Yes
GBM EGL external platform library	Yes	Yes	Yes

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,258 thoughts to “Nvidia driver, CUDA tools and libraries”

Eduard Šurina says:

March 22, 2017 at 9:39 am

Hi !

After update Mesa pckgs I’ ve got transaction check error:

file /usr/lib64/libGLX_indirect.so.0 from mesa-libGL-13.0.4-3.fc25.x86_64 is in conflict with file from package nvidia-driver-libs-2:378.13-3.fc25.x86_64
file /usr/lib/libGLX_indirect.so.0 from mesa-libGL-13.0.4-3.fc25.i686 jis in conflict with file from package nvidia-driver-libs-2:378.13-3.fc25.i686

Reply
1. slaanesh says:
  
  March 22, 2017 at 9:50 am
  
  Fixed in the build that is being pushed now.
  
  Reply
  1. Eduard Šurina says:
    
    March 22, 2017 at 10:26 am
    
    THNX!
    
    It works for me now.
    
    Reply
Joao says:

March 21, 2017 at 1:33 pm

Thank you for this. I had problems with Fedora 25 and had to install with the troubleshooting option which sets a nomodprobe option at log in. After installation I installed the drivers from this repository, I seem to get the backgrounds at a good resolution but no windows! I can even log in and get the default fedora 25 background up but again no windows. Do you know what might be happening?

Reply
Ville says:

March 13, 2017 at 5:18 pm

Thank you from Great Work.

I have Optimus question. I’m running Lenovo W540 Quadro K2100M / Intel HD Graphics 4600. Everythinig works out of the box just great with 3 monitor setup and performance is good.

My problem… I would love to make Prime Synchronization to work so that Screen Tearing is only a bad memory. I have been following ( https://devtalk.nvidia.com/default/topic/957814/linux/prime-and-prime-synchronization ) where is all sorts success and not so much success stories… it starts to feel that Nvidia drivers are quite mature for Prime sync, but just some configuration/automation is missing(?)

I have clean Fedora 25 install with latest patches + Negativo17 Nvidia repo. Does anyone has some easy step-by-step guide for Prime sync? Or should I wait bit more?

Reply
1. slaanesh says:
  
  March 13, 2017 at 8:06 pm
  The information you need is in the file /usr/lib/modprobe.d/nvidia.conf.
  Just do the following as root:
```
echo "options nvidia-drm modeset=1" > /etc/modprobe.d/nvidia.conf
```
  and reboot. If you have success, please give feedback and I will enable it by default on /usr/lib/modprobe.d/nvidia.conf. The reports I have are too scarce to enable by default.
  Reply
  1. Ville says:
    
    March 14, 2017 at 12:07 pm
    
    Things went to deep south. Fedora didn’t boot after that command… on boot it stopped on “Starting Switch Root…”
    
    https://www.dropbox.com/s/lwye1wca0h8ixdx/2017-03-14%2012.03.49.jpg
    
    Reply
    1. espionage724 says:
      
      March 15, 2017 at 3:06 pm
      
      You need “needs_root_rights = yes” in “/etc/X11/Xwrapper.config” with KMS enabled or else modeset won’t work (iirc, X doesn’t fallback automatically to root X with NV’s driver with KMS enabled which causes it to not boot). This one-liner works:
      
      echo ‘needs_root_rights = yes’ | sudo tee –append ‘/etc/X11/Xwrapper.config’ > ‘/dev/null’
      
      Reply
      1. slaanesh says:
        
        March 23, 2017 at 10:47 am
        
        There should be no need for that. When the Nvidia driver is loaded, xorg does switch to using root for the X server.
larrangeur says:

March 10, 2017 at 8:28 am

Hope I post the good logs but since 4.9.13 I can’t log anymore with nvidia driver 378.13 (fc25 – gtx 960)

[code]08:18:07 kernel: nvidia-nvlink: Unregistered the Nvlink Core, major device number 243
08:18:07 kernel: NVRM: No NVIDIA graphics adapter probed!
08:18:07 kernel: NVRM: Try unloading the conflicting kernel module (and/or
NVRM: reconfigure your kernel without the conflicting
NVRM: driver(s)), then try loading the NVIDIA kernel module
NVRM: again.
08:18:07 kernel: NVRM: This can occur when a driver such as:
NVRM: nouveau, rivafb, nvidiafb or rivatv
NVRM: was loaded and obtained ownership of the NVIDIA device(s).
08:18:07 kernel: NVRM: The NVIDIA probe routine was not called for 1 device(s).
08:18:07 kernel: nvidia-nvlink: Nvlink Core is being initialized, major device number 243
08:18:06 kernel: nvidia-nvlink: Unregistered the Nvlink Core, major device number 243
08:18:06 kernel: NVRM: No NVIDIA graphics adapter probed!
08:18:06 kernel: NVRM: Try unloading the conflicting kernel module (and/or
NVRM: reconfigure your kernel without the conflicting
NVRM: driver(s)), then try loading the NVIDIA kernel module
NVRM: again.
08:18:06 kernel: NVRM: This can occur when a driver such as:
NVRM: nouveau, rivafb, nvidiafb or rivatv
NVRM: was loaded and obtained ownership of the NVIDIA device(s).
08:18:06 kernel: NVRM: The NVIDIA probe routine was not called for 1 device(s).
08:18:06 kernel: nvidia-nvlink: Nvlink Core is being initialized, major device number 243
08:18:06 kernel: nvidia: module verification failed: signature and/or required key missing – tainting kernel
08:18:06 kernel: Disabling lock debugging due to kernel taint
08:18:06 kernel: nvidia: module license ‘NVIDIA’ taints kernel.
08:18:06 kernel: nvidia: loading out-of-tree module taints kernel.
08:18:06 kernel: [drm] Initialized nouveau 1.3.1 20120801 for 0000:01:00.0 on minor 0
08:18:06 kernel: nouveau 0000:01:00.0: fb0: nouveaufb frame buffer device
08:18:06 kernel: Console: switching to colour frame buffer device 240×75
[/code]

Reply
1. slaanesh says:
  
  March 13, 2017 at 8:08 pm
  It seems you still have a conflicting driver loaded. The nvidia-driver package correctly disables Nouveau:
```
$ cat /usr/lib/modprobe.d/nvidia.conf 
blacklist nouveau
# Uncomment the following line to enable kernel modesetting support.
# There is NO graphical framebuffer (like OSS drivers) at the moment; this is
# only for Wayland. Leave disabled if you plan to use SLI.
#options nvidia-drm modeset=1
```
  So it’s some additional configuration in your system.
  Reply
  1. larrangeur says:
    
    March 14, 2017 at 11:51 am
    
    In fact, I disabled Wayland in gdm custom.conf and now I can log correctly, where before It crashes back to gdm again and again
    
    Reply
    1. engmia says:
      
      April 1, 2017 at 4:03 pm
      
      From a user perspective (although it doesn’t seem like that’s the problem from the logs) I’ve found that some Gnome Extensions cause Wayland to hang.
      
      For example, a problematic extension for me is Freon. Whenever I have it enabled, logging into a Wayland session causes the system to hang.
      
      Works fine on X sessions, which you are forcing by WaylandEnable=false in custom.conf
      
      So if you have any Gnome Extensions, I think it’s worth trying with all of them turned off, any extra packages modifying the gnome-shell might conflict as well I guess (I underline the I guess part).
      
      Reply
David says:

March 9, 2017 at 6:42 pm

Yesterday I updated (via the gnome package manager) the kernel to 4.9.13-200-fc25.x86_64 and nvidia functionality disappeared. On checking I found no nvidia*.ko modules user /usr/lib/modules/…/extras
and I hunted for error logs but found none (I am not sure I looked in the right places)

I turned on verbose output in dkms’ framework.conf and tried
sudo /usr/lib/dkms/dkms_autoinstaller start
and it returned immediately without error

dkms status returns nothing as if there are no modules to be compiled

nvidia-settings returns
ERROR: Unable to find display on any available system

So, it looks to me like dkms isn’t working.

I see 2 dkms-related packagers are currently installed:

rpm -qa | grep dkms
dkms-nvidia-378.13-2.fc25.x86_64
dkms-2.3-1.20161202gitde1dca9.fc25.noarch

rpm -qi dkms-nvidia-378.13-2.fc25.x86_64
Name : dkms-nvidia
Epoch : 2
Version : 378.13
Release : 2.fc25
Architecture: x86_64
Install Date: Wed 08 Mar 2017 07:54:39 PM EST
Group : Unspecified
Size : 21895744
License : NVIDIA License
Signature : DSA/SHA1, Thu 23 Feb 2017 05:04:43 AM EST, Key ID 14386362f90c0e97
Source RPM : dkms-nvidia-378.13-2.fc25.src.rpm
Build Date : Thu 23 Feb 2017 04:24:28 AM EST
Build Host : hooloovoo.localdomain
Relocations : (not relocatable)
URL : http://www.nvidia.com/object/unix.html
Summary : NVIDIA display driver kernel module
Description :
This package provides the proprietary Nvidia kernel driver modules.
The modules are rebuilt through the DKMS system when a new kernel or modules
become available.

rpm -qi dkms-2.3-1.20161202gitde1dca9.fc25.noarch
Name : dkms
Version : 2.3
Release : 1.20161202gitde1dca9.fc25
Architecture: noarch
Install Date: Wed 08 Feb 2017 06:38:04 PM EST
Group : Unspecified
Size : 227703
License : GPLv2+
Signature : RSA/SHA256, Fri 02 Dec 2016 04:17:45 AM EST, Key ID 4089d8f2fdb19c98
Source RPM : dkms-2.3-1.20161202gitde1dca9.fc25.src.rpm
Build Date : Fri 02 Dec 2016 04:14:41 AM EST
Build Host : buildvm-23.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager : Fedora Project
Vendor : Fedora Project
URL : http://linux.dell.com/dkms
Summary : Dynamic Kernel Module Support Framework
Description :
This package contains the framework for the Dynamic Kernel Module Support (DKMS)
method for installing module RPMS as originally developed by Dell.

Not at all sure what the next step might be.

Thanks

Reply
1. slaanesh says:
  
  March 13, 2017 at 8:10 pm
  
  Look for logs in /var/lib/dkms/nvidia/. To force a rebuild, type dkms --help on a prompt and you will get the help output on how to proceed.
  
  Reply
2. Bharat Kalluri says:
  
  April 18, 2017 at 8:48 pm
  
  I also have the same problem, did you find a solution?
  
  Reply
Romain says:

March 7, 2017 at 4:47 pm

the version of kmod-nvidia (375.39-1) does not match the version of nvidia-driver (375.39-3). therefore on last CentOS the drivers do not compile (see bug report: https://elrepo.org/bugs/bug_view_advanced_page.php?bug_id=720). Could you maybe update kmod-nvidia? Or am I doing something wrong?

Reply
1. slaanesh says:
  
  March 23, 2017 at 10:49 am
  
  Sorry for the late reply, your comment went into spam. The releases are different, that’s intended. There’s no need to keep them in sync, if there’s an update only on the userland components, only that package would be updated. What needs to be in sync is the main version (for example 375.39).
  
  This is not elrepo, there is nothing here that relates to them or bug reports.
  
  Reply
thunderbirdtr says:

March 4, 2017 at 6:48 am

Hello ; I did a kernel and nvidia update then I can’t use nvidia because, It became “intel with wayland” (It was nvidia with Xorg) even I changed the gdm custom.conf (In order to disable wayland) also using x11 gnome desktop file for using Xorg with nvidia and after reboot It is still not working anymore .

Here is my update history >>> https://da.gd/easaZ

Thank you.

Reply
1. slaanesh says:
  
  March 8, 2017 at 11:32 am
  
  If you are using the multimedia repository you can remove the nvidia one, it contains the same packages wrt Nvidia.
  Please provide any error, log or message you are getting.
  
  Reply
Aykut says:

March 2, 2017 at 7:33 pm

There was a problem after today’s update. The driver is not switching. Opening system with mesa drivers. I installed it with dkms. I think dkms is not compiling.

Reply
1. slaanesh says:
  
  March 8, 2017 at 11:33 am
  
  What do you mean by “the driver is not switching”?
  If DKMS is not compiling, you can check the DKMS logs to see why. Not happening here at the moment.
  
  Reply
benrxiao says:

March 2, 2017 at 10:44 am

When I add your Nvidia repo and then do a pkcon refresh force, I get an error saying Fatal error: Cannot open: Unrecognized archive format.

How can I fix this?

Reply
1. slaanesh says:
  
  March 2, 2017 at 1:08 pm
  
  I’ve never seen it. Can you paste the output?
  Just tried and works fine here.
  
  Reply
  1. benrxiao says:
    
    March 2, 2017 at 6:53 pm
    
    [benxiao@benxiao-fedora01 ~]$ sudo dnf config-manager –add-repo=http://negativo17.org/repos/fedora-nvidia.repo
    Adding repo from: http://negativo17.org/repos/fedora-nvidia.repo
    [benxiao@benxiao-fedora01 ~]$ pkcon refresh force
    Refreshing cache [=========================]
    Loading cache [=========================]
    Downloading repository information[=========================]
    Loading cache [=========================]
    Finished [=========================]
    Fatal error: Cannot open: Unrecognized archive format
    
    Reply
    1. benrxiao says:
      
      March 2, 2017 at 6:55 pm
      
      This is on a Fedora 25 system btw. Seems like I don’t have the relevant archive library installed maybe?
      
      Reply
  2. benrxiao says:
    
    March 2, 2017 at 11:37 pm
    
    I tried adding your repo to a fresh Fedora 25 installation and I got the same error. Am I missing some compression library?
    
    Reply
rpotter28 says:

February 28, 2017 at 11:55 pm

Thanks for your repo! Everything working on a fresh install of Fedora 25 with a GeoForce GT 610. I used your example and installed: nvidia-settings kernel-devel dkms-nvidia vulkan.i686 nvidia-driver-libs.i686

Works great! Only thing I don’t have is nvidia-smi which I use in my conky script. How can I get that?

Reply
1. slaanesh says:
  
  March 1, 2017 at 11:04 am
```
$ rpm -qf /usr/bin/nvidia-smi 
nvidia-driver-cuda-378.13-2.fc25.x86_64
```
  Reply
donvipre says:

February 27, 2017 at 10:50 am

Hi, in looks like there are problems with SELinux in latest package:
egrep -e “nvidia|denied” /var/log/audit/audit.log
type=AVC msg=audit(1488186332.923:198): avc: denied { execute } for pid=1387 comm=”gnome-shell” path=2F7661722F6C69622F67646D2F2331313032313831202864656C6574656429 dev=”dm-0″ ino=1102181 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:xdm_var_lib_t:s0 tclass=file permissive=0
type=AVC msg=audit(1488186726.952:198): avc: denied { execute } for pid=1435 comm=”gnome-shell” path=2F7661722F6C69622F67646D2F2331313032313736202864656C6574656429 dev=”dm-0″ ino=1102176 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:xdm_var_lib_t:s0 tclass=file permissive=0
type=AVC msg=audit(1488186976.470:199): avc: denied { execute } for pid=1459 comm=”gnome-shell” path=2F7661722F6C69622F67646D2F2331313032313833202864656C6574656429 dev=”dm-0″ ino=1102183 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:xdm_var_lib_t:s0 tclass=file permissive=0
type=AVC msg=audit(1488187417.902:201): avc: denied { execute } for pid=1440 comm=”gnome-shell” path=2F7661722F6C69622F67646D2F2331343035353031202864656C6574656429 dev=”dm-0″ ino=1405501 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:xdm_var_lib_t:s0 tclass=file permissive=0
type=AVC msg=audit(1488187430.882:239): avc: denied { module_load } for pid=2071 comm=”modprobe” path=”/usr/lib/modules/4.9.11-200.fc25.x86_64/extra/nvidia.ko” dev=”dm-0″ ino=100846929 scontext=unconfined_u:unconfined_r:insmod_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:modules_object_t:s0 tclass=system permissive=0
type=AVC msg=audit(1488187450.765:247): avc: denied { module_load } for pid=2376 comm=”modprobe” path=”/usr/lib/modules/4.9.11-200.fc25.x86_64/extra/nvidia.ko” dev=”dm-0″ ino=100846929 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:modules_object_t:s0 tclass=system permissive=0
type=AVC msg=audit(1488187585.041:253): avc: denied { module_load } for pid=2810 comm=”modprobe” path=”/usr/lib/modules/4.9.11-200.fc25.x86_64/extra/nvidia.ko” dev=”dm-0″ ino=100846929 scontext=unconfined_u:unconfined_r:insmod_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:modules_object_t:s0 tclass=system permissive=0
type=USER_CMD msg=audit(1488187601.496:254): pid=2813 uid=1000 auid=1000 ses=4 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg=’cwd=”/home/uarnold” cmd=”nvidia-xconfig” terminal=pts/0 res=success’
type=USER_CMD msg=audit(1488187613.535:259): pid=2832 uid=1000 auid=1000 ses=4 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg=’cwd=”/home/uarnold” cmd=”nvidia-xconfig” terminal=pts/0 res=success’
type=AVC msg=audit(1488187623.885:264): avc: denied { module_load } for pid=2989 comm=”modprobe” path=”/usr/lib/modules/4.9.11-200.fc25.x86_64/extra/nvidia.ko” dev=”dm-0″ ino=100846929 scontext=unconfined_u:unconfined_r:insmod_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:modules_object_t:s0 tclass=system permissive=0
type=AVC msg=audit(1488187795.725:200): avc: denied { execute } for pid=1442 comm=”gnome-shell” path=2F7661722F6C69622F67646D2F23383337393238202864656C6574656429 dev=”dm-0″ ino=837928 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:xdm_var_lib_t:s0 tclass=file permissive=1

Nvidia kernel module is getting loaded after setting selinux to permissive.
Would you please check that? Don’t hesitate to contact me if you need further information.

Reply
1. slaanesh says:
  
  February 28, 2017 at 9:18 am
  
  This is fixed in the latest policy from updates-testing selinux-policy-targeted-3.13.1-225.11.fc25.noarch. Update and reboot.
  
  Reply
  1. nikoyeslarrangeur says:
    
    March 8, 2017 at 9:18 pm
    
    Fixed for me the 4.9.12-200 upgrade, but since today 4.9.13 upgrade, i can’t log anymore again and I don’t find how to fix that…
    
    Reply
kartiksubbarao says:

February 27, 2017 at 4:20 am

I’m running Fedora 25 with a GTX 1080, running nvidia-driver-378.13-1 from negativo.org, and ran into the same problem as Damjan. His workaround (removing the rhgb kernel argument) worked for me as well.

I have a followup question — is it okay to stick with the libglvnd libraries provided by mirrors.fedoraproject.org (current version is 0.2.999-10.gitdc16f8c), or do I need to downgrade them to the exact version on negativo.org (currently 0.2.999-5.20161115git522c601)?

Reply
1. slaanesh says:
  
  February 27, 2017 at 11:00 am
  
  Just apply whatever comes with the updates (in this case the official Fedora package). I’m removing my libglvnd package for Fedora 25 in the next repository push.
  
  Reply
  1. kartiksubbarao says:
    
    February 27, 2017 at 4:09 pm
    
    Great, thanks!
    
    Reply
stevestorey says:

February 21, 2017 at 11:22 pm

Hi – I’ve opened https://github.com/negativo17/nvidia-kmod/pull/4 to add support for running 4.10 kernels on earlier versions of Fedora by rewriting the patches to apply conditionally based on kernel version. Let me know if you’d like it done differently (or by all means take the content and re-apply to your own liking!)

Reply
Pierre says:

February 20, 2017 at 10:04 pm

Hi, trying to use the driver on an optimus enabled laptop (GTX 1050).
At first the display server could not start, but it seams there might be something wrong with the driver?

NVRM: loading NVIDIA Kernel Module 378.13
NVRM: RmInitAdapter failed! (0x26:0xffff:1097)
NVRM: rm_init_adapter failed for device bearing minor number 0

It it the driver or am I perhaps missing some configuration?

Reply
1. Mohammad Khashashneh says:
  
  March 23, 2017 at 3:04 pm
  
  Same here, I have an asus ROG-GL753VD witn an optimus GTX 1050 notebook, and got similar errors as above.
  slaanesh: is there additional steps for optimus?
  
  Reply
  1. slaanesh says:
    
    April 6, 2017 at 3:30 pm
    
    No, no additional steps. Everything should be in Fedora already.
    
    Reply
    1. Mohammad Khashashneh says:
      
      May 23, 2017 at 3:24 pm
      
      with the recent driver 381.22 the errors are gone but get greeted with a black screen. I can switch to the virtual consoles and confirm the driver.
      Unfortunately I can’t turn off the intel GPU from the bios so I tried the bumblebee route and it works, but with several hangups and the fan running all the time! Is there anyway around this?
      
      Reply
Aaron says:

February 17, 2017 at 10:49 pm

Installed latest 378.13 but getting an “api mismatch” error on boot. Followed the instructions and uninstalled previous driver 375.26 from rpmfusion. Error says kernel module is 375.26 but client is 378.13…

Reply
1. slaanesh says:
  
  February 21, 2017 at 9:05 am
  
  You have a mix of different versions.
  
  Reply
Joshua says:

February 16, 2017 at 9:29 pm

Help! Installed nvidia updates today Thu Feb 16 and no GL — KDE plasma fails, sddm fails. Xorg starts from console with no DE but can run firefox to send this help request. I can not figure out what broke. I’m running kernel-4.7.10 but everything else is up to date.

Reply
1. Joshua says:
  
  February 17, 2017 at 1:07 am
  
  I’m not sure what happened but I think my initrd.img had the previous driver version in it. Luckily I had a backup initrd.img. I’m really tempted to just disable updates once my system is running the way I like. Seems like something breaks with every other update on fedora 25 — it’s the buggiest release in a while.
  Anyway, I need to figure out how to configure dracut so it doesn’t happen again.
  
  Reply
  1. slaanesh says:
    
    February 21, 2017 at 9:04 am
    
    Hello, there should be no module inside the initrd. They are not required for boot. What will be included are the configuration and directories:
    
    ./usr/lib/modprobe.d/nvidia-uvm.conf ./usr/lib/modprobe.d/nvidia.conf ./usr/lib/nvidia ./usr/lib/firmware/nvidia ./usr/lib64/nvidia ./etc/ld.so.conf.d/nvidia-lib64.conf ./etc/ld.so.conf.d/nvidia-lib.conf
    
    These get included in the initrd.
    
    Reply
2. Evgeniy B says:
  
  February 18, 2017 at 9:05 am
  
  Have same issue, NVRM: API mismatch error in dmesg
  
  Reply
Ch Ahmed Waleed says:

February 16, 2017 at 5:43 am

Hello,
Can you point me on how to setup for optimus cards, i am coming to fedora from Ubuntu where i had option of prime. Following procedure above, nvidia drivers have installed successfully but they don’t detect optimus/prime and hence behaving like discrete card only machine.
Its an optimus laptop:
W520 with nvidia 1000m and intel HD3000.
I tried searching on Google and Comments, i am sorry if you responded to such query before and i couldn’t find it.

Regards and Thankyou

Reply
1. slaanesh says:
  
  February 16, 2017 at 9:00 am
  
  Are you running Fedora 25? If so, you just need to install the drivers and the mesa/libgvlnd updates from updates-testing and you will have much more than Prime in Ubuntu.
  For RHEL/CentOS you still need to rely on additional configuration.
  
  Reply
  1. Ch Ahmed Waleed says:
    
    February 16, 2017 at 11:04 am
    
    Yes i am running Fedora 25.
    Are you talking about proprietary nvidia drivers from your repo? or mesa from fedora’s update-testing!
    Sorry i am a newbie so couldn’t get you!
    
    Reply
    1. slaanesh says:
      
      February 16, 2017 at 12:42 pm
      
      Just follow the instructions in the page for the driver and after that update from udpates-testing:
      
      dnf update --enablerepo=updates-testing mesa\* libglvnd\*
      
      This should be enough for a working Optimus setup.
      
      Reply
      1. Ch Ahmed Waleed says:
        
        February 16, 2017 at 1:21 pm
        
        Thank you for your help!
        I did all that and still there is no difference. Nvidia doesnt have any option to turn it off or anything and it is using nvidia card by default.
        
        I followed the instructions in the page however i proceeded with ‘dkms-nvidia’ option. Is it the problem?
        I tried logging in to both sessions and both times it directed to x session.
      2. slaanesh says:
        
        February 16, 2017 at 5:34 pm
        
        Please read the docs by Nvidia, that’s not how it is supposed to work. Also read the third posts here, especially the third going down: http://hansdegoede.livejournal.com/
        
        Optimus on Linux with the Nvidia drivers does not allow you to turn off the Nvidia video card. They are always BOTH on as the Nvidia video card is doing all the rendering.
        This is how it is designed by Nvidia. On Ubuntu, through Prime, you have a module that does an ACPI call to turn off the discrete card (from Bumblebee, and based on reverse engineering) and would switch all GL libraries, configuration, etc. That is a terrible hack, not supported by Nvidia or anyone else and actually in my previous job was killing all Dell laptops with the Nvidia card. The clean solution is multiple drivers loaded, dumb modesetting outputs on Intel, Nvidia always on doing the rendering and multiple GL libraries active at the same time through libglvnd.
      3. Ch Ahmed Waleed says:
        
        February 16, 2017 at 6:30 pm
        
        Thank you for that information and for that blog link as well. Your answer and that blog did wonderful job of explaining things!
        
        However, one last question is how do i confirm that both are working as they are supposed to be instead of only Nvidia doing all the job.
Przem says:

February 10, 2017 at 10:14 am

CUDA is not working in Blender 2.78 (Korora 25 – Fedora 25 spin) . Console is showing this:

Compiling CUDA kernel …
“nvcc” -arch=sm_20 –cubin “/usr/share/blender/2.78/scripts/addons/cycles/kernel/kernels/cuda/kernel.cu” -o “/home/Lew/.config/blender/2.78/cache/cycles_kernel_sm20_D8F831DA74C0363DC018432CF25F3AD8.cubin” -m64 –ptxas-options=”-v” –use_fast_math -DNVCC -D__KERNEL_CUDA_VERSION__=80 -I”/usr/share/blender/2.78/scripts/addons/cycles/kernel”
nvcc warning : The ‘compute_20’, ‘sm_20’, and ‘sm_21’ architectures are deprecated, and may be removed in a future release (Use -Wno-deprecated-gpu-targets to suppress warning).
cc1plus: fatal error: cuda_runtime.h: No such file or directory
compilation terminated.
CUDA kernel compilation failed, see console for details.

I have installed cuda-devel also. Nothi8ng changes.

Please help.

P.

Reply
1. slaanesh says:
  
  February 10, 2017 at 2:30 pm
  Hello, there’s a pre-built Blender with CUDA support in the multimedia repository. Just add the repository and:
```
dnf install blender-cuda nvidia-driver-cuda && reboot
```
  Then you should have CUDA support enabled. Instructions and details are in the multimedia repository page. Keep in mind the repository is NOT compatible with RPMFusion.
  
  If you want to compile Blender with CUDA support yourself, you need an older GCC version or use Clang for the CUDA kernels (as I do: https://github.com/negativo17/blender/blob/master/blender-2.78a-cuda.patch).
  Reply
  1. PRZEM says:
    
    February 12, 2017 at 11:38 am
    
    Thank you! It is working. 🙂
    
    Reply
  2. Marcus Brubaker says:
    
    March 8, 2017 at 10:34 pm
    
    Fixing this in the packages would be really nice and it’s not too hard to do. Basically, create a directory called /usr/share/cuda/nvcc_compilerbindir (or whatever) and create a symlink in there from gcc to /usr/bin/clang (or whatever compiler you want to use). That is, do:
    
    ln -s /usr/bin/clang-3.8 /usr/share/cuda/nvcc_compilerbindir/gcc
    
    Then in /usr/bin (along side nvcc) put a file called nvcc.profile with the lines:
    
    INCLUDES += -I/usr/include/cuda
    compiler-bindir = /usr/share/cuda/nvcc_compilerbindir
    
    Reply
David says:

February 10, 2017 at 1:52 am

I have followed your prescription for the sample installation. I have added a personal key via MokManager.efi
My question is: which modules do I need to sign? I see nvida-uvm.ko, nvidia-modeset,ko, nvidia-drm.ko and nvidia.ko under /usr/lib/modules/…/extra/ and under /var/lib/dms/nvidia/…/module/ ?

And, in general, how do I know all the modules that need to be signed as I add additional components?

Many thanks

Reply
1. slaanesh says:
  
  February 10, 2017 at 2:31 pm
  
  You don’t know, that’s why most of the people do not sign them. After a new kernel update, modules get rebuilt and you need to sign them again. Might be worth doing it for CentOS/RHEL, where the kABI modules change only when a new version is out.
  
  You must sign all nvidia-*.ko files.
  
  Reply
X6205 says:

January 21, 2017 at 3:18 pm

I was never able to make this driver work. After reboot my system started to boot nicely with Fedora boot animation, but then UI has not started and system hangs with black screen. Not sure what is wrong 🙁 My harddrive is in GPT mode with UEFI secure boot enabled. Disabling UEFI secure boot has no effect. My PC is Alienware X51 R2 with 16GB Ram, Core i7 4770 + GTX 1060 6GB and with EVO 850 SSD. Only distros which work with NVIDIA driver and UEFI secure boot enabled are Ubuntu and openSUSE. But no Fedora what is sad, since its most polished, vanilla GNOME experience.

Reply
Xiang Zhang says:

January 21, 2017 at 12:28 pm

Seems to break with the xorg-x11-server-1.19.1-2. I could have tried to downgrade to xorg-x11-server-1.19.0-0 in fedora repo (rather than in updates), but the nvidia packages seem to depend on xorg-x11-server-1.19.0-3. Is it possible to downgrade the dependency version of X/Wayland in nvidia-driver?

Reply
1. Xiang Zhang says:
  
  January 25, 2017 at 3:43 am
  
  It turns out I was wrong. It has nothing to do with xorg-x11-server updates. The driver did not work for me because somehow nvidia-driver-375.26 selected the GPU at “PCI:2:0:0” as the default one, but my two monitors are connected to the device at “PCI:1:0:0”. It was working properly till driver version 375.20 but this new 375.26 broke it. I fixed it by the adding the following section in /etc/X11/xorg.conf:
  
  Section “Device”
  Identifier “Device0”
  Driver “nvidia”
  VendorName “NVIDIA Corporation”
  BusID “PCI:1:0:0”
  EndSection
  
  Apologies for the misinformation!
  
  Reply
2. Xiang Zhang says:
  
  January 25, 2017 at 3:44 am
  
  Just to add more information, I have three GTX Titan X (Maxwell).
  
  Reply
3. Xiang Zhang says:
  
  January 25, 2017 at 5:35 am
  
  There are also multiple reports of nvidia-driver 375.26 breaking CUDA programs from my colleagues, especially when one of the GPU is running X. I think this is a buggy driver, despite being a “Long Lived Branch version”. I advise them to hold updates until a next version is available from NVIDIA.
  
  Reply
  1. slaanesh says:
    
    January 27, 2017 at 2:17 pm
    
    Sorry for the late reply. Do you have more information?
    I’ve just released the 378.09 packages for Fedora 26, if there is anything outstanding in 375.26 I might swap version.
    
    Reply
    1. fancyzhx says:
      
      January 28, 2017 at 4:45 am
      
      Sure of course. The driver version 375.26 seems to be buggy in handling PCI order correctly. Several buggy things on my machine (with ASUS Rampage IV Extreme motherboard and 3 GTX Titan X Maxwell, Fedora 25 on kernel 4.9.5-200. Same problems for 4.8.5 and 4.9.3 as well.):
      
      1. In the absence of xorg.conf, driver 375.26 activated the 2nd GPU at “PCI:2:0:0” by default for X11/Wayland. Driver 375.20 and earlier versions can detect and use the 1st GPU at “PCI:1:0:0” correctly. Which GPU is activated for X11/Wayland can be checked by running “cat /var/log/Xorg.0.log | grep NVIDIA”.
      
      2. I attempted to connect DVI and HTML to the 2nd GPU. In the absence of xorg.conf, gdm hangs and login screen does not show up. Instead, the system can only be accessed through CNTRL + ALT + F2 to a terminal with resolution 640 x 480 via a display connected to the 1st GPU DVI. The displays connnected on the 2nd GPU has signal but it’s just black screen. So even when driver 375.26 activated the 2nd GPU for X11/Wyland, it does not seem to be usable.
      
      3. I then attempted the following configuration in xorg.conf:
      Section “Device”
      Identifier “Device0”
      Driver “nvidia”
      VendorName “NVIDIA Corporation”
      BusID “PCI:1:0:0”
      EndSection
      This time X11/Wayland worked and l can login and use the system with displays connected to the 1st GPU. However, CUDA seems to have trouble using the 2nd GPU because it gives unavailable error whenever I run something. Interestingly, nvidia-smi shows exactly the same memory usage for the 1st and 2nd GPUs, therefore I suspect internally NVIDIA messed up the device orders in driver 375.26. CUDA programs on the 1st and the 3rd GPUs can be ran successfully. At least one other colleague has the same problem here:
      https://groups.google.com/forum/#!topic/torch7/W2n8QYQpUf4
      
      4. I wanted to try adding more device sections in xorg.conf and see if we can make all the device usablel in CUDA, but did not have time to try yet.
      
      I have no idea whether 378.09 is going to solve the problem or not.
      
      Reply
      1. fancyzhx says:
        
        January 28, 2017 at 4:48 am
        
        I meant “HDMI”, not “HTML”. LOL…
      2. fancyzhx says:
        
        January 31, 2017 at 7:14 pm
        
        Update:
        
        4. I attempted to add more “Device” sections in xorg.conf. No change from 3. The 2nd GPU still cannot be used for CUDA.
        
        5. I removed the 3-way SLI bridge on my machine and this time I can use all GPUs for CUDA. The “Device” section in xorg.conf is still necessary, otherwise it went back to 1.
        
        The conclusion is that I can use dirver version 370.26 without problems for either X11/Wayland or CUDA by (1) adding a proper “Device” section in xorg and (2) removing the SLI bridge.
        
        It seems not necessary to make any changes to the repository. Although driver 370.26 seems to have inconsistent GPU order compared to previous drivers, the problems it can certainly be solved. Hopefully my comments here can be helpful for others as well.
      3. fancyzhx says:
        
        March 5, 2017 at 7:05 pm
        
        Just want to report that driver 378.13 has the same issue and the same solution.
goudeuk says:

January 16, 2017 at 12:30 pm

Hello

I just enabled negativo17 repo on my fedora 25 machine but “no results are found” when I search for nvidia inthe “software” window. I don’t understand why is that.

Thank you

Reply
1. slaanesh says:
  
  January 19, 2017 at 7:04 pm
  
  Have you waited enough or triggered the metadata refresh?
  pkcon refresh as your user.
  
  Reply
Eric Mesa says:

January 4, 2017 at 3:38 am

Getting a CUDA error with VLC from your repo, tried to install CUDA, but get:

Error: Transaction check error:
file /usr/lib64/libcuda.so from install of nvidia-driver-cuda-libs-2:375.26-1.fc24.x86_64 conflicts with file from package xorg-x11-drv-nvidia-cuda-1:375.26-6.fc24.x86_64
file /usr/lib64/libcuda.so.1 from install of nvidia-driver-cuda-libs-2:375.26-1.fc24.x86_64 conflicts with file from package xorg-x11-drv-nvidia-cuda-1:375.26-6.fc24.x86_64
file /usr/lib/systemd/system/nvidia-persistenced.service from install of nvidia-persistenced-2:375.26-1.fc24.x86_64 conflicts with file from package xorg-x11-drv-nvidia-cuda-1:375.26-6.fc24.x86_64
file /usr/share/man/man1/nvidia-persistenced.1.gz from install of nvidia-persistenced-2:375.26-1.fc24.x86_64 conflicts with file from package xorg-x11-drv-nvidia-cuda-1:375.26-6.fc24.x86_64
file /etc/OpenCL/vendors/nvidia.icd from install of nvidia-driver-cuda-2:375.26-1.fc24.x86_64 conflicts with file from package xorg-x11-drv-nvidia-cuda-1:375.26-6.fc24.x86_64

Should I be removing the Xorg package?

Reply
1. slaanesh says:
  
  January 8, 2017 at 10:13 am
  
  Hello, you should not remove any Xorg package.
  Now if you’re using these repositories you should not enable RPMFusion, and viceversa. I’m planning to remove compatibility entirely and just state that they are not compatible, as it does not make much sense now. So pick one that suits you most.
  
  Reply
damjan says:

December 15, 2016 at 11:19 pm

So, after some messing around with the boot parameters I finally got my GTX 1080 working in Fedora 25, by removing rhgb boot option.

Long story: additional boot parameters that I have in grub.cfg are:
nomodeset rhgb quiet LANG=en_US.UTF-8 nouveau.modeset=0 rd.driver.blacklist=nouveau gfxpayload=vga=normal
First I tried removing them all and it worked, then I tried one by one and isolated the problematic option to be rhgb for whatever reason. So, If I remove the rhgb option then I can login successfully and the second Xorg works fine, otherwise I get this error in Xorg.1.log:
nvidia(gpu-0): failed to acquire modesetting permission
It appears the rhgb (redhat graphical boot) somehow messes up the nvidia driver. Any idea why?

Hopefully this info helps also someone else with similar problems.

Reply
1. Bav says:
  
  December 19, 2016 at 6:03 pm
  
  Vote of thanks from me… I’ve been struggling with this for days (FC25, GTX970). Since upgrading from Fedora 21->25 a few months ago I’ve had issues after almost every update. Sometimes a couple of reboots seemed to sort it, but for the last three days I’ve tried so many things I’ve got lost. I don’t think I’ve spent so long with a wrecked GUI on Linux since installing RH on a Dell laptop in 2001!
  
  Most recent steps I took, for the record:
  Boot into run level 3 (press e on the grub menu for the entry you want to boot). Scroll down to the line containing the kernel (linux16 /vmlinuz….) and add a space and a 3 at the end of the line, then hit Ctrl+x
  Login as root
  dnf config-manager –add-repo=http://negativo17.org/repos/fedora-nvidia.repo
  dnf -y remove \*nvidia\*
  
  I still seem to have issues logging out though (just get a flashing cursor)…!
  
  Reply
  1. slaanesh says:
    
    December 20, 2016 at 9:44 am
    If you want to remove Nvidia drivers, also remember to remove the libglvnd libraries that were installed as part of it. Fedora 26 will have a libglvnd-Mesa enabled build.
    
    dnf remove \*nvidia\* libgvlnd\*
    Reply
2. Brakia says:
  
  December 22, 2016 at 11:39 pm
  
  Sorry for the noise, the comments here were a bit confusing for me, I just saw this post, It works perfect!.
  
  You guys, make life easy for non technical users.
  Thank you.
  
  Reply
damjan says:

December 12, 2016 at 11:19 pm

So I just checked and on my Fedora 24 there are also 2 Xorg server processes running in parallel, one on vt1 and another on vt2 and nvidia graphics works, I can also switch between the two consoles:

$ ps -ef | grep Xorg
root 968 955 3 23:11 tty1 00:00:01 /usr/libexec/Xorg vt1 -displayfd 3 -auth /run/user/42/gdm/Xauthority -background none -noreset -keeptty -verbose 3
root 1358 1354 3 23:11 tty2 00:00:00 /usr/libexec/Xorg vt2 -displayfd 3 -auth /run/user/1001/gdm/Xauthority -background none -noreset -keeptty -verbose 3

$ lsmod | grep nvidia
nvidia_drm 16384 2
nvidia_modeset 765952 7 nvidia_drm
nvidia 11485184 109 nvidia_modeset
drm 344064 4 nvidia_drm

$ uname -a
Linux dragon.local 4.8.12-200.fc24.x86_64 #1 SMP Fri Dec 2 18:45:50 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Are we sure F25 disabled running multiple Xorg processes? (I have the graphics only in gdm problem)

Reply
1. Zlopez says:
  
  December 13, 2016 at 9:53 am
  
  This is normal, I had two processes of Xorg server running too. One should be for gdm and one for gnome.
  
  Reply
  1. slaanesh says:
    
    December 13, 2016 at 12:10 pm
    
    Correct, it’s normal you have two. It has been like this since Fedora introduced non-root X server.
    
    Reply
    1. damjan says:
      
      December 13, 2016 at 2:26 pm
      
      Ok, I’m confused now. The issue I’m having on Fedora 25 is that the first X with gdm works fine with nvidia driver, while, the second X that’s spawned for the logged in user results in a blank screen. And your last comment is the reverse of what you said a couple of days ago:
      
      SLAANESH
      December 2, 2016 at 9:03 am
      The server should start as root and only start one X server. It’s like that since middle 2015:
      http://hansdegoede.livejournal.com/15767.html
      
      So, what do I do to make my Fedora 25 install work with nvidia, and how come I’m the only one experiencing this issue, I tried a fresh install and that did not help. Are there any logs that I can provide to help solving the issue, (I have pasted the Xorg.logs previously, anything else?) Or should I look for help elsewhere? Any suggestions? 🙁
      
      Reply
      1. Zlopez says:
        
        December 13, 2016 at 2:32 pm
        
        Try to run gdm with debug enabled. It should give you more info, what is going on when starting session.
        The gdm settings are in /etc/gdm/custom.conf.
        Then look in journalctl for gdm.
      2. slaanesh says:
        
        December 13, 2016 at 2:45 pm
        
        Sorry, I was not clear. You get at least two X servers, one as the GDM user and another one for each user logged in (fast user switching spawns another X server).
        If you are using the Nvidia binary drivers, then you have all X servers running as root but with the same mechanism. In the past, you had just one as root with Nvidia drivers.
        
        Depending on how you customized your system you might still have the single one. To debug issues, you might want to look at this page:
        
        https://fedoraproject.org/wiki/How_to_debug_Xorg_problems
damjan says:

December 9, 2016 at 1:03 pm

I saw that the nvidia-driver package was updated so I have updated my fedora 25 installation, but it has still the same problem, after logging in it freezes because it starts another X server. Have you managed to upgrade your system to fedora 25? Is there a known fix for this?

Reply
1. MARCELOM56 says:
  
  December 9, 2016 at 5:56 pm
  
  I’m having exactly same problem here…
  
  Reply
  1. slaanesh says:
    
    December 10, 2016 at 10:33 am
    
    No issues there, I have all my systems on Fedora 25 now. What do the logs say?
    
    Reply
  2. damjan says:
    
    December 10, 2016 at 9:57 pm
    
    MARCELOM56, SLAANESH, which graphic cards do you have? Maybe the issue is only with the latest graphic cards. Mine is Geforce GTX 1080.
    
    Reply
    1. MARCELOM56 says:
      
      December 12, 2016 at 12:31 pm
      
      Hi DAMJAN, I have a notebook with switchable graphics. Here are both graphic cards:
      00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)
      01:00.0 3D controller: NVIDIA Corporation GM107M [GeForce GTX 960M] (rev a2)
      
      After login, the screen freezes (neither Alt + F1, F2, F3, F4… works). The only way that “works” is, in GRUB selection, edit boot parameters adding “nomodeset”.
      
      Reply
      1. slaanesh says:
        
        December 12, 2016 at 2:03 pm
        
        The nomodeset parameter is already there when you install drivers:
        
        https://github.com/negativo17/nvidia-driver/blob/master/nvidia-driver.spec#L20
        
        If you plan to use both Nvidia and Intel chipsets, did you configure your system appropriately?
        
        http://us.download.nvidia.com/XFree86/Linux-x86/375.20/README/randr14.html
        
        Also, remember on Fedora 25 Mutter does not support Wayland on Nvidia with EGLStreams; you need Fedora 26.
      2. Brakia says:
        
        December 22, 2016 at 11:09 pm
        
        I have exactly the same problem, with a clean F25, its works just until I insert the password in user select screen, and then black screen and I can’t do anything.
        
        _my graphic card_
        01:00.0 VGA compatible controller: NVIDIA Corporation GM206 [GeForce GTX 960] (rev a1)
        
        It’s anything new about that?
2. slaanesh says:
  
  December 10, 2016 at 10:33 am
  
  No issues there, I have all my systems on Fedora 25 now. What do the logs say?
  
  Reply
  1. MARCELOM56 says:
    
    December 12, 2016 at 12:32 pm
    
    SLAANESH, did you suggest a specific log to investigate? I have no idea where look for.
    
    Reply
damjan says:

December 1, 2016 at 12:15 am

The gdm login screen shows up correctly using your nvidia driver. And in 4K resolution too.
But when I try to login with a user I only get a black screen.
Looking at the xorg.1.log i see:
nvidia(gpu-0): failed to acquire modesetting permission
so I assume the problem is that gdm is starting two X sessions one on vt0 and another on vt1.
is this supposed to work?
I did disable wayland in /etc/gdm/custom.conf
anything else I need to do?
I also selected gnome on Xorg in gdm when logging in as a user.

Reply
1. slaanesh says:
  
  December 1, 2016 at 10:05 am
  
  So, multiple issues here. If the system detects that you are using the Nvidia binary driver, X is still executed as root and not with normal user privileges. This translates in just one X instance starting.
  
  In your case this means that is loading some other driver (like the Intel KMS one), which would also explain the “failed to acquire modesetting” error. Why it does work at login I don’t know, you need to check your logs. If you’re on an Optimus laptop then that’s another topic and you need to configure it.
  
  Reply
  1. damjan says:
    
    December 1, 2016 at 1:07 pm
    
    It’s not an optimus laptop, it’s a desktop machine with GTX1080. First I installed rpmfusion drivers, discovered they don’t work (I get the gdm something went wrong message), then I found your page, removed rpmfusion *nvidia*, and installed your drivers. I was happy to finally get the gdm login screen in full 4K, but it would not allow me to login because it spawns a second xorg which fails, and from logs i can see that other drivers are also enabled on the second xorg. I don’t know if this is some leftovers from rpmfusion, I can try making a fresh fedora 25 install + your drivers if that would help. Also note, while installing fedora 25 I had to choose boot with basic video or I would not get to the installer, maybe that left some differences on the system…
    
    Reply
    1. slaanesh says:
      
      December 1, 2016 at 10:13 pm
      
      That’s strange, I have a couple of desktops with Nvidia cards and have to do absolutely nothing apart from installing the packages. The system detects that you are using the Nvidia driver; the non-root X servers do not start and there is only one X instance running as root.
      Does your system also have an Intel card integrated on the motherboard? You can check that there are no other driver using kms with the following command. It should only return this output if only the Nvidia driver is loaded:
      
      $ lsmod | grep kms drm_kms_helper 151552 1 nvidia_drm drm 344064 7 nvidia_drm,drm_kms_helper
      
      In case there is something left over by other packages or manual configurations I think you can clean it up without reinstalling anything.
      
      Reply
      1. damjan says:
        
        December 1, 2016 at 10:59 pm
        
        I tried the lsmod | grep kms and get exactly the same output as you have pasted (in single or multi-user mode, without X).
        
        I tried a fresh fedora 25 install and this time with only your multimedia repo, no rpmfusion but it did not help. I installed your nvidia drivers immediately after installing, so without updating the system (dnf update), and it did not work, then I updated the system and still the same issue.
        
        Yes my i5-2500K does have onboard graphics and the motherboard supports that, but I don’t think that’s the issue.
        
        I have uploaded Xorg.0.log:
        http://pastebin.com/7aPNgJks
        
        and Xorg.1.log:
        http://pastebin.com/ttTj5VfC
        
        If you can make some sense out of that?
        
        What else can I try?
        
        My dual-boot fedora 24 install works fine (with rpmfusion nvidia) but I would like to fedora 25 working too so I can move to that.
      2. slaanesh says:
        
        December 2, 2016 at 9:03 am
        
        I really don’t know. The server should start as root and only start one X server. It’s like that since middle 2015:
        http://hansdegoede.livejournal.com/15767.html
        
        Maybe check if you have other video drivers loaded? Btw I’m upgrading my systems to Fedora 25 today (lack of time so far…)
2. Salvatore P. says:
  
  December 3, 2016 at 1:16 pm
  
  I have a GTX970 and I got black screen too. The screen completly turn off. Never append before. I start thinking to join to the RedTeam (AMD), I’m really tired of maxwell gpu on linux.
  
  Reply
  1. Salvatore P. says:
    
    December 3, 2016 at 1:20 pm
    
    And It 2016 and I want a wayland compositor.
    I’m tired of X and the compositors based on X, It’s hard and embarrassing works on a desktop with lag, tearing and stutter all the time, even on discrete powerfull gpu.
    
    Reply
fish says:

November 28, 2016 at 9:36 am

gnome software doesnt show the driver for me. if install the driver over the terminal, gdm doesnt start.

my gpu is a gtx 760

Reply
1. slaanesh says:
  
  November 28, 2016 at 10:17 am
  
  See comment above for Gnome Software. Regarding your problem, you should look at the logs, etc.
  
  Reply
2. André Costa says:
  
  November 28, 2016 at 12:12 pm
  
  Not sure if this will help you, but *every time* I do a fresh install of nvidia drivers from Negativo17, the first reboot stalls for a while and then fails with the GNOME “Oh no! Something happened!” error message (GDM doesn’t even start). If I simply reboot by switching to a console and running “reboot” as root, it works just fine after that. It seems to be a first-run issue…
  
  Reply
  1. espionage724 says:
    
    December 13, 2016 at 1:58 am
    
    Pretty sure this has to do with Akmods not generating the module until the next boot. After you install the NVIDIA driver, immediately running akmods –force should force it to build the module and have it available on next boot.
    
    Reply
Reason says:

November 25, 2016 at 3:58 am

So I was previously using the driver obtained and installed from nvidia.com on Fedora 24, then yesterday I decided to make the switch both to Fedora 25 and to this repo (because I was getting tired of having to manually fix stuff every time kernel updated).

Having some issues:

I previously had it configured to use KMS with the following command line `rd.driver.blacklist=nouveau nvidia-drm.modeset=1 video=vesa:off`

I also added the nvidia modules to my initrd using dracut.

Now I see that installing the packages has changed some things, notably `nouveau.modeset=0 nomodeset gfxpayload=vga=normal`. No matter which configuration I use (yours, without my changes or mine, without yours), I cannot get GDM to show up.

If I boot with the kms flags (and with the modules in initrd), it will give me a bunch of garbage in dmesg about failing to convert NVKMS memory to GEM objects (or so) every time I try to switch VT (it seems any time a KMS context-switch occurs), and if I boot with the nomodeset flags (and without the modules in initrd), then gnome-session hits a segfault.

`segfault at 0 ip 00007f0311775229 … in libgtk3.so.0…`

Totally at a loss…

Reply
1. slaanesh says:
  
  November 25, 2016 at 11:54 am
  
  Hello,
  
  > I also added the nvidia modules to my initrd using dracut.
  
  You should not, otherwise at the next update you require an initrd rebuild. They should be loaded after systemd switches the root filesystem on boot.
  
  To clean everything up, if you come from a manually installed driver:
  
  – Remove stuff from /etc/default/grub
  – Remove stuff from /etc/{modprobe.d,depmod.d}
  – Remove stuff from grub configuration files
  – Remove all packages and manually installed files from Nvidia
  – Remove all Nvidia kernel module source code in /usr/src
  – Reinstall packages providing libGL.*
  – Reboot with Nouveau and standard Fedora setup
  
  Then you can install the packages. Can’t help if you have untracked Nvidia files scattered around your system, sorry.
  
  Reply
  1. Reason says:
    
    November 25, 2016 at 11:20 pm
    
    I’m perfectly comfortable rebuilding my initrd’s with dracut after updates. I’m not worried about that. I need the KMS support for a wayland-based application I’m working on. I have already fully uninstalled the old nvidia drivers. (use of the –uninstall flag in the installer was sufficient). I also did try to use the modules without my patched-together initrd and grub settings, and it failed with the same error below:
    
    The problem actually was that GLX wasn’t being initialized. Xorg attempted to load the wrong GLX module (the X.org Foundation version). If GLX isn’t available, libGTK will apparently just segfault. If anyone from future internet is encountering this problem, try running an X server with e.g. `Xorg :2` and a terminal in that server with `DISPLAY=:2 xterm` or so. Then try to run `glxinfo` in that terminal. It’ll tell you if GLX is missing on the display.
    
    When I saved an X configuration using nvidia-settings, it created a Files section. When I removed this section, GDM could start. I presume that it was overriding somehow the Files section in the xorg.conf.d config file.
    
    Reply
    1. slaanesh says:
      
      November 28, 2016 at 9:29 am
      
      I think you have some leftovers around. The packages install everything that is required to have a working X driver out of the box:
      
      $ cat /etc/X11/xorg.conf.d/99-nvidia-modules.conf # Load with order 99 as the Files section needs to be the very last Section "Files" ModulePath "/usr/lib64/nvidia/xorg" ModulePath "/usr/lib64/xorg/modules" EndSection Section "Module" Disable "glamoregl" EndSection
      
      and:
      
      $ cat /usr/share/X11/xorg.conf.d/10-nvidia-driver.conf Section "OutputClass" Identifier "nvidia" MatchDriver "nvidia-drm" Driver "nvidia" EndSection
      
      Reply
      1. Reason says:
        
        January 26, 2017 at 1:33 am
        
        I have these files and no other Xorg configuration. I confirm that by running, e.g. `Xorg :5 & DISPLAY=:5 xterm` that I have GLX on that display, i.e. the configuration works as intended when starting the X server manually. This is reflected in the logs, where the GDM-parented Xorg server loads the X.org Foundation’s GLX module, and the Xorg server run from CLI loads NVIDIA’s. When the X server is started by GDM, the module path is not set unless I explicitly set it on the environment, i.e. the configuration file is ignored.
        
        The result is that GDM always fails to start on a fresh boot, and I must wait for the service to die, then restart it after setting the environment variables.
      2. slaanesh says:
        
        January 27, 2017 at 2:26 pm
        
        Are you on Fedora 25? The driver now uses the ehnanced OutputClass as per Hans’ blog:
        
        http://hansdegoede.livejournal.com/
mdda says:

November 24, 2016 at 11:23 am

Thanks for the all of your efforts – on previous Fedoras, I’ve rolled-my-own updates, but thought that it would simplify things if I could do it using your repo for Fedora 25. I’m “just” looking to do CUDA/tensorflow stuff on a monitorless box.

dnf install kernel-devel dkms-nvidia
dnf install cuda-devel cuda-cudnn-devel

and reboot, gives me an nvidia driver in “lsmod”.

But when I try and do something with tensorflow, it says that the cuda_XXX.so are all loaded fine, but fails to find a /dev/nvidia0 device (and I don’t see anything useful in the /dev/ listing). Could someone who has a working CUDA configuration tell me what I’m missing? Or is it the tensorflow end – though this is the first error it gives :

I tensorflow/stream_executor/cuda/cuda_diagnostics.cc:147] no NVIDIA GPU device is present: /dev/nvidia0 does not exist

Many Thanks, Martin

Reply
1. slaanesh says:
  
  November 24, 2016 at 1:01 pm
  Hello, you’re missing one step. The package nvidia-driver-cuda is missing in your commands. That’s what loads the nvidia-uvm module and pulls in the other CUDA libraries.
  
  So, based from your above commands:
```
dnf install kernel-devel dkms-nvidia nvidia-driver-cuda
```
  Reply
  1. mdda says:
    
    November 24, 2016 at 4:43 pm
    
    I added nvidia-driver-cuda as suggested (and that pulled in nvidia-persistenced & opencl-filesystem). The install I had done earlier had already pulled in nvidia-uvm as a dependency. After a reboot, still no /dev/nvidia0 (though /dev/nvidia-uvm was there).
    
    However, running the script at http://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html#runfile-verifications did create a /dev/nvidia0 that TensorFlow liked, upon which the following python snippet :
    
    python
    import tensorflow as tf
    sess = tf.Session(config=tf.ConfigProto(log_device_placement=True))
    
    gives the output :
    
    I tensorflow/stream_executor/dso_loader.cc:111] successfully opened CUDA library libcublas.so locally
    I tensorflow/stream_executor/dso_loader.cc:111] successfully opened CUDA library libcudnn.so locally
    I tensorflow/stream_executor/dso_loader.cc:111] successfully opened CUDA library libcufft.so locally
    I tensorflow/stream_executor/dso_loader.cc:111] successfully opened CUDA library libcuda.so.1 locally
    I tensorflow/stream_executor/dso_loader.cc:111] successfully opened CUDA library libcurand.so locally
    
    I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:925] successful NUMA node read from SysFS had negative value (-1), but there must be at least one NUMA node, so returning NUMA node zero
    I tensorflow/core/common_runtime/gpu/gpu_device.cc:951] Found device 0 with properties:
    name: GeForce GTX 760
    major: 3 minor: 0 memoryClockRate (GHz) 1.137
    pciBusID 0000:01:00.0
    Total memory: 1.98GiB
    Free memory: 1.94GiB
    I tensorflow/core/common_runtime/gpu/gpu_device.cc:972] DMA: 0
    I tensorflow/core/common_runtime/gpu/gpu_device.cc:982] 0: Y
    I tensorflow/core/common_runtime/gpu/gpu_device.cc:1041] Creating TensorFlow device (/gpu:0) -> (device: 0, name: GeForce GTX 760, pci bus id: 0000:01:00.0)
    Device mapping:
    /job:localhost/replica:0/task:0/gpu:0 -> device: 0, name: GeForce GTX 760, pci bus id: 0000:01:00.0
    I tensorflow/core/common_runtime/direct_session.cc:252] Device mapping:
    /job:localhost/replica:0/task:0/gpu:0 -> device: 0, name: GeForce GTX 760, pci bus id: 0000:01:00.0
    
    After which everything looks good (i.e. GPU operations run on the GPU).
    
    What rpm should be doing the node creation ?
    
    Reply
    1. slaanesh says:
      
      November 25, 2016 at 11:41 am
      
      There’s something wrong. The node creation is done once you load the nvidia module and the X driver is loaded. I’ve never done anything in that regard:
      
      $ ls -al /dev/nvidia* crw-rw-rw-. 1 root root 195, 0 Nov 25 09:04 /dev/nvidia0 crw-rw-rw-. 1 root root 195, 1 Nov 25 09:04 /dev/nvidia1 crw-rw-rw-. 1 root root 195, 255 Nov 25 09:04 /dev/nvidiactl crw-rw-rw-. 1 root root 195, 254 Nov 25 09:04 /dev/nvidia-modeset crw-rw-rw-. 1 root root 239, 0 Nov 25 09:04 /dev/nvidia-uvm
      
      Reply
      1. slaanesh says:
        
        November 25, 2016 at 11:42 am
        
        Are you running a system without X?
      2. mdda says:
        
        November 30, 2016 at 8:44 am
        
        My system is running without X. Even if X boots, it seems that if there’s no monitor attached to the Nvidia card, X will drop it from the listing.
        
        Either way, I don’t have a /dev/nvidia0 to do cuda through unless I create the symlink myself.
        
        FWIW, I wrote up my experience : http://blog.mdda.net/oss/2016/11/25/nvidia-on-fedora-25, http://blog.mdda.net/oss/2016/11/28/intel-modesetting-and-xorg
      3. slaanesh says:
        
        November 30, 2016 at 11:10 am
        
        Hello, I’ve read your blog posts, I think you can simplify the configuration. Of course that requires some testing.
        
        I would not use intel.modeset=1 and nomodeset like you did.
        
        After that, just rely only on the xorg.conf configuration to load the modesetting driver. In the xorg.conf configuration file you can remove all the InputDevice, Monitor, ServerLayout and Files sections, they should be not needed, the InputDevice sections for sure. Your Files section is also wrong, and does not contain the Nvidia GLX server module, which is already defined in the package /etc/X11/xorg.conf.d/99-nvidia-modules.conf:
        
        – http://us.download.nvidia.com/XFree86/Linux-x86/375.20/README/randr14.html
        – http://negativo17.org/nvidia-driver/ (example down below)
        
        So in your case, I would change /etc/default/grub, regenerate the Grub config file, reboot and use this xorg.conf:
        
        Section "ServerLayout" Identifier "X.org Configured" Inactive "Card0" EndSection Section "Device" Identifier "Card0" Driver "nvidia" Option "AllowEmptyInitialConfiguration" BusID "PCI:1:0:0" EndSection Section "Device" Identifier "Card1" Driver "modesetting" BusID "PCI:0:2:0" EndSection Section "Screen" Identifier "Screen0" Device "Card1" EndSection
        
        Also, regarding the device file creation. The device file is normally created when loading the Nvidia driver, so if X is not running the driver is not loaded and the device file is not created. As per the documentation you posted, you can use the nvidia-modprobe command that is in the package with the same name.
        It contains a SUID binary that creates the device files and set the appropriate permissions when automatic device creation is not available. It is called directly by Nvidia libraries:
        
        $ for i in $(rpm -ql nvidia-driver-libs.x86_64); do strings $i | grep nvidia-modprobe && echo $i; done /usr/bin/nvidia-modprobe /usr/lib64/libnvidia-cfg.so.1 /usr/bin/nvidia-modprobe /usr/lib64/libnvidia-cfg.so.375.20 /usr/bin/nvidia-modprobe /usr/lib64/libnvidia-eglcore.so.375.20 /usr/bin/nvidia-modprobe /usr/lib64/libnvidia-glcore.so.375.20 /usr/bin/nvidia-modprobe /usr/lib64/libnvidia-glsi.so.375.20 /usr/bin/nvidia-modprobe /usr/lib64/vdpau/libvdpau_nvidia.so.1 /usr/bin/nvidia-modprobe /usr/lib64/vdpau/libvdpau_nvidia.so.375.20
        
        I think I will make a blog post about this someday, for now I’m updating the driver page with this information.
      4. slaanesh says:
        
        November 30, 2016 at 11:11 am
        
        > I would not use intel.modeset=1 and nomodeset like you did.
        
        That was not clear sorry. I mean, remove intel.modeset=1 and also _remove_ nomodeset like you did.
      5. slaanesh says:
        
        November 30, 2016 at 11:20 am
        
        I’ve updated the driver page (towards the end).
Kartik says:

November 22, 2016 at 7:29 pm

Hi, I’ve installed nvidia-driver, kernel-devel and akmod-nvidia on fedora 25 cinnamon. After rebooting whenever I log in, t cinnamon desktop crashes and fall into fallback mode. Can you suggest how to fix this?

Reply
1. slaanesh says:
  
  November 23, 2016 at 1:11 pm
  
  Logs? Optimus laptop?
  
  Reply
2. jaspir says:
  
  November 29, 2016 at 11:35 pm
  
  pehaps delete secure boot. And graphics Auto/hybrid to Discrete in the Bios
  
  Reply
johnmik says:

November 22, 2016 at 12:01 pm

Hello,
do you know if there is a way to install not the latest nvidia driver but a specific version ? We are currently constraint to use vendors certified drivers for our applications and that’s often the n-1 or n-2 drivers version.
many thanks

Reply
1. slaanesh says:
  
  November 23, 2016 at 11:46 am
  
  I’m sorry but don’t know how I could do otherwise. I would need a lot of specific repositories for the different versions.
  What I’m offering is what is described in the table in the Nvidia driver page, that is:
  
  – RHEL/CentOS: long-lived branch release
  – Fedora: short-lived branch release
  – Fedora rawhide: beta
  
  By chance, as of today, the latest Nvidia driver version (375.20) is a long-lived branch release, so it’s everywhere.
  
  Reply
Espionage724 says:

November 20, 2016 at 6:50 am

I’m a little confused by the wording in the first post, but does KMS work? I wanted to try out Prime Sync with F25 and Xorg 1.19 but trying to enable KMS with nvidia-drm.modeset=1 causes the driver not to load. I’m not sure if I’m just missing something or what.

Reply
1. slaanesh says:
  
  November 20, 2016 at 9:18 pm
  
  Kernel modesetting is not compatible with SLI, it does not have a framebuffer driver (i.e. no console on fb devices like normal KMS drivers) and it requires a patched Mutter to operate with Gnome which is not yet merged:
  
  https://fedoraproject.org/wiki/Wayland_features#Nvidia_driver_support
  http://us.download.nvidia.com/XFree86/Linux-x86/375.20/README/kms.html
  
  So basically yes, it’s useless now. That’s why it is disabled in my packages. I will enable it once it can be made to work out of the box.
  
  Reply
Mike says:

November 20, 2016 at 2:44 am

Hi, running Fedora 24 and upgraded to 375.20 with an Nvidia 770 GTX. OpenGL runs fine, but whenever I try to launch Dota 2 or The Talos Principle in Vulkan, I get this

[ 87.671044] dota2[2537]: segfault at 48 ip 00007fad8b2e5ad9 sp 00007ffef7576e00 error 4 in libnvidia-glcore.so.375.20[7fad89f4a000+13e2000]

And Talos just gives me a segmentation fault after trying to load Vulkan.

Reply
1. slaanesh says:
  
  November 20, 2016 at 9:19 pm
  
  Unfortunately you need to write in the Nvidia forums, the driver is a binary blob and there’s not much we can do.
  
  Reply
Fabio says:

November 19, 2016 at 9:18 pm

It seems the 375.20 driver update is broken, Xorg complains that the kernel module has a different version (375.10) than the userspace driver (375.20), even after removing and reinstalling the kernel modules (and driver).

Reply
1. slaanesh says:
  
  November 20, 2016 at 1:01 am
  
  Just checked, packages are correct. Maybe you have some leftovers due to a missing reboot and/or module load/unload?
  
  Reply
  1. Fabio Valentini says:
    
    November 20, 2016 at 10:57 am
    
    I just tried again – and, additionally, did a “dracut –regenerate-all –force” – which seems to have fixed the problem. Sorry for the noise.
    
    Reply
Dominique Schaefer says:

November 14, 2016 at 7:55 pm

I made it work on fedora 25 with xorg 1.18. You have to downgrade Xorg from 1.19 to version 1.18 from fedora 24. After it’s working.

dnf downgrade xorg-x11-server\* –releasever=24 –allowerasing
echo “exclude=xorg-x11*” >> /etc/dnf/dnf.conf

After reinstall your nvidia driver.

Reply
Joakim Verona says:

November 12, 2016 at 11:26 pm

I’m having difficulty getting the drivers to work for me on my system.

Its a fedora 25 system that I upgraded from Fedora 24.

At the moment I get a segfault during X startup, aparently:

[ 25.641] (EE) Backtrace:
[ 25.642] (EE) 0: /usr/libexec/Xorg (OsLookupColor+0x139) [0x59e229]
[ 25.642] (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x7ffbd2ad75bf]
[ 25.642] (EE) 2: /lib64/libnvidia-glcore.so.375.10 (nvidiaAddDrawableHandler+0x54599e) [0x7ffbcd868a2c]

I put the complete xorg log here:
https://gist.github.com/jave/3df01788d014d6bc5999dd4ea5d1228b

Reply
1. slaanesh says:
  
  November 14, 2016 at 11:13 am
  
  As explained in the previous comments, driver 375.10 does not support the unreleased X server 1.19 that is now in Fedora 25. Even setting the IgnoreABI flag makes the X server crash. I’m sorry but you have to wait for a new driver.
  
  Reply
  1. espionage724 says:
    
    November 18, 2016 at 9:56 pm
    
    Hi, it would appear NVIDIA has released a new driver (375.20) that does support X 1.19: http://www.nvidia.com/download/driverResults.aspx/111596/en-us
    
    Reply
    1. slaanesh says:
      
      November 19, 2016 at 5:48 pm
      
      Uploading now. It’s a new long lived release, so I had to test it also for RHEL/CentOS.
      
      Reply
Globalstar says:

November 6, 2016 at 5:16 am

[ 1493.223] (EE) Backtrace:
[ 1493.224] (EE) 0: /usr/libexec/Xorg (OsLookupColor+0x139) [0x59e2d9]
[ 1493.224] (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x7f03434d15bf]
[ 1493.224] (EE) 2: /lib64/libnvidia-glcore.so.375.10 (nvidiaAddDrawableHandler+0x54599e) [0x7f033e262a2c]
[ 1493.224] (EE)
[ 1493.224] (EE) Segmentation fault at address 0

Reply
1. slaanesh says:
  
  November 7, 2016 at 9:41 am
  
  Nvidia drivers 375.10 do not yet suppport X.org 1.19, the driver installation is relying on the “IgnoreABI” directive in its configuration. Of course this does not give you any guarantee. Nvidia does not support unreleased X servers, so if you can not downgrade the X server to 1.18.x there’s not much you can do.
  
  Reply
  1. Andy Lee Robinson says:
    
    November 8, 2016 at 9:27 pm
    
    I was caught by this a couple of days ago while upgrading from fc24 to fc25.
    I eventually managed to downgrade a large chunk of the system to get to a hybrid fc24¾
    
    Looking through my bash history I found some commands I tried with varying degrees of success that may help someone else in the same situation, but do check to see what other packages may be removed before committing. I can’t remember which were successful!
    I use dnf with cache enabled and mounted on an nfs share, useful with 6 machines to maintain.
    
    dnf reinstall nvidia\* –release=24
    dnf downgrade xorg\* –releasever=24
    dnf downgrade gdm\* –releasever=24
    dnf remove mlt-freeworld
    dnf downgrade gnome\* –releasever=24 –allowerasing –exclude=mlt\*
    dnf install –releasever=24 akmod-nvidia nvidia-driver nvidia-driver-cuda nvidia-driver-cuda-libs nvidia-driver-cuda-libs.i686 nvidia-driver-libs nvidia-driver-libs.i686 nvidia-libXNVCtrl nvidia-modprobe nvidia-persistenced nvidia-settings
    akmods –force
    grub2-mkconfig -o /boot/grub2/grub.cfg
    dnf install vlc vlc-core –releasever=24 –allowerasing
    
    Now I got my main X system working again, but without firefox as it’s caught in a Catch 22 situation.
    All my servers are running fc25 fine in text mode.
    
    My advice to anyone wanting to upgrade to fc25 and use X with the nvidia drivers is to hold off just a little bit longer until we know it’ll work.
    
    Reply
Marcus Brubaker says:

October 25, 2016 at 8:18 pm

Any chance of updating the CUDA packages for Fedora 24 to 8.0? I need the new version but I’d rather not upgrade to Fedora 25 while it’s still in beta.

Either way though, much appreciated!

Reply
1. slaanesh says:
  
  October 25, 2016 at 11:39 pm
  
  Just done, I’ve made a week of testing!
  http://negativo17.org/cuda-8-cudnn-nvidia-drivers-and-gnome-software-metadata/
  
  Reply
Vallimar says:

October 21, 2016 at 3:37 pm

On Fedora 25, this happens with the new libglvnd packages. Some libraries still need to be hidden unless you are going to start recompiling mesa as well:

Error: Transaction check error:
file /usr/lib64/libGL.so.1 from install of libglvnd-glx-1:0.2.999-2.20161017gita813b56.fc25.x86_64 conflicts with file from package mesa-libGL-12.0.3-2.fc25.x86_64

Reply
1. slaanesh says:
  
  October 21, 2016 at 5:12 pm
  
  I’m working with Adam Jackson and other people in Red Hat on it, that’s why the changes. Can you make a test with Adam’s Mesa build? That has support for libglvnd:
  
  https://copr.fedorainfracloud.org/coprs/ajax/glvnd/
  
  Reply
  1. Jeremy Rimpo says:
    
    October 21, 2016 at 7:53 pm
    
    I had a conflict with 32-bit wine/playonlinux because the copr repo doesn’t provide the i686 packages on x86_64. I worked around it by manually creating a new .repo file pointing to the i386 packages. I’m also currently withholding the new xorg packages due to nvidia incompatibilities. Any idea if the new beta driver supports xorg 1.19?
    
    Reply
  2. Jeremy Rimpo says:
    
    October 21, 2016 at 8:05 pm
    
    Actually, I still seem to be having upgrade issues:
    
    Error: package nvidia-driver-libs-2:370.28-6.fc25.x86_64 conflicts with libglvnd-egl(x86-64) >= 0.1.1 provided by libglvnd-egl-1:0.2.999-2.20161017gita813b56.fc25.x86_64.
    package nvidia-driver-libs-2:370.28-6.fc25.i686 conflicts with libglvnd-egl(x86-32) >= 0.1.1 provided by libglvnd-egl-1:0.2.999-2.20161017gita813b56.fc25.i686.
    package nvidia-driver-libs-2:370.28-4.fc25.i686 requires nvidia-driver = 2:370.28-4.fc25, but none of the providers can be installed
    
    Reply
    1. slaanesh says:
      
      October 21, 2016 at 8:19 pm
      
      Ok, Mesa with GLVND enabled and Nvidia drivers without a libEGL.so.1 can not co-exist, as mesa-libEGL requires libglvnd-egl. I hope Nvidia will release soon drivers compatible with libglvnd’s implementation or it will be a complete mess. Nvidia library is *similar* to the one in libglvnd but different. If a similar driver reaches the release date of Fedora 25 there will be *two* libEGL.so.1 libraries based on libglvnd. Argh.
      
      As written here:
      
      https://devtalk.nvidia.com/default/topic/915640/unix-graphics-announcements-and-news/multiple-glx-client-libraries-in-the-nvidia-linux-driver-installer-package/
      
      “libEGL.so.1, while not a proper GLVND library, depends upon the GLVND infrastructure for proper functionality.”
      
      I’m reverting the change in libglvnd.
      
      Reply
      1. Vallimar says:
        
        October 21, 2016 at 9:08 pm
        
        I replied a bit late, but per my comment below, Nvidia just released 375.10 driver with what appeared to be a different libEGL, so you might want to test with that first?
      2. slaanesh says:
        
        October 23, 2016 at 11:03 am
        
        I built 375.10, and indeed it now contains 2 different libEGL.so libraries, one standalone and one based on libglvnd, pretty much like their 2 different libGL.so libraries.
        
        The documentation/release notes still do not report this change and still use the above wording. I made a test with libglvnd‘s EGL library and it does not work yet:
        
        $ eglinfo eglinfo: eglInitialize failed $ strings libEGL.so.1 | grep -i glvnd 1.5 libglvnd /etc/glvnd/egl_vendor.d:/usr/share/glvnd/egl_vendor.d %s/.glvndXXXXXX
        
        So situation is that libglvnd’s EGL is not supported.
        
        Regarding the additional changes, I made the CUDA package to build on i686 for just the cuda-nvml-devel subpackage, so now nvidia-settings can be built. Will release the drivers in a moment, as soon as I reset EGL status.
      3. slaanesh says:
        
        October 25, 2016 at 11:40 pm
        
        This is fixed, drivers are using EGL from GLVND libraries.
  3. Vallimar says:
    
    October 21, 2016 at 9:05 pm
    
    It installs fine using that Mesa build. I can’t test if it is actually working yet though.
    I also just updated to Nvidia’s 375.10 driver which requires a few changes.
    
    Reply
OppA says:

October 17, 2016 at 10:55 am

Hello. I have installed your repo drivers on fresh fedora 25 with 4.8.1-1.fc25.x86_64 with 01:00.0 VGA compatible controller: NVIDIA Corporation GF119M [GeForce GT 520M] (rev a1). Gdm is not starting with “Oh, no” error. Can you help me?

Reply
1. OppA says:
  
  October 17, 2016 at 10:58 am
  
  Forgot to say, that WaylandEnable=false is uncommented.
  
  Reply
jeremy9856 says:

October 13, 2016 at 11:27 pm

Hello,
Do you have some trouble with suspend too ? On my desktop (GT430) 1 time on 3 resume doesn’t work and I end up with a black screen. No problem with nouveau.

Reply
1. jeremy9856 says:
  
  October 20, 2016 at 11:15 am
  
  Well it seems that it’s not a nvidia driver problem. Resume can fail too with nouveau and radeon on my desktop…
  
  Reply
fancyzhx says:

October 9, 2016 at 6:28 pm

Have been using your NVIDIA repo for nearly a year, and it has been awesome. I use both nvidia-driver and the cuda package for deep learning purposes, and ffmpeg (from your other repo) as well to preprocess data. Now we are going to have a bunch of GTX 1080, CUDA 8.0 support would be nice! Thanks for the amazing work!

Reply
1. slaanesh says:
  
  October 9, 2016 at 9:41 pm
  
  Thanks! I’m working on it right now.
  It will take a while, though. It replaces NVML (GPU Deployment kit) headers as well and I’m planning to build FFmpeg also with NPP/CUVID support:
  
  https://github.com/negativo17/ffmpeg/commit/e996b7dab89c3e96a55d04796a16000da479a58b
  
  Feedback on the CUDA packages is much welcome, as you can guess not many people use the packages.
  Thanks!
  
  Reply
2. slaanesh says:
  
  October 13, 2016 at 2:48 pm
  
  Hello, which distribution are you running? CentOS 7 or Fedora?
  
  Reply
  1. fancyzhx says:
    
    October 17, 2016 at 5:23 pm
    
    I install the latest Fedora anywhere I can; but some of machines are managed by CentOS 7. Only in Fedora we use your repositories.
    
    The best thing about your CUDA package is the host_config.h file you changed. It can compile even with the constantly updated GCC in Fedora. Some times I need to append a -std=c++03 for legacy cuda code, but other than that everything works smoothly.
    
    I personally think the compiler version check is complete BS from NVIDIA’s end. Forbidding the user from compiling code using a new compiler is utterly wrong. The correct approach is to give linking or run-time error if the code compiled does not work (but why on earth wouldn’t it work if the ABI is used correctly, regardless of compiler version?). Thanks to your amazing work this is not a problem in Fedora at all.
    
    Reply
    1. slaanesh says:
      
      October 25, 2016 at 11:40 pm
      
      Just done, I’ve made a week of testing!
      http://negativo17.org/cuda-8-cudnn-nvidia-drivers-and-gnome-software-metadata/
      
      Reply
      1. fancyzhx says:
        
        October 26, 2016 at 2:18 am
        
        Thanks! I just saw the new versions from dnf today. Will test in the next week and let you know how it goes.
        
        Thanks for adding cudnn as well, BTW!
      2. fancyzhx says:
        
        October 26, 2016 at 10:02 pm
        
        Every works smoothly for the driver and CUDA, but only one problem for cudnn on Fedora 24 x64:
        
        # dnf install cuda-cudnn
        Last metadata expiration check: 3:16:26 ago on Wed Oct 26 12:18:50 2016.
        Error: nothing provides cuda = 1:8.0 needed by cuda-cudnn-1:5.1-1.fc24.x86_64
        (try to add ‘–allowerasing’ to command line to replace conflicting packages)
        
        I use my own libcudnn.so for now so it is not a serious issue. Thanks for the great work!
      3. slaanesh says:
        
        October 26, 2016 at 10:19 pm
        
        Yep, that’s a leftover of a useless dependency. You can just install it with rpm -Uvh --nodeps http://negativo17.org/repos/nvidia/fedora-25/x86_64/cuda-cudnn-5.1-1.fc25.x86_64.rpm.
        New build coming in a few minutes.
        
        Thanks for reporting.
      4. fancyzhx says:
        
        November 2, 2016 at 10:57 pm
        
        I used the cuda 8.0 repo for a few days (including cudnn with fixed dependency) for training my neural nets, and everything works smoothly. Just want to say thanks!
Clodoaldo Pinto Neto says:

October 8, 2016 at 2:56 am

libglvnd 0.2.999-2.git14f6283.fc24 from updates-testing is crashing the system. Running KDE. Apart from not updating it is there anything that can be done?

Reply
1. slaanesh says:
  
  October 8, 2016 at 12:19 pm
  
  Yeah, just saw that as well. libglvnd 0.2.x It is not supported by the Nvidia drivers which still require version 0.1. Since there is support for nothing yet, if installed will just make things crash. Maybe it was better to coordinate the update containing libglvnd with the one containing Mesa support into one.
  
  I’m rebuilding 0.1.1 with an updated Epoch, so Nvidia drivers will keep running.
  
  Reply
robFrobisher says:

October 5, 2016 at 11:44 am

Will you be upgrading the repo to CUDA 8? Many thanks for all the amazing work!

Reply
1. slaanesh says:
  
  October 5, 2016 at 3:37 pm
  
  Working on it right now! It will take a while, though. It replaces NVML (GPU Deployment kit) headers as well and I’m planning to build FFmpeg also with NPP:
  
  https://github.com/negativo17/ffmpeg/commit/e996b7dab89c3e96a55d04796a16000da479a58b
  
  Feedback on the CUDA packages is much welcome, as you can guess not many people use the packages.
  
  Thanks!
  
  Reply
  1. ROBFROBISHER says:
    
    October 14, 2016 at 9:23 pm
    
    Many thanks for the response! My whole lab uses your Fedora CUDA repo for ML/Deep Learning research so we cannot thank you enough. Some software, such as Theano, expects the CUDA normal directory structure but that is the only real problem we have had. Mostly we use TensorFlow now so it’s really not a problem.
    
    Thanks again.
    
    Reply
    1. slaanesh says:
      
      October 25, 2016 at 11:41 pm
      
      Just done, I’ve made a week of testing!
      http://negativo17.org/cuda-8-cudnn-nvidia-drivers-and-gnome-software-metadata/
      
      Reply
      1. ROBFROBISHER says:
        
        October 27, 2016 at 11:39 am
        
        Amazing work., thank you very much! I also see that you have added CuDNN 5.1 into the repo as well. Is it recommended to remove the old CUDA install before upgrading?
      2. slaanesh says:
        
        October 27, 2016 at 12:35 pm
        
        Thanks! No you can just straight upgrade everything, all packages have the appropriate upgrade paths.
jeremy9856 says:

September 22, 2016 at 5:57 pm

Hello,

I reinstalled the drivers (# dnf install nvidia-driver dkms-nvidia nvidia-driver-libs.i686) (I tested nouveau driver) and I noticed that nvidia-settings wasn’t installed. I installed it manually (# dnf install nvidia-settings). Is it intended ?

Thanks !

Reply
1. slaanesh says:
  
  September 23, 2016 at 9:46 am
  
  Hello, yes it is, since a few days. Unfortunately I had no time to create a blog post about this.
  I’ve been contacted by Red Hat, they asked me to add AppStream metadata for the Nvidia repository (Fedora 25+) and make nvidia-settings optional. Will try to make a post this weekend.
  
  Reply
  1. jeremy9856 says:
    
    September 23, 2016 at 10:51 am
    
    Ok, thank you 🙂
    
    Reply
    1. slaanesh says:
      
      September 23, 2016 at 3:39 pm
      
      I’ve updated the documentation, also with information for Gnome Software on Fedora 25. Post coming.
      
      Reply
Niels says:

September 8, 2016 at 8:27 am

After F24 did update the kernel to 4.7.2-201, I think all my computers with Nvidia cards, had the graphical start-up destroyed. I have a mixed setup on several computers and is using both the 340xx driver and the 367 depending of the computer.
On one of the work computers (Geforce GT650, using akmod and the 67.44-1.fc24@fedora-nvidia), shutdown takes a looooooong time.. like 6-10mins (sometime start-up is also slow)

After I did read the /var/log/messages, I realized that the system tries to build a (a)kmod driver for each kernel on shutdown, but fails for some of the “extra/older” kernels I have in my boot list.

Like here (from /var/log/messages, only akmod log entries) some builds succeed and some fails

Sep 8 07:32:59 akmods-shutdown: Building modules for all installed kernels.
Sep 8 07:32:59 akmods-shutdown: Checking kmods exist for 4.6.3-300.fc24.x86_64[ OK ]
Sep 8 07:34:21 akmods-shutdown: Building and installing nvidia-kmod[ OK ]
Sep 8 07:34:21 akmods-shutdown: Checking kmods exist for 4.6.3-300.fc24.x86_64+debug[ OK ]
Sep 8 07:35:30 akmods-shutdown: Building and installing nvidia-kmod[FAILED]
Sep 8 07:35:30 akmods-shutdown: Building rpms failed; see /var/cache/akmods/nvidia/367.44-1-for-4.6.3-300.fc24.x86_64+debug.failed.log for details
Sep 8 07:35:31 akmods-shutdown: Hint: Some kmods were ignored or failed to build or install.
Sep 8 07:35:31 akmods-shutdown: You can try to rebuild and install them by by calling
Sep 8 07:35:31 akmods-shutdown: ‘/usr/sbin/akmods –force’ as root.
Sep 8 07:35:33 akmods-shutdown: Checking kmods exist for 4.6.4-301.fc24.x86_64[ OK ]
Sep 8 07:35:33 akmods-shutdown: Checking kmods exist for 4.6.4-301.fc24.x86_64+debug[ OK ]
Sep 8 07:36:42 akmods-shutdown: Building and installing nvidia-kmod[FAILED]
Sep 8 07:36:42 akmods-shutdown: Building rpms failed; see /var/cache/akmods/nvidia/367.44-1-for-4.6.4-301.fc24.x86_64+debug.failed.log for details
Sep 8 07:36:42 akmods-shutdown: Hint: Some kmods were ignored or failed to build or install.
Sep 8 07:36:42 akmods-shutdown: You can try to rebuild and install them by by calling
Sep 8 07:36:42 akmods-shutdown: ‘/usr/sbin/akmods –force’ as root.
Sep 8 07:36:44 akmods-shutdown: Checking kmods exist for 4.7.2-201.fc24.x86_64[ OK ]
Sep 8 07:36:44 akmods-shutdown: Checking kmods exist for 4.7.2-201.fc24.x86_64+debug[ OK ]
Sep 8 07:37:54 akmods-shutdown: Building and installing nvidia-kmod[FAILED]
Sep 8 07:37:54 akmods-shutdown: Building rpms failed; see /var/cache/akmods/nvidia/367.44-1-for-4.7.2-201.fc24.x86_64+debug.failed.log for details
Sep 8 07:37:54 akmods-shutdown: Hint: Some kmods were ignored or failed to build or install.
Sep 8 07:37:54 akmods-shutdown: You can try to rebuild and install them by by calling
Sep 8 07:37:54 akmods-shutdown: ‘/usr/sbin/akmods –force’ as root.

Then sometime on boot, the system again tries to build for older kernels. (and the boot takes loooOOoong time)

Is it somehow possible to configure for only building for the newest kernel ?

(BTW. I wonder why the 4.7.2-201… says “OK” for exist of the kmod, but fails on installing.. (int the log above), when the computer on boot, boots really fast with that driver..)

Oh.. And thanks for a great site, and all the work you put into it.

Reply
1. slaanesh says:
  
  September 8, 2016 at 9:34 am
  From the logs above it seems you are building for both kernel and kernel-debug. Are you booting into it or the normal one?
  If you don’t need it, can you remove all kernel-debug components and see if that happens?
```
# dnf remove kernel-debug\*
```
  Reply
Clodoaldo Pinto Neto says:

August 25, 2016 at 2:28 am

367.35 fails to build in F24 4.7.2-200 kernel: http://pastebin.com/Ria3eCFw

Reply
1. slaanesh says:
  
  August 25, 2016 at 8:44 pm
  
  367.44 is coming.
  
  Reply
zerionseven says:

August 17, 2016 at 7:58 pm

Thanks for all your hard work on this great repo.

Could NVENC be updated to 7.0? (6.0.1 doesn’t seem to work with Pascal GPUs)

Reply
1. slaanesh says:
  
  August 17, 2016 at 8:33 pm
  
  Sure, I will do. The problem is that it has to be supported by both Gstreamer and FFMpeg. I haven’t yet checked if it’s compatible.
  
  Reply
  1. slaanesh says:
    
    August 21, 2016 at 1:08 pm
    
    NVENC 7.0.1 is available. It is compatible with Gstreamer bad plugins 1.8, 1.9 and FFMpeg 2.8.7 and 3.1.2.
    Rebuilds of all those components are now available.
    
    Reply
Dmitry says:

August 15, 2016 at 8:25 am

Hello! Fedora newbie is here.
After fresh installing and updating F24 I tried to install nvidia drivers for my GeForce GTX 560. But failed. What I’ve done:
installed your repository
after that “dnf install nvidia-driver dkms-nvidia” like in your example.
Reboot… Blank white screen with error cycling.

Do you have step-by-step instructions? Should I follow steps under “specific driver installation”?

Reply
1. slaanesh says:
  
  August 15, 2016 at 6:13 pm
  
  Apart from that, you should make sure you are installing kernel-devel from the command line. If you are relying on its own dependencies, as explained in the comments above, you hit a depsolv bug that actually pulls in kernel-debug-devel. If it did on your system, remove it, and install the one without debug. It’s listed in the commands required in the driver page.
  
  Reply

Nvidia driver, CUDA tools and libraries

Repository installation

What’s different?

Nvidia drivers

Packaging

Versioning

CUDA support

Kernel modules

Default configuration

Kernel modesetting and Wayland support

Optimus laptops

Limitations with the Nvidia driver

Limitations with the OSS stack

SLI systems

Nouveau fallback

Sample installation

Package installation

Specific driver installations

Proprietary and open source kernel modules

DKMS

akmods

Additional driver configuration to your system

Configuration for CUDA only systems

Option with only CUDA components installed

CUDA

Packaging

Distribution and CUDA version support

CUDA installations

Bugs

Like this:

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

Leave a ReplyCancel reply

Recent Comments

Repository installation

What’s different?

Nvidia drivers

Packaging

Versioning

CUDA support

Kernel modules

Default configuration

Kernel modesetting and Wayland support

Optimus laptops

Limitations with the Nvidia driver

Limitations with the OSS stack

SLI systems

Nouveau fallback

Sample installation

Package installation

Specific driver installations

Proprietary and open source kernel modules

DKMS

akmods

Additional driver configuration to your system

Configuration for CUDA only systems

Option with only CUDA components installed

CUDA

Packaging

Distribution and CUDA version support

CUDA installations

Bugs

Share this:

Like this:

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

Leave a ReplyCancel reply

Recent Comments