Nvidia driver, CUDA tools and libraries

nvidia-logo-1

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

Repository installation

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

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

To install the repository on CentOS/RHEL:

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

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

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

What’s different?

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

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

Nvidia drivers

Packaging

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

Versioning

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

CUDA support

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

Kernel modules

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

Default configuration

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

Kernel modesetting and Wayland support

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

Distribution and Nvidia driver version support

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

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

x86_64
aarch64		YesYesYes
Basic nvidia driver:

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

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

libnvidia-fbc		YesYesYes
Nvidia tools:

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

kmod-nvidia		YesNoNo
DKMS kernel
modules:

dkms-nvidia		YesYesYes
aKMOD kernel
modules:

akmod-nvidia		NoYesYes
32 bit compatibility on x86_64:

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

Optimus laptops

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

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

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

Everything else should not be different from your normal experience.

Limitations with the Nvidia driver

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

Limitations with the OSS stack

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

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

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

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

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

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

SLI systems

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

Nouveau fallback

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

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

Sample installation

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

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

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

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

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

Package installation

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

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

yum -y remove *nvidia*

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

yum -y install nvidia-driver nvidia-settings

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

dnf -y install nvidia-driver nvidia-settings

Specific driver installations

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

akmod kernel module variant (Fedora):

dnf -y install nvidia-driver akmod-nvidia

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

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

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

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

Proprietary and open source kernel modules

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

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

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

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

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

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

DKMS

Check which version you have installed:

# modinfo -l nvidia
NVIDIA

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

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

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

# modinfo -l nvidia
Dual MIT/GPL
# reboot

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

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

akmods

Check which version you have installed:

# modinfo -l nvidia
NVIDIA

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

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

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

# modinfo -l nvidia
Dual MIT/GPL
# reboot

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

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

Additional driver configuration to your system

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

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

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

Configuration for CUDA only systems

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

Option with only CUDA components installed

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

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

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

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

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

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

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

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

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

CUDA

Packaging

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

Distribution and CUDA version support

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

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

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

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

CUDA installations

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

yum -y install cuda nvidia-driver-cuda

To just install packages required for enabling CUDA development:

yum -y install cuda-devel

Or if you just want to enable everything:

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

A couple of examples. Just the basic tools:

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

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

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

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

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

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

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

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

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

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

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

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

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

Bugs

Just open an issue to the specific package on GitHub.

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

  1. Hi, are there any plans to support beta driver soon?
    I tried to setup releasever=rawhide but your repo does not seem to support it, even though you said rawhide would have beta drivers. Am I missing something?

    Reply

    1. No rawhide support, sorry. I normally enable the branch when the distribution is forked or close to release.

      Reply

  2. Slaanesh, do you maintain the Fedora software center version? It installs fine but fails to work. Nouveau is always running when its installed that way so its kind of broken 🙁

    Reply

  3. Cannot download ‘http://negativo17.org/repos/nvidia/fedora-28/x86_64/’: Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried.

    dnf reinstall dkms-nvidia.x86_64 –releasever=27

    Can support Fedora 28?

    Reply

  4. I had try many different distros on my optimized laptop, installing CUDA but all failed with problem of insufficient version of CUDA runtime. Bumblebee always block my way, although it’s really useful.

    Follow your tutorial, everything is work as expect :-D. And it seems that standalone NVIDIA is faster than bumblebee-nvidia.

    Thank you very much for your great work!

    Reply

  5. So after last dkms and kernel update, nvidia kernel module didn’t build again and felt back to nouveau. For some odd reason dkms wouldn’t build kernel module on boot, like it wasn’t installed. After dkms install -m nvidia -v 390.42 it built and works again. this situation happens when new driver/dkms and new kernel version is being installed in the same update, if it was just driver or just kernel it would compile new module and work fine after reboot.

    Also a note to everyone, who for some reason wish to use RPMFusion together with negativo17 repo, to avoid conflicts modify fedora-nvidia or fedora-multimedia repo config file and add parameter priority=N, where N is any integer lower than 99. It will prioritize negativo packages over those from rpmfusion

    Reply

    1. Hello,

      this situation happens when new driver/dkms and new kernel version is being installed in the same update

      Ah, that’s cool to know, because it did not happen on my systems and I couldn’t reproduce it. Thanks for the explanation.

      who for some reason wish to use RPMFusion together with negativo17 repo, to avoid conflicts modify fedora-nvidia or fedora-multimedia

      If this is the case I would suggest you just use RPMFusion. Multimedia repo does not play nicely with RPMFusion.

      Cheers.

      Reply

  6. So the last month or so of updates have been failing whenever it tries to finish up the kernel update process. On FC27 (fresh install 6 weeks ago), I get an indefinite hang at:

    Running scriptlet: kernel-core-4.15.10-300.fc27.x86_64

    It simply never finishes. ps -ef shows that this scriptlet is actually running /var/tmp/rpm.* (some random assortment of characters.

    That file shows it’s simply running : /bin/kernel-install add 4.15.10-300.fc27.x86_64 /lib/modules/4.15.10-300.fc27.x86_64/vmlinuz || exit $?

    /var/log/messages shows that it’s trying to use dracut:

    Mar 22 10:05:20 HOSTNAME dracut[5272]: dracut-046-8.git20180105.fc27
    Mar 22 10:05:20 HOSTNAME dracut[5274]: Executing: /usr/bin/dracut -f /boot/initramfs-4.15.10-300.fc27.x86_64.img 4.15.10-300.fc27.x86_64

    CTRL-Cing or killing the process and attempting to run “/bin/kernel-install add 4.15.9-300.fc27.x86_64 /lib/modules/4.15.9-300.fc27.x86_64/vmlinuz” also never finishes

    dkms status shows:

    dkms status
    nvidia, 390.42, 4.15.7-300.fc27.x86_64, x86_64: installed

    Out of the last 10 kernel updates I’ve tried, only 4.15.7-300 actually completed the scriptlet.

    I’ve been running fedora on this same machine, same hardware, since FC22 and never had these issues until recently. Something is broken when the dkms module is attempting to configure new kernels.

    Ideally I’d like to completely remove all elements of negativo and move on to another nvidia option without having to rebuild my machine. Any thoughts?

    Reply

    1. I don’t think it is related, but if you want to remove everything you can just remove all the repository definition files and just do a:

      dnf repoquery --extras

      It will print out all packages that are not in the main repositories. You can remove all of those.

      Reply

  7. After installing kernel 4.15.10-300 I get an error when inserting the nvidia kernel module:

    ~ # modprobe -v nvidia
    insmod /lib/modules/4.15.10-300.fc27.x86_64/extra/nvidia.ko.xz
    modprobe: ERROR: could not insert ‘nvidia’: Invalid argument

    ~ # dkms status
    nvidia, 390.42, 4.15.10-300.fc27.x86_64, x86_64: installed

    Any ideas how to fix?

    Reply

    1. Does anybody know a solution or point me in the right direction? I’ve looked through journalctl and dmesg but I can’t find any details on the “invalid argument”. Also tried a complete reinstall (rpm -e –nodeps dkms-nvidia), rebuilding modules, etc but nothing seems to work.

      Reply

  8. Hi there,

    First of all, thank you so much for this great repository!

    I’m having a issue on my (secured boot) system.

    Before, the driver was working perfectly on the kernel 4.15.9. As you can see in the list bellow, the modules were installed in plain *.ko files. So I could sign and use them.

    ls -l /lib/modules/4.15.9-300.fc27.x86_64/extra/

    total 22148
    drwxr-xr-x. 2 root root 4096 mar 19 13:18 bbswitch
    drwxr-xr-x. 10 root root 4096 mar 19 13:07 drivers
    drwxr-xr-x. 13 root root 4096 mar 19 13:07 fs
    drwxr-xr-x. 13 root root 4096 mar 19 13:07 net
    -rw-r–r–. 1 root root 37732 mar 21 13:37 nvidia-drm.ko
    -rw-r–r–. 1 root root 19556388 mar 21 13:37 nvidia.ko
    -rw-r–r–. 1 root root 1459729 mar 21 13:37 nvidia-modeset.ko
    -rw-r–r–. 1 root root 1597729 mar 21 13:37 nvidia-uvm.ko

    However, after the last kernel updated, the modules became compressed, and I can’t sign them more, and consequently I can’t use them too.

    ls -l /lib/modules/4.15.10-300.fc27.x86_64/extra/

    total 20
    drwxr-xr-x. 2 root root 4096 mar 21 13:36 bbswitch
    drwxr-xr-x. 10 root root 4096 mar 21 13:20 drivers
    drwxr-xr-x. 13 root root 4096 mar 21 13:20 fs
    drwxr-xr-x. 13 root root 4096 mar 21 13:20 net
    drwxr-xr-x. 2 root root 4096 mar 21 15:56 nvidia

    ls -l /lib/modules/4.15.10-300.fc27.x86_64/extra/nvidia/

    total 7908
    -rw-r–r–. 1 root root 17404 mar 21 15:55 nvidia-drm.ko.xz
    -rw-r–r–. 1 root root 7390780 mar 21 15:55 nvidia.ko.xz
    -rw-r–r–. 1 root root 410024 mar 21 15:55 nvidia-modeset.ko.xz
    -rw-r–r–. 1 root root 268744 mar 21 15:55 nvidia-uvm.ko.xz

    I just tried to remove an (re)install the packages again, but the modules are still compressed. And I don’t remember how I’ve installed before to be uncompressed.

    My question is: how can I use the secure boot with the compressed modules and don’t have this issue every time the kernel is update?

    Thanks in advance!

    Reply

    1. Just a update… I figured out a way to sign and use the modules:

      First, I’ve uncompressed all nvidia modules, and regenerate de modules.dep and map…

      $ sudo unxz /lib/modules/4.15.10-300.fc27.x86_64/extra/nvidia/nvidia*

      $ sudo depmod -a

      Then I could sign the modules and insert the nvidia via modprobe

      I know that it isn’t the best or beauty solution, but its kind of working now. 🙂

      Reply

  10. I use an Asus Geforce GTX 1070 nvidia card with 8 GB of memory. I am also using the nvidia driver source from negativo17 for version 390.25. Within Nvidia X Server Configuration I have selected FXAA Antialiasing within the opengl settings and that has caused an issue in my F27 implementation. With that option active, the KDE kicker, active applications in the taskbar and the system tray contents all get displayed as white on white, and all applications, irrespective of whether the application is a native KDE application or a GTK application, text is displayed out of focus until either I mouse over them (in some cases) or scroll the window in which case the text is sharp and readable. If I unselect the FXAA option and set the Anti-alias option to 16x I don’t get the same issue.
    Am I missing something in the installation, I have nvidia-driver installed and the dkms-nvidia package to compile the driver?

    Reply

  11. Hello!

    I am having problems to access to the negativo17 repos, dnf give me:
    Failed to synchronize cache for repo ‘fedora-nvidia’, disabling.

    Thanks!

    Reply

  12. First of all, thank you very much for maintaining this repository! It is by far the easiest way to get CUDA up and running properly on Linux.
    Just a little wishlist item: could you please consider keeping old versions of CUDA around for a little longer?

    Asking because I (and probably many others) use TensorFlow, which is very slow when it comes to adopting new CUDA versions. For example, TensorFlow 1.6 was released yesterday and runs only on CUDA 9.0 (released in September), despite the fact that CUDA 9.1 has been “stable” for almost three months.

    Reply

  13. Last time I tried to update nvidia-driver I got conflict with xorg-x11-drv-nvidia from rpmfusion.

    Problem: package nvidia-driver-2:390.25-2.fc27.x86_64 conflicts with xorg-x11-drv-nvidia provided by xorg-x11-drv-nvidia-3:390.25-4.fc27.x86_64
    – package akmod-nvidia-3:390.25-3.fc27.x86_64 requires nvidia-kmod-common >= 3:390.25, but none of the providers can be installed
    – cannot install the best update candidate for package nvidia-driver-2:390.25-2.fc27.x86_64
    – cannot install the best update candidate for package akmod-nvidia-2:390.25-2.fc27.x86_64

    Is there any issue with nvidia-driver package?

    Reply

    1. Sorry for repost I didn’t noticed the same comment bellow me. But I don’t have xorg-x11-drv-nvidia installed and I still have this error.
      Here is rpm -qa |grep xorg-x11-drv output:
      xorg-x11-drv-fbdev-0.4.3-28.fc27.x86_64
      xorg-x11-drv-evdev-2.10.5-4.fc27.x86_64
      xorg-x11-drv-qxl-0.1.5-5.fc27.x86_64
      xorg-x11-drv-openchrome-0.6.0-3.fc27.x86_64
      xorg-x11-drv-vmware-13.2.1-4.fc27.x86_64
      xorg-x11-drv-nouveau-1.0.15-3.fc27.x86_64
      xorg-x11-drv-libinput-0.26.0-1.fc27.x86_64
      xorg-x11-drv-intel-2.99.917-31.20171025.fc27.x86_64
      xorg-x11-drv-wacom-0.35.0-3.fc27.x86_64
      xorg-x11-drv-vesa-2.3.2-28.fc27.x86_64
      xorg-x11-drv-ati-7.9.0-3.fc27.x86_64

      Reply

        1. Hey Slaanesh,

          Is there any way i can get my hands on one of your ver387.xx or 384.xx rpm packages? The 390 completely bricked my centos7 box and i don’t have any of the older versions saved anywhere. Running without a driver right now 🙁
          /desperate linux noob

          Reply

  14. I’m not sure what the deal is, but the most recent dkms-nvidia released today bricked my machine. I can still boot and see the logon screen fine, but after that the display freezes. I can still logon because I hear the sound and can type blindly open up a terminal and type “reboot,” but the display is stuck on the display manager logon screen. Even Ctl+Alt+F2 won’t open a TTY.

    Reply

    1. I have also seen similar strange full-system freezes that seem related to GPU usage with the latest version

      Reply

    2. I have the same behavior. I fixed it by uninstalling the drivers and reinstalling them. But this wasn’t a one-off event; after another kernel update it happened again. Trying the same solution again, but obviously this isn’t ideal.

      Reply

    3. Same problem here, DKMS doesn’t automatically recompile the kernel module when there’s a kernel update. But instead of freezing the system, Fedora boots on nouveau driver. Then, I need to recompile by hand with

      dkms install -m nvidia -v 390.42

      It also happens when I upgrade to a newer version of Fedora.

      Reply

      1. Weird. Works fine here, just tried with the kernel in updates-testing:

        # dkms status
nvidia, 390.42, 4.15.10-300.fc27.x86_64, x86_64: installed
nvidia, 390.42, 4.15.11-300.fc27.x86_64, x86_64: installed
        Reply

      1. Actually there are more issues with version 390.xx, according to my experience:
        – Segfaulting apps (example: https://github.com/linuxmint/Cinnamon/issues/5376, but it crashed my chrome as well)
        – suspend / resume issues (https://devtalk.nvidia.com/default/topic/1029683/suspend-swap-group-failed-resume-swap-group-failed-nvidia-390-25/)
        – Performance hits (see above)

        I had to revert back to 387.34 as well – Even if it’s not optimal with CUDA, it’s still more stable..

        Reply

  16. Hi,
    I’m with nvidia proprietary on Fedora 26 by several months.
    Today when I launch dnf upgrade appears the following warnings:

    Problem: package nvidia-driver-2:387.34-1.fc26.x86_64 conflicts with xorg-x11-drv-nvidia provided by xorg-x11-drv-nvidia-2:390.25-1.fc26.x86_64
    – package akmod-nvidia-2:390.25-1.fc26.x86_64 requires nvidia-kmod-common >= 2:390.25, but none of the providers can be installed
    – cannot install the best update candidate for package nvidia-driver-2:387.34-1.fc26.x86_64
    – cannot install the best update candidate for package akmod-nvidia-2:387.34-1.fc26.x86_64

    So I cannot install latest 390.25 drivers.
    Any ideas on how I can bypass this errors?

    Thanks

    Reply

    1. That is correct. The packages here conflict with the ones from RPMFusion, you can’t have both drivers installed at the same time.

      Reply

      1. Hi, thanks for the repo!

        I’m also encountering this package conflict, but I’m not sure what to uninstall. I’ve listed all of my installed packages, but ‘xorg-x11-drv-nvidia’ is nowhere to be found.

        Any advice would be greatly appreciated.

        Reply

      2. Would it work to mark the fedora-nvidia repo with a priority=10? This seems to work in the short-term, but I don’t know if it’s suggested for the long run.

        Reply

    1. I am rebuilding all the packages dependent on CUDA libraries right now. If all goes well, I’ll make a blog post in a couple of days and push everything (CUDA 9.1, drivers 390.25).

      Reply

      2. Same here, all the work on these repositories is very much appreciated.

        I’m also looking forward to new CUDA libraries and driver for RHEL7 because version 384.111 of the driver stopped working with the latest kernel version 4.15.

        Reply

          2. Just as an FYI, we are seeing issues with the 390.25 driver, I suspect related to this bug that was fixed in 390.30: “Fixed a bug in the JIT compiler which would result in some math functions (e.g. in the libdevice library) returning incorrect results”. We have to revert to the 384.111 driver packages for now.

  18. After the F27 upgrade to kernel-4.14.15 nvidia module didn’t load with the info:
    nvidia: version magic ‘4.14.15-300.fc27.x86_64 SMP mod_unload ‘ should be ‘4.14.15-300.fc27.x86_64 SMP mod_unload retpoline ‘

    Reply

  19. Does anyone experience quiet audio over nvidia hdmi?

    My HTPC is a i3-2100T and I used the integrated intel gpu till now, but as I experienced stuttering in Kodi, I have added a MSI nvidia GT1030 passive. While kodi no longer stutters, the audio I get to the TV over HDMI is very quiet. I need to boost it to 150% in pavucontrol, and turn up volume on TV double of what used to be normal before. I can’t find any setting to improve the audio level. The issue is that then I need to turn up and down TV volume as I switch inputs…

    Reply

    1. I think its likely the result of different hardware. Possibly nothing else you can do though I’ve never researched if anyone came up with something else. Pushing it past 100% is all I’ve ever used when necessary but like you said you’re using a TV which has its own volume controls, so that is the alternative.

      Those three choices in the end are all I know. Use a different audio device, push past 100% and have possible snap, crackle, pop or still too low volume at times, or pass it to receiver, tv, etc which has its own volume control.

      Reply

  20. Hi. Thanks for the great work. I am running a desktop with AMD 6 core CPU and Nvidia GeForce 200 card. I recently installed the driver and X Server Settings after adding the repo on my Fedora 27. However, when I opened X Server Settings it notified me that “You do not appear using Nvidia X driver. Please edit your X configuration file (just run ‘nvidia-xconfig’ as root), and restart the X server.

    The trouble is, after I installed nvidia-xconfig and run the command, I cannot log into my MATE desktop anymore. only after I deleted the file generated by nvidia-xconfig could I enter the system. Any suggestion as how to solve this issue? Thanks.

    Reply

  21. After upgrade to fc27 (kernel 4.14.11-300) the nvidia kernel modules are missing in /lib/modules/4.14.11-300.fc27.x86_64/extra/

    I’ve tried reinstalling the nvidia packages, but unfortunately that does not solve the problem. How do i recompile the modules manually? My system is completely up-to-date, SELinux is enabled and afaik the other prerequisites are met.

    Reply

    1. Are you using or ? In both cases you can force compile the modules just type the command and look for the output for the proper syntax. They also both provide build logs.

      Reply

      1. Thanks for the quick reply!

        I don’t know exactly what you mean by “Are you using or ?”. Do you mean akmod or dkms? In that case it’s dkms.

        Could you please tell me which command you mean? Been looking around here but i’m not sure what to do.

        Reply

        1. First of all check that is ok:

          # dkms status
nvidia, 387.34, 4.14.11-200.fc26.x86_64, x86_64: installed
xpad, 4.14: added

          If you don’t get that output:

          # dkms add nvidia/387.34
# dkms build nvidia/387.34
# dkms install nvidia/387.34
          Reply

          1. Or reinstall the module entirely:

            # rpm -e --nodeps dkms-nvidia
# dnf -y install dkms-nvidia

  22. Hello and thank you again for this repo!

    One of my home PCs keeps having it’s akmodsbuild fail for the NVIDIA drivers. Could you please give me some tips for troubleshooting this, or do you know where I should ask?

    To try to resolve I’ve installed mock (creating a mock group) and created a mockbuild user since that didn’t exist and there were warnings in the log. I’ve previously forced the build as root which may have mucked up permissions, so I recursively set them all back to ‘akmods:akmods’.

    When I run a build manually it works, but never automatically.
    For example, when run this works:
    sudo -H -u akmods bash -c ‘nice /sbin/akmodsbuild –target x86_64 –kernels 4.14.11-300.fc27.x86_64 /usr/src/akmods/nvidia-kmod.latest’

    The logs have:

    2018/01/05 06:02:46 akmods: Building RPM using the command ‘/sbin/akmodsbuild –target x86_64 –kernels 4.14.11-300.fc27.x86_64 /usr/src/akmods/nvidia-kmod.latest’
    2018/01/05 06:02:50 akmods: Building rpms failed; see /var/cache/akmods/nvidia/387.34-1-for-4.14.11-300.fc27.x86_64.failed.log for details

    and:

    2018/01/05 06:02:46 akmods: Building RPM using the command ‘/sbin/akmodsbuild –target x86_64 –kernels 4.14.11-300.fc27.x86_64 /usr/src/akmods/nvidia-kmod.latest’

    Session terminated, killing shell… CONFTEST: follow_pfn
    CONFTEST: hash__remap_4k_pfn
    CONFTEST: vmap
    CONFTEST: set_pages_uc
    CONFTEST: set_memory_uc
    CONFTEST: set_memory_array_uc
    CONFTEST: change_page_attr
    CONFTEST: pci_get_class
    CONFTEST: pci_choose_state
    CONFTEST: vm_insert_page
    CONFTEST: acpi_device_id
    CONFTEST: acquire_console_sem
    CONFTEST: console_lock
    CONFTEST: kmem_cache_create
    CONFTEST: on_each_cpu
    CONFTEST: smp_call_function
    CONFTEST: acpi_evaluate_integer
    make[2]: *** Deleting file ‘/tmp/akmodsbuild.12O2Etr3/BUILD/nvidia-kmod-387.34-x86_64/kmod_build_4.14.11-300.fc27.x86_64/conftest/compile-tests/acpi_evaluate_integer.h’
    make[2]: *** Deleting file ‘/tmp/akmodsbuild.12O2Etr3/BUILD/nvidia-kmod-387.34-x86_64/_kmod_build_4.14.11-300.fc27.x86_64/conftest/compile-tests/smp_call_function.h’
    make[2]: *** Deleting file ‘/tmp/akmodsbuild.12O2Etr3/BUILD/nvidia-kmod-387.34-x86_64/_kmod_build_4.14.11-300.fc27.x86_64/conftest/compile-tests/on_each_cpu.h’
    make[2]: *** Deleting file ‘/tmp/akmodsbuild.12O2Etr3/BUILD/nvidia-kmod-387.34-x86_64/_kmod_build_4.14.11-300.fc27.x86_64/conftest/compile-tests/kmem_cache_create.h’
    make[2]: *** [/tmp/akmodsbuild.12O2Etr3/BUILD/nvidia-kmod-387.34-x86_64/_kmod_build_4.14.11-300.fc27.x86_64/Kbuild:119: /tmp/akmodsbuild.12O2Etr3/BUILD/nvidia-kmod-387.34-x86_64/_kmod_build_4.14.11-300.fc27.x86
    64/conftest/compile-tests/kmem_cache_create.h] Terminated
    make[2]: *** [/tmp/akmodsbuild.12O2Etr3/BUILD/nvidia-kmod-387.34-x86_64/kmod_build_4.14.11-300.fc27.x86_64/Kbuild:119: /tmp/akmodsbuild.12O2Etr3/BUILD/nvidia-kmod-387.34-x86_64/_kmod_build_4.14.11-300.fc27.x86
    64/conftest/compile-tests/on_each_cpu.h] Terminated
    make[2]: *** [/tmp/akmodsbuild.12O2Etr3/BUILD/nvidia-kmod-387.34-x86_64/kmod_build_4.14.11-300.fc27.x86_64/Kbuild:119: /tmp/akmodsbuild.12O2Etr3/BUILD/nvidia-kmod-387.34-x86_64/_kmod_build_4.14.11-300.fc27.x86
    64/conftest/compile-tests/smp_call_function.h] Terminated
    make[2]: *** [/tmp/akmodsbuild.12O2Etr3/BUILD/nvidia-kmod-387.34-x86_64/kmod_build_4.14.11-300.fc27.x86_64/Kbuild:119: /tmp/akmodsbuild.12O2Etr3/BUILD/nvidia-kmod-387.34-x86_64/_kmod_build_4.14.11-300.fc27.x86
    64/conftest/compile-tests/acpi_evaluate_integer.h] Terminated
    make[1]: *** wait: No child processes. Stop.
    make[1]: *** Waiting for unfinished jobs….
    make[1]: *** wait: No child processes. Stop.
    make: *** [Makefile:84: modules] Error 2
    /var/tmp/rpm-tmp.PTVsUG: line 31: 26461 Terminated make -j4 IGNORE_XEN_PRESENCE=1 IGNORE_PREEMPT_RT_PRESENCE=1 IGNORE_CC_MISMATCH=1 SYSSRC=”${kernel_version##*___}” module
    error: Bad exit status from /var/tmp/rpm-tmp.PTVsUG (%build)

    Reply

      1. It seems to me that what you are trying to do is overcomplicated, I would just hard-reinstall the packages from scratch:

        # rpm -e --nodeps akmods akmod-nvidia kmod-nvidia-4.14.13-300.fc27.x86_64
# rm -fr /var/cache/akmods
# dnf install -y akmod-nvidia
# akmods
        Reply

        1. I am surprised you say “overcomplicated” I was only trying to troubleshoot the problem.
          There are errors (possibly only warnings?) if the mock group doesn’t exist, for example.

          I’m happy to try a clean reinstall. I’ll let you know how it goes. Thank you!

          Reply

        2. Well, I think I’ve identified my problem and I’ve also learned that I really don’t understand how this works!

          The PC in question runs some basic script I’d written to apply all security updates daily. Once a week a companion script does a full update and after success reboots the PC. I think it is doing so before whatever trigger runs which calls the build of a new NVIDIA kernel module.

          I’m sorry to ask such a basic question, but how does the akmod build get triggered?

          My update-reboot scripts run from systemd timers. Is there any easy way I can know when an akmod has finished being built (if one was required)?

          For the moment I’ve just added a 5 minute sleep. The new kernel usually builds and installs in under 3 minutes.

          Thank you again!

          Reply

  23. After last update of nvidia-settings, I can’t use nvidia-driver anymore…
    nvidia-settings show an error:
    “You do not appear to be using the nvidia x server”.
    I’ve tried to remove and reinstall nvidia driver from your repo… any suggestions?
    File: /etc/default/grub
    GRUB_CMDLINE_LINUX=”rd.driver.blacklist=nouveau rhgb quiet”

    Reply

    1. Please re-enable SELinux, you should not disable it. Try to uncomment this in /etc/gdm/custom.conf:

      [daemon]
# Uncoment the line below to force the login screen to use Xorg
#WaylandEnable=false
      Reply

    1. Thanks, will make a note. I was actually thinking of packaging TensorFlow directly, so many people are using it (I’m not).

      Reply

  26. I also met the freeze issue. The Nvidia driver seems to be working but after input username/password on the GDM login screen the system become completely hangs with CPU fans run at full speed. Neither can I move the mouse cursor nor switch to other TTYs.

    I finally solved this issue by disabling the nouveau driver fallback mechanism with sudo systemctl status nvidia-fallback. Not sure why this would cause trouble.

    I am using Fedora 27 + kernel 4.14.7-300.fc27.x86_64 + nvidia-driver-387.34-1.fc27 + X11 + Gnome 3.26.2 + EFI boot + Secure Boot disabled + Selinux disabled.

    Reply

    2. Please re-enable SELinux, you should not disable it. Try to uncomment this in /etc/gdm/custom.conf:

      [daemon]
# Uncoment the line below to force the login screen to use Xorg
#WaylandEnable=false
      Reply

      1. I went back to using the Negativo driver

        Moments after rebooting after disabling Wayland this way, my system froze just as well

        It may fix freezing from resizing application window’s from Wayland but it froze on using the web browser.

        What is that, the better of two evils?

        Reply

  28. Giving this a spin on F27 and have discovered an issue that I would appreciate any input on.

    Running your same repo on Centos 7 with driver version 384.98 the following command worked as expected when setting clock values. After the move to F27 and the latest 387.34, the command works ONLY for GPU0. Running the command against any other GPU in the system is silently ignored.

    sudo /usr/bin/xinit /usr/bin/nvidia-settings -a [gpu:0]/GPUMemoryTransferRateOffset[3]=500 — :0 -once

    Running the following command sees all 6 GPUs in my case.

    sudo /usr/bin/xinit /usr/bin/nvidia-settings -q gpus — :0 -once

    Reply

      1. After reverting the F27 system to 384.98, I see that the same problem exists there. The Centos7 system is running kernel v3 and F27 is on kernel v4. Not sure if there could be some differences in the newer kernel that could prevent accessing these other devices.

        Again, open to any suggestions.

        Reply

  29. On Fedora 27 “sudo dnf -y install cuda nvidia-driver-cuda cuda-devel” leads to

    CMake Error at /usr/share/cmake/Modules/FindCUDA.cmake:682 (message):
    Specify CUDA_TOOLKIT_ROOT_DIR
    Call Stack (most recent call first):
    libhwmon/CMakeLists.txt:13 (find_package)

    cmake probably expects /usr/local/cuda. How to fix this? Thank you!

    Reply

    1. Well, the command does not lead to the error. The commands install the packages, and then you’re trying to use some CMake based build to build something. What are you building? You need to make sure it finds CUDA installed in the system paths and the header files at /usr/include/cuda. Is it ethminer?

      Reply

        1. I tried almost everything I could think of but failed; perhaps s.o. more savy can have a go at it?

          CUDA_INC_PATH=/usr/include/cuda is set by default
          CUDA_TOOLKIT_ROOT_DIR=/usr is the best I can think of to add

          No luck!

          git clone –recursive https://github.com/ethereum-mining/ethminer.git
          cd ethminer
          mkdir build; cd build
          cmake3 .. -DETHASHCUDA=ON -DETHASHCL=OFF -DETHDBUS=OFF
          cmake3 –build .
          sudo make install

          CMake Error at /usr/share/cmake/Modules/FindCUDA.cmake:682 (message):
          Specify CUDA_TOOLKIT_ROOT_DIR
          Call Stack (most recent call first):
          libhwmon/CMakeLists.txt:13 (find_package)

          Reply

    1. Ouch, I did not know. Considering that the Tesla driver is at 384.81, you can probably rebuild the RHEL packages which are at 384.98. Or figure out if the list of supported chips is something you can just “bolt in” in some header or similar.

      Reply

        1. Thanks Slaanesh.

          The NVIDIA documentation link was sending me to an old version of the driver. When I updated the URL to the current version (http://us.download.nvidia.com/XFree86/Linux-x86/384.98/README/supportedchips.html) I found that the Tesla M60’s are supported!

          I suspect our problem is that we need to update the VMware drivers (VIBs) underneath the vGPUs presented to Linux virtual machines to a newer version. So I’m going to have a colleague do that and try your drivers again.

          Reply

          1. For the record, after updating ESXi to use NVIDIA 384.99 driver VIBs I could not get a 384.84 driver to work in a RHEL 7.4 VM with vGPU (Tesla M60) presented to it.

            However the 384.99 version (“NVIDIA Accelerated Graphics Driver for Linux-x86_64 384.99”) included in the Tesla driver download did work.

            The annoying thing is that the public downloads page only shows 384.81 drivers. GRR!

  32. I did this on freshly installed fedora 27 ( I have 1080 ti gpu)
    sudo dnf install nvidia-settings kernel-devel dkms-nvidia vulkan.i686 nvidia-driver-libs.i686
    and then reboot: The system gets stuck for ever.

    Reply

  33. Thanks for the great repo, I rely on it at home!

    Could you please confirm if these drivers support the NVIDIA Tesla server graphics cards. They’re used for VM desktop graphics acceleration.

    Thanks!

    Reply

  34. Do all these drivers and features work with a plain install of Fedora 27 as of Dec 4 2017? I’m interested in using 4 monitors and doing GPU programming.

    It seems that maybe wayland is NOT supported directly (meaning additional links and instructions must be followed). Since wayland is the default on F27 this is an important issue. I personally don’t want to follow other links which may or may not be up to date and work or not work and be easily uninstalled or not. I appreciate the work done on this driver, but I believe it is crucial to document what exactly the driver will work with. 🙂

    Reply

  35. Hey guys,

    On a fresh fedora 27 xfce, I tried installing this drivers. Laptop is an ASUS k556u laptop (nvidia 940mx and intel HD graphics 620)

    after reboot, i see the fedora logo loading and then black screen.

    I am able to drop to shell using ctr+alt+f2

    i dont see any errors are at Xorg logs. No errors at /var/log/messages either.

    on .xfce4-sessions log i see “received save timeout client will be disconnected now”

    startx will launch, as initx will as well, but they will all remain in a black screen.

    Any ideas ho how to fix?

    Reply

  36. Hi Simone,

    Ever since the upgrade:

    Upgraded nvidia-driver-2:387.22-1.fc27.x86_64 @fedora-multimedia
    Upgrade 2:387.34-1.fc27.x86_64 @fedora-multimedia

    the Nvidia driver no longer loads, but instead falls back to nouveau even when nouveau is blacklisted.

    I notice it looked like some scriptlet failed during that particular update but I am not sure if it is related.

    Scriptlet output:
    1
    2 UPGRADE: Automatically re-enabling default systemd units: fedora-import-state.service fedora-readonly.service
    3
    4 ln: target ‘/boot/dtb’ is not a directory
    5 cat: write error: Broken pipe

    Not sure if something got corrupted.

    Let me know what you think, and thanks again for the great repo.

    -Tom

    Reply

    1. Sorry to bug you, Simone!

      After the kernel update to 4.13.16-302.fc27.x86_64 this seemed to resolve itself. Appears unrelated to the driver and only manifested (for some reason) on 4.13.16-300.fc27.x86_64. Managed to repro the issue with that particular version on two machines no less!

      Thanks again,
      Tom

      Reply

  37. on fedora 27 i cant install it the gnome software way… nouveau still active after reboot. if i install it over commandline everything works fine.

    Reply

  38. For all those who have had problems with this driver and have tried the various suggestions in the thread without result. That was me. I spent hours trying to work it out.

    In the end, the solution was simple. Edit /etc/gdm/custom.conf and uncomment the “WaylandEnable=false”. Save, reboot and away you go.

    HTH.

    Reply

  39. Hi,

    First of all, thanks for your effort.
    Second, I’m the case when Secure Boot is desired to be preserved.
    After installing the nvidia package, I
    – locate the module (/lib/modules/…/extra/nvidia)
    – unxz nvidia.ko.xz , sign it, xz it back
    – modprobe it, reboot
    – Details not showing that nvidia is working now, though lspci says nvidia is it is a kernel driver for 3d controller

    problems:
    – does not actually work – CS:GO hangs
    – dnf upgrade –refresh apparently loses the signiture and nouvaue returns after it.

    Can you please correct me in this steps?

    Reply

  40. Hi, I just tried to install nvidia drivers on a clean F27 system, and after the reboot the system becomes unusable due to gnome-shell hogging the CPU (load goes above 9.0). Even the login screen shows this behavior. Reverting back to nouveau makes system usable again. Any idea what’s going on? I have a GTX 750 Ti. Thanks!

    Reply

    1. Uh… I don’t know exactly what happened, but I decided to reinstall nvidia driver to get some additional info, and to my surprise it is working just fine now, no CPU hogs or such. Sorry for the noise, nothing to see here, move on 😉

      Reply

  41. I can’t install driver because package is not at same version :
    nvidia-driver.x86_64 2:384.69-1.fc25 fedora-nvidia
    nvidia-settings.x86_64 2:387.22-1.fc25 fedora-nvidia
    dkms-nvidia.x86_64 2:387.22-1.fc25 fedora-nvidia
    kmod-nvidia.x86_64 2:387.22-1.fc25 fedora-nvidia
    akmod-nvidia.x86_64 2:387.22-1.fc25 fedora-nvidia

    Can you fix it ?

    Reply

  43. I added the repo and then installed the driver and graphics control panel from software center. But when i click on the control panel nothing happens. I mean it doesn’t open and how do i switch to nvidia drivers ?

    What could be the issue ?

    Reply

  44. ARGH! I installed your driver on F26 (GTX 650 Ti) and had ABYSMAL graphics performance. Slow, stuttering, graphics artifacts etc. I’ve been looking for a solution for months, to finally be able to play games on Linux.

    Everything was supposed to be fine: the Nvidia control panel was working, direct rendering was ‘on’, showed the proper graphic device, didn’t complain about the kernel module not being loaded.

    But all games ran awfully slow, especially compared to the fact that they ran nicely in Windows!

    So, I had the following installed:
    akmod-nvidia
    kmod-nvidia-…
    nvidia-driver-libs
    nvidia-settings.

    You know what solved my problem after searching for weeks and finding no solution?

    Installing the seemingly optional nvidia-modprobe package… now my system works great, games run wonderfully.

    What does it do and if it’s optional, why does it improve performance so much?

    Reply

  46. Hi! I’m using Fedora 27 beta and after installing this repo the nouveau driver is used instead of nvidia. I ran on Gnome, Gnome Classic and Gnome Xorg, but the same driver still loads. Here there are commands I run:

    lspci | grep VGA
    01:00.0 VGA compatible controller: NVIDIA Corporation GP106M [GeForce GTX 1060 Mobile 6GB] (rev a1)

    uname -r
    4.13.9-300.fc27.x86_64

    dnf list installed nvidia
    Installed packets
    dkms-nvidia.x86_64 2:387.12-2.fc27 @fedora-nvidia
    nvidia-driver.x86_64 2:387.12-1.fc27 @fedora-nvidia
    nvidia-driver-libs.i686 2:387.12-1.fc27 @fedora-nvidia
    nvidia-driver-libs.x86_64 2:387.12-1.fc27 @fedora-nvidia
    nvidia-libXNVCtrl.x86_64 2:387.12-1.fc27 @fedora-nvidia
    nvidia-settings.x86_64 2:387.12-1.fc27 @fedora-nvidia

    lshw -numeric -C display
    *-display
    description: VGA compatible controller
    product: GP106M [GeForce GTX 1060 Mobile 6GB] [10DE:1C60]
    vendor: NVIDIA Corporation [10DE]
    physical id: 0
    bus info: pci@0000:01:00.0
    version: a1
    width: 64 bits
    clock: 33MHz
    capabilities: pm msi pciexpress vga_controller bus_master cap_list rom
    configuration: driver=nouveau latency=0
    resources: irq:128 memory:db000000-dbffffff memory:90000000-9fffffff memory:a0000000-a1ffffff ioport:e000(size=128) memory:c0000-dffff

    I heard about EAGLStreams repo from Nvidia that allows to run their driver on Wayland. Should it help? How safe is it?

    Reply

      1. Sorry to reply late. Yes, I’m using it. Few days before there was update which caused that driver if logged to xorg mode was loaded. I installed the mutter exactly from the provided link but nouveau driver loads.

        Reply

      2. Also happening with me. That link does nothing with 3.13.12-300 f27 kernel.

        I’ve tried all I could but only the last kernel (3.13.12-200) or earlier that I had in use with Fedora 26 works.

        Secure boot is disabled. uninstall nvidia package, reinstall, reboot, eglstream, whatever.

        Tested also with disablement of Wayland:
        loginctl show-session 2 -p Type
        Type=x11

        lspci -nnk | grep -iA2 vga
        Kernel driver in use: nouveau

        Reply

          1. OK! So managed to get the older kernels working with the nvidia driver again (though as I type this 4.13.12-200 f26 is working a bit oddly. Figure that out later.) 4.13.12-300 still does not work and still shows nouveau.

            lspci -nnk | grep -iA2 vga
            Kernel driver in use: nvidia

            loginctl show-session 1 -p Type
            Type=wayland

            It went something like this:

            removed linked mutter repo and undid all that from link

            reinstalled mutter

            remove then installed negativo17.org driver

            su -c ‘dnf -y –allowerasing install xorg-x11-drv-nvidia-libs.i686’

            reboot into older kernel and nvidia driver was back

          2. After more testing, have been unable to get nvidia drivers working at all now with wayland or xorg. Even removed gdm, mutter, wayland and all nvidia packages regardless of how I do it. Even with the linked mutter. Nothing at all.

            Its interesting to note that nvidia-settings has error:
            ERROR: Unable to find display on any available system

            And adding generated xconfig causes boot to get stuck pre-login

            No dnf command found on this page seems to fix it as well

            So I’m now out of ideas. It just seems to be completely broken.

          3. For reference, my solution was to install Nvidia proprietary driver without negativo17. Nouveau has a freeze bug for me so couldn’t exactly wait around for this to be fixed.

  48. Suggestion:

    Is it how doable to do GPU Switching for Optimus laptops? Ubuntu has made Dirty hack which allows switching between Intel/Nvidia. I suppose that “offloading” would be THE way to do it like in Windows, but far as I know that is not happening in Linux.

    Would be super helpful on Laptop to decide between Performance vs PowerSave. Batter time with only intel can be like 7 hours, but on nividia its max 2 hours, but commonly just 1 hour. (just my Dell Laptop measures)

    Reply

  49. I have two Fedora 26 laptops. Both has Intel with Optimus. (Haswell + Kaby Lake and Quadro 2100K + GeForce 1050 Ti)

    My experience with fresh installs is:
    –> Wayland is working with Intel
    –> Xorg is working with Nvidia

    This is kinda nice… I can EASILY switch to Powersave Intel / Powerful Nvidia by just relogging.

    I don’t know if this is the intended way it should work. I understood that Nvidia should now work with Wayland? Or is that coming from Fedora 27?

    Reply

      1. Thank you from clarification. I think I will wait still before I break my system. 🙂 Also few things does not work in Wayland, example Shutter which I use daily basis.

        Reply

  50. I’m using fresh installed Fedora 26 and I get the following msg when I’m trying :
    dnf remove *nvidia*
    Error:
    Problem: The operation would result in removing the following protected packages: kernel-core
    how can I fix that?

    Reply

      1. That was the full output of the command but I can give more information about the kernel I’m using and graphics card:

        dnf list installed nvidiaInstalled Packages
        kernel-core.x86_64 4.11.8-300.fc26 @anaconda
        kernel-core.x86_64 4.13.5-200.fc26 @updates
        kernel-modules.x86_64 4.11.8-300.fc26 @anaconda
        kernel-modules.x86_64 4.13.5-200.fc26 @updates
        linux-firmware.noarch 20170828-77.gitb78acc9.fc26 @updates

        uname -r
        4.11.8-300.fc26.x86_64

        lspci |grep -E “VGA|3D”
        05:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 770] (rev a1)

        any idea?

        Reply

      1. I tried to use negativo drivers, but after reboot (GTX 1080) it gave me a black screen, then I tried to reinstall Fedora, but it failed (broke EFI partition) and I had to reinstall Windows in result.

        Reply

Leave a Reply