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
YesYesYes
Basic nvidia driver:

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

nvidia-driver-cuda
nvidia-driver-cuda-libs
nvidia-driver-NVML
nvidia-persistenced
YesYesYes
OpenGL Framebuffer Capture:

nvidia-driver-NvFBCOpenGL
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:

nvidia-libXNVCtrl
nvidia-driver-libs
nvidia-driver-cuda-libs
nvidia-driver-NVML
YesYesYes
Development

nvidia-driver-devel
nvenc
nvenc-samples
YesYesYes
GLVND librariesYesYesYes
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,257 thoughts to “Nvidia driver, CUDA tools and libraries”

  1. Hi Everyone,

    I noticed a more recent problem with a consistent stuttering across my entire system using the latest Nvidia drivers (384.90) and the latest kernel on Fedora 26 (4.13.4-200). This problem didn’t exhibit itself a couple of weeks ago, although I’m not sure what package updates actually caused it.

    The stuttering can be seen scrolling on a webpage, watching a youtube video, or even just typing. It occurs about every 5-10 seconds.

    I tried to reinstall the older version of the nvidia drivers (384.69) by downgrading using dnf, but I ran into some problems. I wasn’t able to get the kernel module to rebuild, so the next time I logged into Xorg I believe I was actually using Nouveau.

    I noticed in the Nvidia changelog for 384.90 Nvidia specifically mentions a fix for stuttering, so perhaps this is related?

    I’m using a GTX 1060 with a Ryzen 1700, so my system specs are fairly good.

    Thanks!

  2. On Fedora 27 with GTX 1050 Ti GDM and Wayland sessions are causing 100% CPU usage and animations are stuttering (LLVMpipe I guess).
    More details:

    $ ls -al /dev/nvidia*
    crw-rw-rw-. 1 root root 195, 0 10-07 12:38 /dev/nvidia0
    crw-rw-rw-. 1 root root 195, 255 10-07 12:38 /dev/nvidiactl
    crw-rw-rw-. 1 root root 195, 254 10-07 12:38 /dev/nvidia-modeset
    crw-rw-rw-. 1 root root 241, 0 10-07 12:38 /dev/nvidia-uvm
    crw-rw-rw-. 1 root root 241, 1 10-07 12:38 /dev/nvidia-uvm-tools
    $ cat /proc/devices | grep nvidia
    195 nvidia-frontend
    241 nvidia-uvm
    242 nvidia-nvlink
    $ dnf list installed | grep nvidia
    akmod-nvidia.x86_64 2:387.12-1.fc27 @fedora-nvidia
    kmod-nvidia-4.13.4-300.fc27.x86_64.x86_64
    kmod-nvidia-4.13.5-300.fc27.x86_64.x86_64
    nvidia-driver.x86_64 2:387.12-1.fc27 @fedora-nvidia
    nvidia-driver-NVML.x86_64 2:387.12-1.fc27 @fedora-nvidia
    nvidia-driver-NvFBCOpenGL.x86_64 2:387.12-1.fc27 @fedora-nvidia
    nvidia-driver-cuda.x86_64 2:387.12-1.fc27 @fedora-nvidia
    nvidia-driver-cuda-libs.x86_64 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-modprobe.x86_64 2:387.12-1.fc27 @fedora-nvidia
    nvidia-persistenced.x86_64 2:387.12-1.fc27 @fedora-nvidia
    nvidia-settings.x86_64 2:387.12-1.fc27 @fedora-nvidia
    $ uname -r
    4.13.5-300.fc27.x86_64

    dmesg https://pastebin.com/LCpn6WtV
    Xorg.0.log https://pastebin.com/PNnVpBm2

  3. Hi !
    By the past your driver was perfect with our studio setup, we do 3d rendering with cuda cards.

    I can’t tell you when (a change this year ?) but now your nvidia-drivers-cuda doesn’t work anymore for cuda computing, the nvidia drivers work but cuda don’t… I’ve installed multiple times “yum -y install nvidia-driver-cuda nvidia-settings”

    To solve that I actually installed on our computers the packages from elrepo witch solves the problem but I have a question, can I leave elrepo AND your multimedia repo on ? should I blacklist kmod-nvidia ? your ffmpeg and mpv build are so usefull 😉

    1. I don’t think you can use them at the same time but I might be wrong. What is the issue exactly?

      Can you see if with the drivers here you have all devices correctly created?

      $ ls -al /dev/nvidia*
      crw-rw-rw-. 1 root root 195,   0 Oct  2 02:51 /dev/nvidia0
      crw-rw-rw-. 1 root root 195, 255 Oct  2 02:51 /dev/nvidiactl
      crw-rw-rw-. 1 root root 195, 254 Oct  2 02:51 /dev/nvidia-modeset
      crw-rw-rw-. 1 root root 239,   0 Oct  2 02:51 /dev/nvidia-uvm
      crw-rw-rw-. 1 root root 239,   1 Oct  2 02:51 /dev/nvidia-uvm-tools
      $ cat /proc/devices | grep nvidia
      195 nvidia-frontend
      239 nvidia-uvm

      If not, can you try to install nvidia-modprobe, reboot, and check again?
      Thanks,
      –Simone

      1. Hi, sorry for the late reply.
        About the driver not working, I reported you back cuda wasn’t working but in fact that was the whole nvidia driver who wasn’t working, nvidia-settings in gnome reports no nvidia driversI think there is a fall back to nouveau…

        On Centos latest (7.4) I don’t get why the Elrepo driver works and your don’t…

        I tried on a blank disk a F26 Install and I can repro 100% what’s hapenning on CentOs, nvidia-modrobe don’t help. The same goes for F27

        Do you know an equivalent of Elrepo nvidia drivers for Fedora ?

  4. Hello, trying to install nvidia drivers in a VM with VT-d PCI passthrough of the nvidia card. On the host nouveau module is disabled and the VM sees the card. Also the nvidia_drm module is successfully loaded.

    When I run $ sudo nvidia-smi I’m getting Unable to determine the device handle for GPU 0000:00:09.0: Unknown Error. And in console I’m getting

    NVRM: RmInitAdapter failed! (0x23:0x56:469)
    NVRM: rm_init_adapter failed for device bearing minor number 0
    NVRM: RmInitAdapter failed! (0x23:0x56:469)
    NVRM: rm_init_adapter failed for device bearing minor number 0

    This is with akmod-nvidia-384.90-1.fc26.x86_64 but same also happens when I install directly with nvidia installer. Any ideas whether this can be fixed?

  5. With Fedora 27 nvidia driver 384.69-1.fc27 and kernel 4.13.2-300.fc27.x86_64 i got with akmod an error and its unable to compile the driver 2017/09/20 00:40:28 akmodsbuild: MODPOST 4 modules
    2017/09/20 00:40:28 akmodsbuild: FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol ‘lockdep_init_map’
    2017/09/20 00:40:28 akmodsbuild: make[2]: *** [scripts/Makefile.modpost:91: __modpost] Error 1
    2017/09/20 00:40:28 akmodsbuild: make[1]: *** [Makefile:1520: modules] Error 2
    2017/09/20 00:40:28 akmodsbuild: make[1]: Leaving directory ‘/usr/src/kernels/4.13.2-300.fc27.x86_64’

  6. Hi Friends:

    Unfortunately I’m booted from Windows on my multiboot laptop, so I don’t have access to all of the information that I would normally post.

    After a ‘dnf -y update’ updated my nvidia collection of RPM to version — 384.69-1.fc25.x86_64 — I get the below segmentation fault. Everything was working fine for many months before that update. I’m running the latest Fedora 25 kernel, which is: 4.12.11-200.fc25.x86_64. Note that booting to a previous kernel doesn’t fix the issue.

    I wish I could do a rpm -qa | egrep ‘nvidia|xorg‘ to add more information, but I am not booted into Linux to do that. The problem could be with the nvidia driver and/or with the xorg RPMs.

    See below. Any ideas? Thank you in advance!

    X.Org X Server 1.19.3
    Release Date: 2017-03-15
    X Protocol Version 11, Revision 0
    Build Operating System: 4.9.3-200.fc25.x86_64
    Current Operating System: Linux y700 4.12.11-200.fc25.x86_64 #1 SMP Fri Sep 8 11:44:51 UTC 2017 x86_64
    Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.12.11-200.fc25.x86_64 root=/dev/sdb1 ro gfxpayload=vga=normal quiet rd.driver.blacklist=nouveau net.ifnames=0 biosdevname=0 LANG=en_US.UTF-8
    Build Date: 15 March 2017 06:37:12PM
    Build ID: xorg-x11-server 1.19.3-1.fc25
    Current version of pixman: 0.34.0
    Before reporting problems, check http://wiki.x.org
    to make sure that you have the latest version.
    Markers: (--) probed, (**) from config file, (==) default setting,
    (++) from command line, (!!) notice, (II) informational,
    (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
    (==) Log file: "/var/log/Xorg.0.log", Time: Wed Sep 13 23:08:47 2017
    (==) Using config file: "/etc/X11/xorg.conf"
    (==) Using config directory: "/etc/X11/xorg.conf.d"
    (==) Using system config directory "/usr/share/X11/xorg.conf.d"
    (EE)
    (EE) Backtrace:
    (EE) 0: /usr/libexec/Xorg (OsLookupColor+0x139) [0x59ea19]
    (EE) 1: /lib64/libpthread.so.0 (funlockfile+0x50) [0x7fb88acbf61f]
    (EE) 2: /usr/lib64/xorg/modules/libglamoregl.so (glamor_init+0x16b) [0x7fb88442951b]
    (EE) 3: /usr/lib64/xorg/modules/drivers/modesetting_drv.so (_init+0x39c1) [0x7fb8885bec91]
    (EE) 4: /usr/libexec/Xorg (AddGPUScreen+0xf0) [0x437480]
    (EE) 5: /usr/libexec/Xorg (InitOutput+0x287) [0x47cf87]
    (EE) 6: /usr/libexec/Xorg (InitFonts+0x216) [0x43aea6]
    (EE) 7: /lib64/libc.so.6 (__libc_start_main+0xf1) [0x7fb88a908431]
    (EE) 8: /usr/libexec/Xorg (_start+0x2a) [0x424d5a]
    (EE)
    (EE) Segmentation fault at address 0x43ba50
    (EE)
    Fatal server error:
    (EE) Caught signal 11 (Segmentation fault). Server aborting
    (EE)
    (EE)
    Please consult the Fedora Project support
    at http://wiki.x.org
    for help.
    (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
    (EE)
    (EE) Server terminated with error (1). Closing log file.
    xinit: giving up
    xinit: unable to connect to X server: Connection refused
    xinit: unexpected signal 2

  7. Firstly, thank you for this driver packaging. Brilliant.

    I’m using releases from NVIDIA’s Vulkan dev branch, and would prefer packages and not a .run file, for whose contents i am not convinced i will ever be able to really remove, or reliably update against.

    I have little RPM packaging chops, but if there were “shoulders to stand on”, like a packaging framework that knows what to do with a .run file, i might be able to dedicate enough time and succeed. Can any of the work going into these repos be shared?

    Cheers

  8. Based on this driver. I have successfully build and install nvidia-docker! https://github.com/NVIDIA/nvidia-docker/wiki/Installation, with make rpm and rpm -i dist/nvidia-docker-1.0.1-1.x86_64.rpm

    Even more importantly, this driver (version 384.69) helps to get NVIDIA GTX 1080 Ti GPU runs on my CentOS 7.3 server. I spent two nights trying to get it working. driver version 375.26 (current official download) does not work for 1080 Ti, it works for GTX 970.

    Thanks a lot!!!

  9. Hello and, as always, thanks for the great work.
    Yesterday night I upgraded my Fedora 26 to the latest version of your drivers and Gnome is now running on Wayland! So the support has finally landed? Do we have to configure something?

    Thanks,
    Bauno

      1. Hmmm…

        loginctl
        SESSION UID USER SEAT TTY
        c1 42 gdm seat0 /dev/tty1
        2 1000 bauno seat0 /dev/tty2

        loginctl show-session 2 -p Type
        Type=wayland

        rpm -q mutter
        mutter-3.24.4-1.fc26.x86_64

        Weird?

        B.

        1. Ok, I’m a moro 🙂
          For some reason, the driver update re-enabled nouveau removeing the blacklist line in grub.cfg…
          Now it’s back to normal. Sorry for the confusion.

          B.

  10. OpenCL not working

    Hello, I installed this nvidia drivers on fresh EL7.4, on optimus laptop. Everythings works fine, except for OpenCL. I also installed packages opencl-filesystem and ocl-icd but it doesnt seem to help. I cant get it working in any application.

    for example here is the output from darktable:

    darktable -d opencl

    [opencl_init] opencl related configuration options:
    [opencl_init]
    [opencl_init] opencl: 1
    [opencl_init] opencl_library: ”
    [opencl_init] opencl_memory_requirement: 768
    [opencl_init] opencl_memory_headroom: 300
    [opencl_init] opencl_device_priority: ‘/!0,//
    [opencl_init] opencl_size_roundup: 16
    [opencl_init] opencl_async_pixelpipe: 0
    [opencl_init] opencl_synch_cache: 0
    [opencl_init] opencl_number_event_handles: 25
    [opencl_init] opencl_micro_nap: 1000
    [opencl_init] opencl_use_pinned_memory: 0
    [opencl_init] opencl_use_cpu_devices: 0
    [opencl_init] opencl_avoid_atomics: 0
    [opencl_init] opencl_omit_whitebalance: 0
    [opencl_init]
    [opencl_init] could not find opencl runtime library ‘libOpenCL’
    [opencl_init] could not find opencl runtime library ‘libOpenCL.so’
    [opencl_init] found opencl runtime library ‘libOpenCL.so.1’
    [opencl_init] opencl library ‘libOpenCL.so.1’ found on your system and loaded
    [opencl_init] could not get platforms: -1001
    [opencl_init] FINALLY: opencl is NOT AVAILABLE on this system.
    [opencl_init] initial status of opencl enabled flag is OFF.

    If you need any more info or testing please let me know 🙂

    Have a nice day

  11. Any idea why I’m getting

    h264_nvenc @ 0x251644dca0] Cannot init CUDA
    [h264_nvenc @ 0x251644dca0] cuCtxPushCurrent failed

    I’ve installed nvenc, cuda, nvidia drivers and nothing…

    1. nvenc are just headers, required if you need to compile some software that uses NVENC. Make sure to have nvidia-drivers-cuda installed.

      1. Yes, it is installed:

        ↪ rpm -qa | grep nvidia
        nvidia-driver-devel-384.59-4.fc26.x86_64
        nvidia-driver-NvFBCOpenGL-384.59-4.fc26.x86_64
        nvidia-driver-NVML-384.59-4.fc26.x86_64
        nvidia-persistenced-384.59-1.fc26.x86_64
        nvidia-driver-384.59-4.fc26.x86_64
        nvidia-libXNVCtrl-384.59-1.fc26.x86_64
        nvidia-driver-cuda-libs-384.59-4.fc26.x86_64
        dkms-nvidia-384.59-1.fc26.x86_64
        nvidia-driver-libs-384.59-4.fc26.x86_64
        nvidia-settings-384.59-1.fc26.x86_64
        nvidia-driver-cuda-384.59-4.fc26.x86_64

        ↪ lsmod | grep nv
        nvidia_drm 45056 3
        nvidia_modeset 843776 9 nvidia_drm
        nvidia_uvm 675840 0
        nvidia 13037568 411 nvidia_modeset,nvidia_uvm
        drm_kms_helper 155648 2 i915,nvidia_drm
        drm 348160 6 i915,nvidia_drm,drm_kms_helper

        1. I face the same issue. I do not use nvenc that often so cannot say what could possibly break CUDA. It used to work in F25 when I already was using negativo17 repository. Also at least a fortnight ago after I upgraded F25 to F26 and installed all the required packages, like nvidia-driver-cuda, which somehow got removed during upgrade, CUDA was working fine (I just quickly verified it using cuda-z). However after installing new kernel 4.12.8 I do see in logs a slight different order of nvidia related entires, some HDA NVidia HDMIs are before the usual loading of nvidia modules. Would be really bizarre that some soundcard loading stuff forbids proper CUDA initialization. Strangely enough when I booted older kernel 4.12.5 the order of logs is now the same as in 4.12.8.

        2. I checked it a bit further and it seems it is some permission issue. Runnig nvenc from ffmpeg or cuda-z as root is working ok. I am not sure what should be the correct ownership of nvidia devices but I changed them from root to video group and it is now working for my user as well. Seems that the udev rules are somewhat incomplete.

          1. I spoke too soon. This is not the ownership issue. CUDA starts working when it is first used by root, then it works for all users despite the root:root ownership of nvidia devices. Maybe some initialization/locking issue then?

  12. F25 has a problem (Dell T7600) with the latest kernel and nvidia driver.

    1) 4.11.12-200.fc25.x86_64 always loads nouveau
    4.11.11-200.fc25.x86_64 works fine

    2) nvidia-driver-2:384.59-3.fc25.x86_64

    Looks like a gnome shell library related issue?

    [ 520.923115] gnome-shell[26091]: segfault at 48 ip 00007fe4043918a0 sp 00007ffda0ca2198 error 4 in libmutter-cogl.so[7fe404358000+a7000]
    [ 524.449936] gnome-shell[26208]: segfault at 48 ip 00007fac73e7f8a0 sp 00007fff4fbb3bf8 error 4 in libmutter-cogl.so[7fac73e46000+a7000]
    [ 524.497533] gnome-session-f[26343]: segfault at 0 ip 00007f3f5caff869 sp 00007ffc602e7d80 error 4 in libgtk-3.so.0.2200.17[7f3f5c820000+6eb000]
    [ 525.281125] nvidia-modeset: Freed GPU:0 (GPU-41da5200-fbd1-51a7-03ad-1b7bf1a9ba8b) @ PCI:0000:05:00.0
    [ 525.833486] nvidia-modeset: Allocated GPU:0 (GPU-41da5200-fbd1-51a7-03ad-1b7bf1a9ba8b) @ PCI:0000:05:00.0

    1. Are you attempting to use Wayland? Mutter in Fedora 26 does not support EGLstream yet, please use the X session.

  13. Fresh F26 install… X server does not start. (This used to work on
    F25, but some driver/kernel update broke it in the last 2 months;
    after lots of troubleshooting I decided to do a fresh install, but
    alas the problem persists.) Any pointers would be GREATLY
    appreciated.

    [The comment system seems to be eating my posts… Trying again in
    smaller chunks, I apologize in advance if duplicates appear…]

    Info follows:

    uname -r
    4.12.5-300.fc26.x86_64

    lspci -k | …
    02:00.0 3D controller: NVIDIA Corporation GK110GL [Tesla K20c] (rev a1)
    Subsystem: NVIDIA Corporation Device 0982
    Kernel driver in use: nvidia
    Kernel modules: nouveau, nvidia_drm, nvidia
    04:00.0 VGA compatible controller: NVIDIA Corporation GM204 [GeForce GTX 970] (rev a1)
    Subsystem: Micro-Star International Co., Ltd. [MSI] Device 3171
    Kernel driver in use: nvidia
    Kernel modules: nouveau, nvidia_drm, nvidia
    04:00.1 Audio device: NVIDIA Corporation GM204 High Definition Audio Controller (rev a1)
    Subsystem: Micro-Star International Co., Ltd. [MSI] Device 3171
    Kernel driver in use: snd_hda_intel
    Kernel modules: snd_hda_intel

    rpm -qa ‘nvidia
    nvidia-driver-libs-384.59-4.fc26.x86_64
    nvidia-libXNVCtrl-384.59-1.fc26.x86_64
    kmod-nvidia-4.12.5-300.fc26.x86_64-384.59-1.fc26.x86_64
    nvidia-settings-384.59-1.fc26.x86_64
    nvidia-driver-384.59-4.fc26.x86_64
    akmod-nvidia-384.59-1.fc26.x86_64

    1. [smaller post == success]

      startx 2> err2.txt
      cat err2.txt
      xauth: file /root/.serverauth.1664 does not exist
      xauth: file /root/.Xauthority does not exist
      xauth: file /root/.Xauthority does not exist

      X.Org X Server 1.19.3
      Release Date: 2017-03-15
      X Protocol Version 11, Revision 0
      Build Operating System: 4.10.6-200.fc25.x86_64
      Current Operating System: Linux xx.xxxx.xxx 4.12.5-300.fc26.x86_64 #1 SMP Mon Aug 7 15:27:25 UTC 2017 x86_64
      Kernel command line: BOOT_IMAGE=/vmlinuz-4.12.5-300.fc26.x86_64 root=/dev/mapper/fedora_xi–pb-root ro rd.lvm.lv=fedora_xi-pb/root rd.lvm.lv=fedora/swap quiet LANG=en_US.UTF-8 rd.driver.blacklist=nouveau 3
      Build Date: 23 April 2017 11:51:31PM
      Build ID: xorg-x11-server 1.19.3-4.fc26
      Current version of pixman: 0.34.0
      Before reporting problems, check http://wiki.x.org
      to make sure that you have the latest version.
      Markers: (–) probed, (**) from config file, (==) default setting,
      (++) from command line, (!!) notice, (II) informational,
      (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
      (==) Log file: “/var/log/Xorg.0.log”, Time: Wed Aug 16 13:25:53 2017
      (==) Using config directory: “/etc/X11/xorg.conf.d”
      (==) Using system config directory “/usr/share/X11/xorg.conf.d”
      (EE)
      Fatal server error:
      (EE) no screens found(EE)
      (EE)
      Please consult the Fedora Project support
      at http://wiki.x.org
      for help.
      (EE) Please also check the log file at “/var/log/Xorg.0.log” for additional information.
      (EE)
      (EE) Server terminated with error (1). Closing log file.
      xinit: giving up
      xinit: unable to connect to X server: Connection refused
      xinit: server error

      1. /var/log/Xorg.0.log [edited for brevity]
        X.Org X Server 1.19.3
        [ 416.265] Kernel command line: BOOT_IMAGE=/vmlinuz-4.12.5-300.fc26.x86_64 root=/dev/mapper/fedora_xi–pb-root ro rd.lvm.lv=fedora_xi-pb/root rd.lvm.lv=fedora/swap quiet LANG=en_US.UTF-8 rd.driver.blacklist=nouveau 3
        [ 416.326] (II) xfree86: Adding drm device (/dev/dri/card0)
        [ 416.327] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 11 paused 0
        [ 416.327] (II) xfree86: Adding drm device (/dev/dri/card1)
        [ 416.328] (II) systemd-logind: got fd for /dev/dri/card1 226:1 fd 12 paused 0
        [ 416.330] () OutputClass “nvidia” setting /dev/dri/card0 as PrimaryGPU
        [ 416.332] (–) PCI:*(0:2:0:0) 10de:1022:10de:0982 rev 161, Mem @ 0xfa000000/16777216, 0xe0000000/268435456, 0xf0000000/33554432, BIOS @ 0x????????/524288
        [ 416.332] (–) PCI: (0:4:0:0) 10de:13c2:1462:3171 rev 161, Mem @ 0xf8000000/16777216, 0xc0000000/268435456, 0xd0000000/33554432, I/O @ 0x0000e000/128, BIOS @ 0x????????/131072
        [ 416.658] (II) Applying OutputClass “nvidia” to /dev/dri/card0
        [ 416.769] (II) Applying OutputClass “nvidia” to /dev/dri/card1
        [ 416.989] (II) LoadModule: “nvidia”
        [ 417.114] (II) NVIDIA dlloader X Driver 384.59 Wed Jul 19 23:14:49 PDT 2017
        [ 417.127] (II) NVIDIA(0): Creating default Display subsection in Screen section
        [ 417.128] (II) Applying OutputClass “nvidia” options to /dev/dri/card0
        [ 417.128] (
        ) NVIDIA(0): Option “SLI” “Auto”
        [ 417.128] () NVIDIA(0): Option “BaseMosaic” “on”
        [ 417.128] (
        ) NVIDIA(0): Option “AllowEmptyInitialConfiguration”
        [ 417.129] () NVIDIA(0): NVIDIA SLI auto-select rendering option.
        [ 417.129] (
        ) NVIDIA(0): Enabling 2D acceleration
        [ 419.089] (EE) NVIDIA(GPU-0): Failed to find a valid Base Mosaic configuration.
        [ 419.089] (EE) NVIDIA(GPU-0): Invalid Base Mosaic configuration 1 of 1:
        [ 419.089] (EE) NVIDIA(GPU-0): GPUs:
        [ 419.089] (EE) NVIDIA(GPU-0): 1) NVIDIA GPU at PCI:2:0:0
        [ 419.089] (EE) NVIDIA(GPU-0): 2) NVIDIA GPU at PCI:4:0:0
        [ 419.089] (EE) NVIDIA(GPU-0): Errors:
        [ 419.089] (EE) NVIDIA(GPU-0): – The video link was not detected
        [ 419.089] (EE) NVIDIA(GPU-0): – Unsupported GPU
        [ 419.089] (EE) NVIDIA(GPU-0): – Chipset not approved for SLI
        [ 419.089] (EE) NVIDIA(GPU-0): – GPU PCI IDs do not match
        [ 419.089] (WW) NVIDIA(GPU-0): Failed to find a valid Base Mosaic configuration for the
        [ 419.089] (WW) NVIDIA(GPU-0): NVIDIA graphics device PCI:2:0:0. Please see Chapter 28:
        [ 419.089] (WW) NVIDIA(GPU-0): Configuring SLI and Multi-GPU FrameRendering in the README
        [ 419.089] (WW) NVIDIA(GPU-0): for troubleshooting suggestions.
        [ 419.193] (EE) NVIDIA(GPU-0): Only one GPU will be used for this X screen.
        [ 420.374] (WW) NVIDIA(GPU-0): No 3D engine available.
        [ 420.374] (EE) NVIDIA(GPU-0): Failed to select a 2D engine.
        [ 420.474] (EE) NVIDIA(0): Failing initialization of X screen 0
        [ 420.474] (II) UnloadModule: “nvidia”
        [ 420.474] (II) UnloadSubModule: “wfb”
        [ 420.474] (II) UnloadSubModule: “fb”
        [ 420.474] (EE) Screen(s) found, but none have a usable configuration.
        Fatal server error:
        [ 420.474] (EE) no screens found(EE)
        [ 420.475] (EE) Server terminated with error (1). Closing log file.

        1. The issue is that it’s trying to use the Tesla K20C as the primary display adapter. You need to force it into starting on the other one by writing some X.org configuration.

          1. You could also edit /etc/X11/xorg.conf.d/10-nvidia.conf and see if commenting all the “Option” works.
            To create your custom X.org config file, just copy that to /etc/X11/xorg.conf and edit it there.

          2. Thanks for the reply… I’m still having problems; what option/setting do I need in order to change the selection of the Tesla card:

            (**) OutputClass “nvidia” setting /dev/dri/card0 as PrimaryGPU

            to the GeForce GTX 970 card

            (**) OutputClass “nvidia” setting /dev/dri/card1 as PrimaryGPU

            I tried adding

            Section “Device”
            Identifier “Device1”
            Driver “nvidia”
            VendorName “NVIDIA Corporation”
            BusID “PCI:4:0:0”
            Screen 0
            EndSection

            Section “Screen”
            Identifier “Screen0”
            Device “Device1”
            GPUDevice “Device1”
            EndSection

            Section “ServerLayout”
            Identifier “Layout0”
            Screen 0 “Screen0”
            EndSection

            but no dice. 🙁

  14. Upgrading to 2:384.59-3.fc26 from 2:384.59-2.fc26 never reaches the GDM login screen and keeps resetting/cycling the monitors. GeForce GTX 550 Ti/PCIe/SSE2 Fedora 26. It was necessary to downgrade.

  15. I figured out what I did to keep the nvidia driver from your repo from working on fedora 26 and how to get it working again on my system, but I don’t understand why. I broke it by changing the default plymouth theme from charge to details so that I could see the detailed text boot log and then I rebuilt initrd with:

    plymouth-set-default-theme details –rebuild-initrd

    And I figured out that I could fix it with:

    plymouth-set-default-theme solar –rebuild-initrd

    Although the solar animations don’t animate quite correctly and the flares jump around so I will probably set it back to the default “charge” theme.

    What dependencies did I break for the nvidia driver by changing the pymouth theme? Perhaps this dependency should be be mentioned in your excellent installation instructions above?

    Also, what is the recommended method to switch between intel and nvidia drivers on fedora for those of us who have laptops which hide the BIOS settings to enable and disable the nvidia graphics hardware? Is an additional grub entry the best way to do it?

    Thank you for your packaging work on this driver!

    1. Looking for some more permanent solution to select nvidia/nouveau/intel on boot, that would respect kernel updates, I created the following solution. It will add nvidia/nouveau boot option, where intel is default. Not very grub polite but it works well.

      In all modprobe files disable ‘blacklist’ options for nvidia/nouveau, it will depend on command line options.

      2. In nvidia-fallback.service add ‘-b’ as in this line, so nouveau is not loaded if only intel is required:

      ExecStart=-/sbin/modprobe -b nouveau

      3. In /etc/default/grub:

      GRUB_CMDLINE_LINUX_OPTION[0]=”nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off”
      GRUB_CMDLINE_LINUX_OPTION[1]=”rd.driver.blacklist=nvidia,nvidia_drm,nvidia_modeset,nvidia_kms_helper modprobe.blacklist=nvidia,nvidia_drm,nvidia_modeset,nvidia_kms_helper”
      GRUB_CMDLINE_LINUX_DEFAULT=”${GRUB_CMDLINE_LINUX_OPTION[0]} ${GRUB_CMDLINE_LINUX_OPTION[1]}”
      declare -A GRUB_CMDLINE_LINUX_ALTERNATIVE
      GRUB_CMDLINE_LINUX_ALTERNATIVE[nvidia]=”${GRUB_CMDLINE_LINUX_OPTION[0]}”
      GRUB_CMDLINE_LINUX_ALTERNATIVE[nouveau]=”${GRUB_CMDLINE_LINUX_OPTION[1]}”

      export GRUB_CMDLINE_LINUX_ALTERNATIVES=$(declare -p GRUB_CMDLINE_LINUX_ALTERNATIVE)

      4. Add this executable file as /etc/grub.d/11_linux_alternative:

      #! /bin/sh
      set -e

      GRUB_DISABLE_SUBMENU=”n”

      eval $GRUB_CMDLINE_LINUX_ALTERNATIVES
      for alternative in ${!GRUB_CMDLINE_LINUX_ALTERNATIVE[]}; do
      GRUB_DISTRIBUTOR=”$alternative”
      GRUB_CMDLINE_LINUX_DEFAULT=”${GRUB_CMDLINE_LINUX_ALTERNATIVE[$alternative]}”
      . ${0%/
      }/10_linux

      done

  16. I have a Dell Precision 5520 with Optimus (Intel/Nvidia GPUs) installed. I have used both of the following to try to install the drivers, but GDM doesn’t seem to be coming up on this Fedora 26 machine:

    dnf -y install nvidia-driver nvidia-settings kernel-devel

    and

    dnf install nvidia-settings kernel-devel dkms-nvidia vulkan.i686 nvidia-driver-libs.i686

    (I did a “dnf remove *nvidia*”, of course, in between the two installations to clean things up).

    I see the console systemd startup messages after I get the usual Fedora logo at startup, but the startup process never transitions to GDM, even though it does try to start GDM.

    It looks like some things are happy:

    dkms status

    nvidia, 384.59, 4.11.11-300.fc26.x86_64, x86_64: installed

    but I also see the following from dmesg:

    [ 410.396375] gnome-shell[2210]: segfault at 28 ip 00007fefc6bcd7e4 sp 00007ffc5a19c3e0 error 4 in libmutter-0.so.0.0.0[7fefc6b7e000+13a000]

    From journalctl -r:

    systemd-coredump[2219]: Process 2210 (gnome-shell) of user 42 dumped core.

    Stack trace of thread 2210:
    #0 0x00007fefc6bcd7e4 center_pointer (libmutter-0.so.0)
    #1 0x00007fefc6be1ad9 meta_backend_x11_post_init (libmutter-0.so.0)
    #2 0x00007fefc6be2b19 meta_backend_x11_cm_post_init (libmutter-0.so.0)
    #3 0x00007fefc6c0c586 meta_init (libmutter-0.so.0)
    #4 0x0000555fd6e041aa main (gnome-shell)
    #5 0x00007fefc06294da __libc_start_main (libc.so.6)
    #6 0x0000555fd6e045ba _start (gnome-shell)

    Stack trace of thread 2215:
    #0 0x00007fefc09ebf94 recvmsg (libpthread.so.0)
    #1 0x00007fefc3cc647c g_socket_receive_message_with_timeout (libgio-2.0.so.0)
    #2 0x00007fefc3cc6a66 g_socket_receive_message (libgio-2.0.so.0)
    #3 0x00007fefc3d14974 _g_socket_read_with_control_messages_ready (libgio-2.0.so.0)
    #4 0x00007fefc3cc3121 socket_source_dispatch (libgio-2.0.so.0)
    #5 0x00007fefc21ef247 g_main_context_dispatch (libglib-2.0.so.0)
    #6 0x00007fefc21ef5e8 g_main_context_iterate.isra.25 (libglib-2.0.so.0)
    #7 0x00007fefc21ef902 g_main_loop_run (libglib-2.0.so.0)
    #8 0x00007fefc3d14cb6 gdbus_shared_thread_func (libgio-2.0.so.0)
    #9 0x00007fefc2216536 g_thread_proxy (libglib-2.0.so.0)
    #10 0x00007fefc09e136d start_thread (libpthread.so.0)
    #11 0x00007fefc0719b8f __clone (libc.so.6)

    Stack trace of thread 2211:
    #0 0x00007fefc070da9d poll (libc.so.6)
    #1 0x00007fefc21ef569 g_main_context_iterate.isra.25 (libglib-2.0.so.0)
    #2 0x00007fefc21ef67c g_main_context_iteration (libglib-2.0.so.0)
    #3 0x00007fefc21ef6c1 glib_worker_main (libglib-2.0.so.0)
    #4 0x00007fefc2216536 g_thread_proxy (libglib-2.0.so.0)
    #5 0x00007fefc09e136d start_thread (libpthread.so.0)
    #6 0x00007fefc0719b8f __clone (libc.so.6)

    Stack trace of thread 2216:
    #0 0x00007fefc0714529 syscall (libc.so.6)
    #1 0x00007fefc22346fa g_cond_wait_until (libglib-2.0.so.0)
    #2 0x00007fefc21c3b31 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0)
    #3 0x00007fefc2216ed4 g_thread_pool_thread_proxy (libglib-2.0.so.0)
    #4 0x00007fefc2216536 g_thread_proxy (libglib-2.0.so.0)
    #5 0x00007fefc09e136d start_thread (libpthread.so.0)
    #6 0x00007fefc0719b8f __clone (libc.so.6)

    Stack trace of thread 2217:
    #0 0x00007fefc070da9d poll (libc.so.6)
    #1 0x00007fefc21ef569 g_main_context_iterate.isra.25 (libglib-2.0.so.0)
    #2 0x00007fefc21ef67c g_main_context_iteration (libglib-2.0.so.0)
    #3 0x00007fefa1319f3d dconf_gdbus_worker_thread (libdconfsettings.so)
    #4 0x00007fefc2216536 g_thread_proxy (libglib-2.0.so.0)
    #5 0x00007fefc09e136d start_thread (libpthread.so.0)
    #6 0x00007fefc0719b8f __clone (libc.so.6)

    Aug 09 09:35:43 gnome-session[2189]: Unable to init server: Could not connect: Connection refused
    Aug 09 09:35:43 spice-vdagent[2277]: Cannot access vdagent virtio channel /dev/virtio-ports/com.redhat.spice.0
    Aug 09 09:35:43 gnome-session-binary[2189]: WARNING: App ‘org.gnome.Shell.desktop’ respawning too quickly
    Aug 09 09:35:43 gnome-session-binary[2189]: Unrecoverable failure in required component org.gnome.Shell.desktop
    Aug 09 09:35:43 gnome-session-binary[2189]: WARNING: Application ‘org.gnome.Shell.desktop’ killed by signal 11
    Aug 09 09:35:43 gnome-session[2189]: gnome-session-binary[2189]: WARNING: App ‘org.gnome.Shell.desktop’ respawning too quickly
    Aug 09 09:35:43 gnome-session[2189]: gnome-session-binary[2189]: WARNING: Application ‘org.gnome.Shell.desktop’ killed by signal 11

    I have tried disabling Wayland for GDM by modifying “/etc/gdm/custom.conf” to have “WaylandEnable=false” (uncommented). The behavior is different–I see the Fedora bootup logo on the screen and don’t see the console messages at all. I don’t see the gnome-shell segfault messages via dmesg, but I see similar messages to the journalctl -r output above (gnome-shell is still crashing).

    If I remove the nvidia packages using “dnf remove *nvidia*”, I can get back to using the Nouveau drivers just fine.

    Any thoughts on how to resolve this?

    1. I figured out how to resolve the problem. As noted in https://wiki.debian.org/InstallingDebianOn/Dell/Precision%205520%20%28Laptop%29/jessie, the Linux kernel command line should not include nomodeset, but mine did. I removed nomodeset from /etc/sysconfig/grub and then ran grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg (See Fedora Wiki: Grub 2) to update GRUB 2. With this set properly, GDM comes up without crashing and I can use the laptop just fine with both Gnome 3 (using the Intel drivers and Wayland) and Plasma/KDE (using the proprietary Nvidia drivers and X).

      Thanks for all the great work to package the drivers and associated software!

  17. I have a fresh F26 install on a ASUS F556U notebook. lspci says:
    VGA compatible controller: Intel Corporation Device 5916 (rev 02)
    3D controller: NVIDIA Corporation GM108M [GeForce 940MX] (rev a2)

    $ rpm -qa nvidia*
    nvidia-driver-libs-384.59-1.fc26.i686
    nvidia-driver-384.59-1.fc26.x86_64
    nvidia-settings-384.59-1.fc26.x86_64
    nvidia-driver-libs-384.59-1.fc26.x86_64
    nvidia-driver-cuda-libs-384.59-1.fc26.x86_64
    nvidia-driver-cuda-384.59-1.fc26.x86_64
    nvidia-driver-NVML-384.59-1.fc26.x86_64
    nvidia-libXNVCtrl-384.59-1.fc26.x86_64
    nvidia-persistenced-384.59-1.fc26.x86_64

    $ dkms status
    nvidia, 384.59, 4.11.11-300.fc26.x86_64, x86_64: installed

    But the driver doesn’t seem to load properly:
    $ glxinfo | grep -i string
    server glx vendor string: SGI
    server glx version string: 1.4
    client glx vendor string: Mesa Project and SGI
    client glx version string: 1.4
    OpenGL vendor string: Intel Open Source Technology Center
    OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 620 (Kaby Lake GT2)
    OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.1.5
    OpenGL core profile shading language version string: 4.50
    OpenGL version string: 3.0 Mesa 17.1.5
    OpenGL shading language version string: 1.30
    OpenGL ES profile version string: OpenGL ES 3.2 Mesa 17.1.5
    OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

    Am I doing something wrong?

      1. […]
        00:02.0 VGA compatible controller: Intel Corporation Device 5916 (rev 02)
        Subsystem: ASUSTeK Computer Inc. Device 1490
        Kernel driver in use: i915
        Kernel modules: i915
        […]
        01:00.0 3D controller: NVIDIA Corporation GM108M [GeForce 940MX] (rev a2)
        Subsystem: ASUSTeK Computer Inc. Device 1490
        Kernel driver in use: nvidia
        Kernel modules: nouveau, nvidia_drm, nvidia
        […]

        And BTW: GRUB does have this in the config: rd.driver.blacklist=nouveau

        1. I’m assuming you are using X.org and not Wayland. Do you have any custom X.org configuration? You should not have anything, just use the package X.org configuartion files as they are.

          1. I haven’t done anything to X.org config.

            $ loginctl show-session 2 -p Type
            Type=wayland

            I have several repos activated in my install (most notably UnitedRMPS). I will install F26 again from scratch, and try it with your repo only. Will report after.

          2. Before reinstalling everything, can you just trying login with an X.org session instead of Wayland?

          3. Sorry, too late. This time, I did install only the basic stuff:

            $ sudo dnf install nvidia-settings kernel-devel dkms-nvidia

            But otherwise ended with exactly the same results. When I log in with X.org, though:

            $ glxinfo | grep -e string
            server glx vendor string: NVIDIA Corporation
            server glx version string: 1.4
            client glx vendor string: NVIDIA Corporation
            client glx version string: 1.4
            OpenGL vendor string: NVIDIA Corporation
            OpenGL renderer string: GeForce 940MX/PCIe/SSE2
            OpenGL core profile version string: 4.5.0 NVIDIA 384.59
            OpenGL core profile shading language version string: 4.50 NVIDIA
            OpenGL version string: 4.5.0 NVIDIA 384.59
            OpenGL shading language version string: 4.50 NVIDIA
            OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 384.59
            OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

          4. What is “same result”? In the previous comment you typed about Intel being used and not Nvidia, this is no longer the case. So is it working?

          5. With X.org yes, but with Wayland it’s still the same – i.e. Intel works, Nvidia doesn’t. glxinfo output looks the same for Wayland, but in X.org it shows what I pasted earlier.

  18. Hi, on F26 after update to latest driver and reboot Cinnamon is crashing and failing into safe mode. Removing dkms-nvidia and installing it back fixes the problem.

    1. I see the same thing – it broke within the last week while it had been working fine. When this driver is installed and plasma is selected from gdm, it tries to start X11 and goes back to gdm. Failed to initialize the nvidia kernel module. I can confirm it was working fine as I ran benchmarks before it broke recently.

      1. I forgot to mention that I also tried uninstalling this driver and installing the one from rpmfusion and got exactly the same result when I try to start KDE. Here is a pastebin of the Xorg log file: https://pastebin.com/W7PRreSa The system is fedora 26 with all updates installed. It did work fine until very recently.
        for i in $(rpm -ql nvidia-driver-libs.x86_64); do strings $i | grep nvidia-modprobe > /dev/null && echo $i; done
        /usr/lib64/libnvidia-cfg.so.1
        /usr/lib64/libnvidia-cfg.so.384.59
        /usr/lib64/libnvidia-eglcore.so.384.59
        /usr/lib64/libnvidia-glcore.so.384.59
        /usr/lib64/libnvidia-glsi.so.384.59
        /usr/lib64/vdpau/libvdpau_nvidia.so.1
        /usr/lib64/vdpau/libvdpau_nvidia.so.384.59

  19. There’s now three new driver versions released since 381.22. How to I get at a newer 38x driver while using negativo17?

      1. Many thanks! The update came fast!

        Was hoping the latest with all the improvements would solve the corrupted display on resume from suspend that Fedora 25 and 26 has but it didn’t 🙁

        I already know its either the Nvidia driver, gpu, or Fedora as this happens with the same gpu in two completely different computers. Though the installation of Fedora is dirty and I may do one more test with a clean Fedora install on the second computer but not holding out any hope.

        1. So… a clean install of Fedora 26 then the negativo17 Nvidia supplied driver actually worked! (No more resume from suspend issues. Unfortunately, no idea where the problem was. Maybe something left over from Fedora 25 or previous official Nvidia driver install.)

          And to get Steam working it requires an additional change Nvidia related change via terminal after the negativo17 supplied driver is installed and possibly a reboot (which may break nvidia-settings as that no longer starts). There’s so much fun with Fedora lol

  20. Hey, thanks a lot. My fedora 26 is working fine with more performance after installation. I installed with:

    sudo dnf install nvidia-settings kernel-devel dkms-nvidia vulkan.i686 nvidia-driver-libs.i686

    How can I test my drivers installation correctly?

    1. Well, if it doesn’t crash, that’s a good indication that you are not using Nouveau on a recent Nvidia card.

      glxinfo | grep -i string

      or any log will tell you which drivers are you using.

  21. I just installed the drivers on Fedora 26, but I can’t get to the login screen. I erased rhgb and quiet from grub, and the last message was [OK] Starting Gnome Display Manager. When I checked /var/log/X.org.0.log, it says
    LoadModule: “ramdac”
    Module “ramdac” already built-in
    NVIDIA: Failed to initialize the NVIDIA kernel module. Please see the system’s kernel log for additional error messages […]
    When I did rpm -qa nvidia kernel* | sort, the output told me I have kernel, kernel-core, kernel-devel and kernel-modules for 4.11.10-300.fc26.x86_64 and a few older ones.

    1. Make sure the dkms module is built:

      # dkms status
      nvidia, 381.22, 4.11.10-300.fc26.x86_64, x86_64: installed

      If not:

      # dkms add nvidia/381.22
      # dkms build nvidia/381.22
      # dkms install nvidia/381.22
      # reboot
      1. $ dkms status
        nvidia, 381.22, 4.11.10-300.fc26.x86_64, x86_64: installedError! Could not locate dkms.conf file.
        File: does not exist.

        $ sudo dkms install nvidia/381.22
        Module nvidia/381.22 already installed on kernel 4.11.10-300.fc26.x86_64/x86_64

        How should I fix this?

  22. This has been a problem for me since F25, but someone might be able to help me. My AVR is giving out wrong EDID, so I use Option “UseEDID” “FALSE”, and set the “metamodes” in xorg.conf:
    Section “Screen”
    Identifier “Screen0”
    Device “Device0”
    Monitor “Monitor0”
    Option “metamodes” “DFP-1: 1920×1080 +0+0”
    DefaultDepth 24
    SubSection “Display”
    Depth 24
    EndSubSection
    EndSection

    However, I’m not able to manually set the “metamodes”. I get this in my Xorg.0.log:
    [ 51.877] () NVIDIA(0): NVIDIA SLI auto-select rendering option.
    [ 51.877] (
    ) NVIDIA(0): Option “UseEDID” “FALSE”
    [ 51.878] () NVIDIA(0): Option “MetaModes” “DFP-1: 1920×1080 +0+0”
    [ 51.878] (
    ) NVIDIA(0): Enabling 2D acceleration
    [ 51.878] (**) NVIDIA(0): Ignoring EDIDs
    [ 51.886] (WW) NVIDIA(0): Failed to initialize Base Mosaic! Reason: Only one GPU
    [ 51.886] (WW) NVIDIA(0): detected. Only one GPU will be used for this X screen.
    [ 52.536] (–) NVIDIA(0): Valid display device(s) on GPU-0 at PCI:2:0:0
    [ 52.536] (–) NVIDIA(0): CRT-0
    [ 52.536] (–) NVIDIA(0): CRT-1
    [ 52.536] (–) NVIDIA(0): DFP-0
    [ 52.536] (–) NVIDIA(0): DFP-1 (boot)
    [ 52.537] (II) NVIDIA(0): NVIDIA GPU GeForce GT 430 (GF108) at PCI:2:0:0 (GPU-0)
    [ 52.537] (–) NVIDIA(0): Memory: 1048576 kBytes
    [ 52.537] (–) NVIDIA(0): VideoBIOS: 70.08.29.00.01
    [ 52.537] (II) NVIDIA(0): Detected PCI Express Link width: 16X
    [ 52.540] (–) NVIDIA(GPU-0): CRT-0: disconnected
    [ 52.540] (–) NVIDIA(GPU-0): CRT-0: 400.0 MHz maximum pixel clock
    [ 52.540] (–) NVIDIA(GPU-0):
    [ 52.541] (–) NVIDIA(GPU-0): CRT-1: disconnected
    [ 52.541] (–) NVIDIA(GPU-0): CRT-1: 400.0 MHz maximum pixel clock
    [ 52.541] (–) NVIDIA(GPU-0):
    [ 52.543] (–) NVIDIA(GPU-0): DFP-0: disconnected
    [ 52.543] (–) NVIDIA(GPU-0): DFP-0: Internal TMDS
    [ 52.543] (–) NVIDIA(GPU-0): DFP-0: 330.0 MHz maximum pixel clock
    [ 52.543] (–) NVIDIA(GPU-0):
    [ 52.543] (–) NVIDIA(GPU-0): DFP-1: connected
    [ 52.543] (–) NVIDIA(GPU-0): DFP-1: Internal TMDS
    [ 52.543] (–) NVIDIA(GPU-0): DFP-1: 165.0 MHz maximum pixel clock
    [ 52.543] (–) NVIDIA(GPU-0):
    [ 52.544] (WW) NVIDIA(0): No valid modes for “DFP-1:1920×1080+0+0”; removing.
    [ 52.544] (WW) NVIDIA(0):
    [ 52.544] (WW) NVIDIA(0): Unable to validate any modes; falling back to the default mode
    [ 52.544] (WW) NVIDIA(0): “nvidia-auto-select”.
    [ 52.544] (WW) NVIDIA(0):
    [ 52.547] (II) NVIDIA(0): Validated MetaModes:
    [ 52.548] (II) NVIDIA(0): “DFP-1:nvidia-auto-select”
    [ 52.548] (II) NVIDIA(0): Virtual screen size determined to be 640 x 480

    Now, I can only see 640×480 resolution on my big TV which makes me sad. Is there anyone who can help me figure out why the metamode won’t take? I’m suspecting the wrong pixel clock from the AVR. If that’s true, is there option to override the pixel clock too?

    Thanks!

  23. Hello Slanesh

    I successfully installed your repo in fedora 26 and nvidia proprietary drivers in my optimus laptop. I was
    able to run Gnome in X11 and Wayland mode. But I dislike gnome and try to install other window
    managers, like XFCE, Matte, but all of them do not run with your setup. I login in lightdm and
    the screen stays black without showing nothing. It only works if I remove 10-nvidia.conf and
    runs in intel driver. Do you know what is happening or how to debug why this is happening? Any
    help is welcome.

    1. I remember having seen a bug on bugzilla.redhat.com about lightdm and other login managers not playing nicely with Optimus setups, but I can’t find it, sorry.

        1. Have you ever managed to resolve the issue with black screen?
          I’m on fedora 26 with xfce and after installing this driver, i can login into Gnome and everything is ok, but with xfce i only get black screen.

  24. I struggle to compile the cuda samples from below amidst looking for cuda-install-samples-8.0.sh in vain. Any advice? Appreciate!

    dnf -y install cuda nvidia-driver-cuda cuda-devel cuda-samples
    uname -r
    4.11.9-300.fc26.x86_64
    cd /usr/share/cuda/samples/
    make
    make[1]: Entering directory ‘/usr/share/cuda/samples/0_Simple/UnifiedMemoryStreams’
    /usr/bin/nvcc –include-path /usr/include/cuda -ccbin g++ -I../../common/inc -m64 -Xcompiler -fopenmp -gencode arch=compute_30,code=sm_30 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52 -gencode arch=compute_60,code=sm_60 -gencode arch=compute_60,code=compute_60 -o UnifiedMemoryStreams.o -c UnifiedMemoryStreams.cu
    /usr/lib/gcc/x86_64-redhat-linux/7/include/stddef.h(444): error: identifier “nullptr” is undefined

    1. You need to use GCC 5.3 to use CUDA on Fedora. Last GCC supported version by CUDA 8 is 5.3. Look for compat-gcc* packages in the same repository.

      1. Thanks for the hint! However, I seem to still be missing s.th. see below. Any ideas?

        [root@localhost samples]# dnf install compat-gcc-53
        [root@localhost samples]# make
        make[1]: Entering directory ‘/usr/share/cuda/samples/0_Simple/UnifiedMemoryStreams’
        /usr/bin/nvcc –include-path /usr/include/cuda -ccbin g++ -I../../common/inc -m64 -Xcompiler -fopenmp -gencode arch=compute_30,code=sm_30 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52 -gencode arch=compute_60,code=sm_60 -gencode arch=compute_60,code=compute_60 -o UnifiedMemoryStreams.o -c UnifiedMemoryStreams.cu
        /usr/lib/gcc/x86_64-redhat-linux/7/include/stddef.h(444): error: identifier “nullptr” is undefined

        /usr/lib/gcc/x86_64-redhat-linux/7/include/stddef.h(444): error: expected a “;”

        /usr/include/c++/7/x86_64-redhat-linux/bits/c++config.h(2196): error: expected a “;”

          1. I am trying to compile the julia package knet. Your examples got me past the c++ errors; however, I am not getting link errors eventhough I am using the -fPIC switch (see below). Do you have any suggestions on how to resolve this?

            .
            .
            .
            nvcc -ccbin /usr/bin/g++53 -Xcompiler -fPIC -c -O3 –use_fast_math -Wno-deprecated-gpu-targets –compiler-options “-shared -O3 -Wall -fPIC -fopenmp” -I/usr/include/cuda cuda22.cu -o cuda22.o
            nvcc -ccbin /usr/bin/g++53 -Xcompiler -fPIC -c -O3 –use_fast_math -Wno-deprecated-gpu-targets –compiler-options “-shared -O3 -Wall -fPIC -fopenmp” -I/usr/include/cuda conv.cpp -o conv.o
            nvcc -ccbin /usr/bin/g++53 -Xcompiler -fPIC –shared -O3 –use_fast_math -Wno-deprecated-gpu-targets –compiler-options “-shared -O3 -Wall -fPIC -fopenmp” -I/usr/include/cuda cuda1.o cuda01.o cuda11.o cuda12.o cuda13.o cuda16.o cuda17.o cuda20.o cuda21.o cuda22.o conv.o -o libknet8.so
            /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/5.3.1/libgomp.a(parallel.o): relocation R_X86_64_32 against hidden symbol gomp_global_icv' can not be used when making a shared object
            /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/5.3.1/libgomp.a(team.o): relocation R_X86_64_TPOFF32 against hidden symbol
            gomp_tls_data’ can not be used when making a shared object
            /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/5.3.1/libgomp.a(proc.o): relocation R_X86_64_32 against hidden symbol gomp_global_icv' can not be used when making a shared object
            /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/5.3.1/libgomp.a(affinity.o): relocation R_X86_64_32 against
            .rodata.str1.8′ can not be used when making a shared object; recompile with -fPIC
            /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/5.3.1/libgomp.a(alloc.o): relocation R_X86_64_32 against .rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
            /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/5.3.1/libgomp.a(env.o): relocation R_X86_64_32 against hidden symbol
            gomp_global_icv’ can not be used when making a shared object
            /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/5.3.1/libgomp.a(error.o): relocation R_X86_64_32 against .rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
            /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/5.3.1/libgomp.a(task.o): relocation R_X86_64_32S against
            .rodata’ can not be used when making a shared object; recompile with -fPIC
            /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/5.3.1/libgomp.a(target.o): relocation R_X86_64_32 against .rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
            /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/5.3.1/libgomp.a(splay-tree.o): relocation R_X86_64_32 against
            .rodata.str1.1′ can not be used when making a shared object; recompile with -fPIC
            /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/5.3.1/libgomp.a(oacc-init.o): relocation R_X86_64_32 against .rodata' can not be used when making a shared object; recompile with -fPIC
            /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/5.3.1/libgomp.a(oacc-host.o): relocation R_X86_64_32 against
            .rodata.str1.1′ can not be used when making a shared object; recompile with -fPIC
            /usr/bin/ld: final link failed: Nonrepresentable section on output
            collect2: error: ld returned 1 exit status
            make: *** [Makefile:18: libknet8.so] Error 1

  25. After upgrading to fedora 26 (yes, apparently I did this too soon), I get the login screen(gnome), but when I try to log in it:
    1. under wayland, simply freezes
    2. under X, kicks me back to the login screen.

    In journalctl -k -b -1 I see a lot of refs to nouveau and none to nvidia, which I was not expecting, along with some bits that look like errors, such as:

    kernel: nouveau 0000:01:00.0: DRM: Pointer to flat panel table invalid
    kernel: nouveau 0000:01:00.0: DRM: failed to create kernel channel, -22

    I can provide more of this output if requested, but it seemed like a lot to dump in a comment. Note that this system worked just fine using nvidia drivers before upgrade, and had nouveau blacklisted both in grub opts and modprobe.d/blackllist. Any thoughts on how I can correct this issue, or further detail that may be needed to debug? Thanks!

    1. Hey,

      For me Fresh Fedora 26 install works OK with Negativo17 nvidia drivers in Xorg. Wayland freezes as you described.

      I’m not a very advanced linux user, but with my limited knowledge I would do following:

      1) Enter console.
      2) sudo dnf -y remove *nvidia*
      3) Reboot
      4) Now you should be able to login to Gnome xorg/wayland
      5) Reinstall the driver: sudo dnf install nvidia-settings kernel-devel dkms-nvidia vulkan.i686 nvidia-driver-libs.i686

      1. Sorry for the delayed response. Faults, thanks, that did indeed work. I had started down this path, but dnf wanted to take a bunch of packages with it (like libreoffice). I was able to narrow down the list by setting most of them to userinstalled, so the reinstall list was more manageable. Note that with the newer cards (I have a 1050ti), you can’t even log in to your DE without the nvidia driver, nouveau seems to have no support yet (last I tried anyway). Not a big deal, you just ssh in or set init 3 and do the reinstall from there, just a note for others.

  26. Possible bug with Fedora 26 Beta + Nvidia driver.

    I have just installed two (Lenovo + Dell) Fresh 26 Beta installs on Optimus laptop. I haven’t managed to get work neither.

    1) Fresh Fedora 26 Beta install
    2) dnf update
    3) Adding RPMFusion repos
    4) Adding Nvidia + Multimedia Negativo17 repo
    5) dnf update
    6) Installing Nvidia driver: sudo dnf install nvidia-settings kernel-devel dkms-nvidia vulkan.i686 nvidia-driver-libs.i686
    7) After reboot Nvidia driver is not loaded. Nouveau works with Xorg, Wayland not start.

    Sorry for limited information for troubleshooting… I will dig deeper tomorrow.

    1. Nevermind… It must been something what I did wrong. Today after reinstall all stuff works as intended. 🙂

  27. I still can’t get wayland to start correctly with fully updated F26. Can you help me with this problem? Thanks.

    nvidia-driver-libs-381.22-6.fc26.x86_64
    dkms-nvidia-381.22-2.fc26.x86_64
    nvidia-driver-cuda-libs-381.22-6.fc26.x86_64
    nvidia-driver-381.22-6.fc26.x86_64

    I didn’t change any settings except /usr/lib/modprobe.d/nvidia.conf

    If I don’t change it, gnome falls back to X11
    gnome-shell[1261]: Can’t initialize KMS backend: could not find drm kms device
    gnome-session[1254]: gnome-session-binary[1254]: WARNING: App ‘org.gnome.Shell.desktop’ exited with code 1

    If I changed it to “nvidia-drm.modeset=1” , gnome wayland starts but is very slow
    gnome-shell[1634]: Failed to apply DRM plane transform 0: Invalid argument
    org.gnome.Shell.desktop[1634]: Disabling glamor and dri3, EGL setup failed
    org.gnome.Shell.desktop[1634]: Failed to initialize glamor, falling back to sw

    1. It doesn’t matter, the driver is excluded from loading in the initird:

      https://github.com/negativo17/nvidia-driver/blob/master/nvidia-driver.spec#L7
      https://github.com/negativo17/nvidia-driver/blob/master/nvidia-driver.spec#L15
      https://github.com/negativo17/nvidia-driver/blob/master/nvidia-driver.spec#L27

      Do you come from a different installation, maybe wiht Nvidia’s own makeself or other packages? With the driver installed, try to rebuild the initird (dracut -f force) and reboot.
      Also, make sure you don’t have any X configuration created by you.

      1. dracut -f && reboot results in a white screen just before I’d normally get a GUI login screen. Xorg.0.log indicates the nvidia driver found no devices it recognised, but lspci lists the GeForce device. There are no loose X configuration bits. It looks like the Intel HD graphics are on and the GeForce is off.

        1. Can you paste the output of the following commands?

          lsmod | egrep "intel|nouveau|nvidia"
          rpm -qa *nvidia* kernel* | sort
          lspci | grep -i vga

  28. Hi there! Thank you for all the work!

    I have a desktop running Centos 7 with an i7-3770 that has an integrated GPU and an nVidia GTX980. At the moment I am not using the intel GPU at all (the monitor is attached to the nvidia GPU). However since this machine is for CUDA development, I would like to use the Intel GPU for displaying the desktop and the nVidia GPU only for compute. I am a little puzzled on how to do that, according to your instructions.

    My /etc/default/grub file looks like this:

    GRUB_TIMEOUT=5
    GRUB_DISTRIBUTOR=”$(sed ‘s, release .*$,,g’ /etc/system-release)”
    GRUB_DEFAULT=saved
    GRUB_DISABLE_SUBMENU=true
    GRUB_TERMINAL_OUTPUT=”console”
    GRUB_CMDLINE_LINUX=”nouveau.modeset=0 rd.driver.blacklist=nouveau crashkernel=auto rd.lvm.lv=idefix/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=idefix/root vconsole.keymap=us rhgb rd.driver.blacklist=nouveau”
    GRUB_DISABLE_RECOVERY=”true”
    GRUB_GFXPAYLOAD_LINUX=text

    How should I edit this in order to achieve what you are suggesting?

    Thank you in advance,
    Andreas

    1. If you have an Nvidia and an Intel card, and the Intel is for display, you have to do some fiddling around.
      I will update the instructions. On Fedora, is much easier, on CentOS there’s some change required.

  29. Sorry to bug you, but I couldn’t find help anywhere else. Gnome won’t start in wayland mode, falls back to x11.

    rpm -qa | grep nvidia
    nvidia-driver-libs-381.22-6.fc26.x86_64
    dkms-nvidia-381.22-2.fc26.x86_64
    nvidia-driver-cuda-libs-381.22-6.fc26.x86_64
    nvidia-driver-381.22-6.fc26.x86_64

    gnome-shell[1384]: Can’t initialize KMS backend: could not find drm kms device
    gnome-session[1363]: gnome-session-binary[1363]: WARNING: App ‘org.gnome.Shell.desktop’ exited with code 1
    gnome-session-binary[1363]: WARNING: App ‘org.gnome.Shell.desktop’ exited with code 1
    gnome-session-binary[1363]: Unrecoverable failure in required component org.gnome.Shell.desktop
    gdm-launch-environment][1185]: pam_unix(gdm-launch-environment:session): session closed for user gdm

  30. Excellent work and thanks for accompanying it with such a complete technical writeup of how it works!

    I am curious about the Nouveau fallback. You say that if the nvidia kernel module fails to load, the system automatically falls back to nouveau?

    But I presume that the nouveau kernel module was blacklisted somewhere along the way, which is what makes the nvidia proprietary module get loaded instead. So how does the nouveau kernel driver get loaded in the fallback path?

    1. Pretty simple, most of the explanation is in the spec file (https://github.com/negativo17/nvidia-driver/blob/master/nvidia-driver.spec#L4-L32). On Fedora 25 there is only rd.driver.blacklist=nouveau defined, so that means that apart from nouveau being included & loaded from the initrd, there is nothing preventing it from loading, modesetting the screen, etc. The blacklist configuration (https://github.com/negativo17/nvidia-driver/blob/master/nvidia.conf#L1) is also used only when calling modprobe -b from udev, so it’s ignored by the systemd unit file which explicitly loads the module (https://github.com/negativo17/nvidia-driver/blob/master/nvidia-fallback.service#L10)

  31. Has anyone been able to get virtio-gpu/virGL to work in fedora 25 or 26 ? When I try and load a guest with virtio/spice with open GL enabled the VM crashes a few moments after it launches with:

    qemu-system-x86_64: Couldn’t find current GLX or EGL context.

    1. Ok, I did hit it a little more.

      glxinfo showed Gallium, weirdly, with a backed xorg, nvidia-settings discord. So I guessed my system is loading nouveau even with 381.22-6. I did a dirty trick moving nouveau DRM driver from /usr/lib/modules and doing ”dracut -f” and everything is fine again.

      1. No need to remove the module, just rebuild the initrd:

        $ cat /usr/lib/dracut.conf.d/99-nvidia-dracut.conf
        # omit the nvidia driver from the ramdisk, to avoid needing to regenerate
        # the ramdisk on nvidia driver updates
        omit_drivers+=" nvidia-drm "

        Probably you had it included in the initrd from some previous installation.

        1. It worked, but now I did a upgrade to Fedora 26 and for some reason it didn’t build nvidia modules, nvidia-driver and dkms-nvidia are installed but dkms status gives nothing and the modprobe didn’t show any nvidia driver. I reverted to my last snapshot, any Idea why?

  32. There’s been talk about Gnome 3.24 and Mesa 17.1 including support for running Wayland on Nvidia proprietary drivers. Is it possible to run Wayland in F26 with the latest drivers?

  33. Hey, I have asked this before, but I ask now again about PrimeSync. I have now extremely good change to try out PrimeSync on two different Optimus laptop. One is Lenovo W540 Intel/Quadro and another is brand new Dell Intel/Geforce Pascal. Both has clean Fedora 25 and Negativo17 nvidia Repo added.

    What should I do for FRESH Fedora 25 to enable PrimeSync. I can do all sort of testing these as those are not production laptops for while.

    (I don’t want to break my own laptop again with testing Primesync) 🙂

    Thank you.

    1. If you want to test on your system, just do the following as root:

      echo "option nvidia-drm modeset=1" > /etc/modprobe.d/nvidia-drm.conf
      depmod -a
      reboot

      If for whatever reason you have support for PRIME Synchronization but wish to disable it, you may disable it via xrandr –output --set “PRIME Synchronization” 0 and re-enable it via xrandr –output --set “PRIME Synchronization” 1.

        1. echo gives me a permission denied even with sudo, but I created a file with nano where I added option nvidia-drm modeset=1. I ran depmod -a and reboot.

          Nothing happens. 🙂

          Setup: Intel® HD Graphics 630 + Pascal 1050 Ti Optimus

          1. Sadly tearing is still in there…. 🙁 How can I check if PrimeSync is in use?

          2. Hey,

            Tried now with Fedora 26 on W540. Intell 4000 / Quadro K2100M setup.

            Same as with Dell… nothing happens. Screen Tearing is still there.

            I ran xrandr –verbose which shows that my display is PRIME Sync 0.

            PRIME Synchronization: 0
            supported: 0, 1

            When I try to enable it then screen just flashes and its back to 0.

            Nvidia-bug-report log: https://drive.google.com/open?id=0B9Gh7bg64e8KVWdxMW9GRHl3ZFU

  34. [fierce.brake@movil-01 ~]$ sudo rpm -qa nvidia*
    nvidia-modprobe-381.22-1.fc25.x86_64
    nvidia-driver-381.22-5.fc25.x86_64
    nvidia-libXNVCtrl-381.22-1.fc25.x86_64
    nvidia-xconfig-381.22-1.fc25.x86_64
    nvidia-settings-381.22-1.fc25.x86_64
    nvidia-driver-libs-381.22-5.fc25.x86_64
    nvidia-driver-libs-381.22-5.fc25.i686
    [fierce.brake@movil-01 ~]$

    I did “dracut -f && reboot” but no luck after reboot.

    What else should i try ?

  35. hello! i own an asus k556u laptop with nvidia geforece 940mx card.
    WHn i run nvidia-settings i get this:

    ERROR: Unable to find display on any available system

    and when i launch games they look awful, as if the driver is not working.

    fierce.brake@movil-01 nvidia]$ lsmod | grep -E -i “nvidia|nouveau”
    nvidia_drm 45056 0
    nvidia_modeset 811008 1 nvidia_drm
    nvidia 11546624 1 nvidia_modeset
    drm_kms_helper 155648 2 i915,nvidia_drm
    drm 352256 13 i915,nvidia_drm,drm_kms_helper

    [fierce.brake@movil-01 nvidia]$ dkms status
    nvidia, 381.22, 4.10.14-200.fc25.x86_64, x86_64: installed

    1. It seems it’s loading nouveau before nvidia.
      Can you confirm that you have nvidia-driver-381.22-5.fc25.x86_64 installed?
      Without doing anything special, with the system in the current state, can you do a:

      dracut -f && reboot

      And let me know? I think somehow your nouveau module is in the initrd.

      1. [fierce.brake@movil-01 ~]$ sudo rpm -qa nvidia*
        nvidia-modprobe-381.22-1.fc25.x86_64
        nvidia-driver-381.22-5.fc25.x86_64
        nvidia-libXNVCtrl-381.22-1.fc25.x86_64
        nvidia-xconfig-381.22-1.fc25.x86_64
        nvidia-settings-381.22-1.fc25.x86_64
        nvidia-driver-libs-381.22-5.fc25.x86_64
        nvidia-driver-libs-381.22-5.fc25.i686
        [fierce.brake@movil-01 ~]$

        I did “dracut -f && reboot” but no luck after reboot.

        What else should i try ?

  36. Hi, just a quick question. I know that nvidia provides kms support since last few versions and that should enable plymouth native support. However, enabling modesetting and adding nvidia modules to initrd doesnt seem to work. There is noticable blink just when kernel is loaded, indicating it tries to enter graphical mode, but second later it falls back to text mode boot, and continues.

    Was anyone successfull on using nvidia-drm modesetting and plymouth in Fedora 25?

    1. Actually the KMS support for the Nvidia driver is only for Wayland. There is no console support, the console would still be in text mode. So plymouth will be no different and would run at VGA resolutions. Unless of course you are on an Optimus laptop, in which case plymouth is running on the KMS console provided by the Intel driver.

      file:///usr/share/doc/nvidia-driver/html/kms.html

      The nvidia-drm module must not be in the intird, or you will have all sort of issues when upgrading the drivers.
      Anyway, if you want to test on your system, just do the following as root:

      echo "option nvidia-drm modeset=1" > /etc/modprobe.d/nvidia-drm.conf
      depmod -a
      reboot

      This should allow you to select Wayland from the login screen and see the desktop if you are running on the Nvidia drivers. Please note that this is not stable for everyone at the moment.

      1. I had this line in modprobe.d already, however it changed nothing since im not using gnome. Only thing i was interested to check if its possible to have nice fancy boot splash at startup. Well its something i can live without 🙂 cheers, SLAANESH and thanks for informations.

        1. Well, if you just installed your system using UEFI, your console runs on efifb which has KMS console support, thus giving you the Plymouth graphical boot without doing anything.

          1. I have EFI system, however fedora is installed in old fashion BIOS method, thus there is no framebuffer device at startup. From what i’ve read there is an issue with plymouth actually not asking the driver for desired video mode, and that causes to fall back to text boot. You can find this info and plymouth patch on nvidia forums.

            One another thing: i noticed multimedia repo still has nvidia-378 driver and nvidia repo has 381 already.

          2. Well, my experience is:

            efifb is used at boot. As soon as a proper drivers is loaded (intelfb, nouveaufb, mgafb, etc.) the framebuffer is stolen and attached to the new driver. Plymouth runs on that one.

            Example on my system:

            [ 0.921216] fb0: EFI VGA frame buffer device
            [ 21.783776] fb: switching to inteldrmfb from EFI VGA
            [ 21.916407] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
            [ 22.158371] nouveau 0000:01:00.0: fb: 6144 MiB GDDR5
            [ 22.589653] nouveau 0000:01:00.0: DRM: allocated 1024x768 fb: 0x60000, bo ffff8c2dfecb8000
            [ 22.590078] fbcon: nouveaufb (fb1) is primary device
            [ 22.590079] fbcon: Remapping primary device, fb1, to tty 1-63
            [ 22.719951] nouveau 0000:01:00.0: fb1: nouveaufb frame buffer device
            [ 26.885991] fbcon: Remapping primary device, fb0, to tty 1-63

            If you are using the Nvidia drivers, there is no framebuffer console, so you have the X drivers loaded (or KMS with Wayland), but if you switch back, you are switching the console back to efifb.

            One another thing: i noticed multimedia repo still has nvidia-378 driver and nvidia repo has 381 already.

            I know, I’m preparing more updates there to make just one push to the repositories.

  37. Thanks from fast reply! Sadly after 381.22-4 patch it still falls back to nouveau…

    I patched + booted = No luck
    I removed Nvidia driver + booted + Reinstalled + Reboot = No luck

    I patched 381.22-4 + rebooted on Fedora 26 Alpha on identical hardware = Works

    1. Please do the following, if you still have the problem. With the drivers installed (doesn’t matter if on Nouveau or Nvidia) run:

      dracut -f

      And reboot. Please let me know.

        1. As soon as it is booted, check that the Nvidia modules are built and loaded. If those are, the rest should follow.

          lsmod | grep -E -i "nvidia|nouveau"

          If they are not, and you are usign DKMS, check that they are built:

          dkms status

          If not, add/build/install them:

          dkms add nvidia/381.22
          dkms build nvidia/381.22
          dkms install nvidia/381.22

          If using akmods, make sure that the rpm package for the modules is installed:

          rpm -qa kmod-nvidia\*

          If not, build it with:

          akmods --force

          1. nouveau 1601536 2
            mxm_wmi 16384 1 nouveau
            ttm 98304 1 nouveau
            i2c_algo_bit 16384 2 nouveau,i915
            drm_kms_helper 155648 2 nouveau,i915
            drm 352256 11 nouveau,i915,ttm,drm_kms_helper
            wmi 16384 2 mxm_wmi,nouveau
            video 40960 3 thinkpad_acpi,nouveau,i915

            Looks like this.. I also run dkms commands and rebooted.

            No luck 🙁

      1. I updated 381.22-5, but no luck. Might be that I have something weird going in my system.

        I did dracut -f

        1. No secure boot ? (forgot to sign the mod if you usually do it)
          No dmesg related to nvidia ?
          “ll /lib/modules/uname -r/extra” give you the nvidia module ? (so compilation is correct)

    2. I just re-installed Korora 25 and drivers works just great. Must been something wrong in my setup.

  38. I have Korora 25 Gurgle kernel x86_64 Linux 4.10.14-200.fc25.x86_64 with xfce4 xfwm4 GPU Gallium 0.4 in NV117.

    I got nvidia-driver 381.22 this morning.

    Since this update fan of graphic card is screaming and makes a lot of noise. Speed of fan is constantly changing up and down.

    When calling Nvidia X Server setting it says: You do not appear to be using nvidia x driver. Please edit yr config file (run nvidia-xconfig as root). I did it. After that no more xfce4 anymore.

    Then i removed nvidia-driver install completely “dnf remove *nvidia*” and did fresh install “dnf install nvidia-driver nvidia-settings kernel-devel”.

    This brings back xfce4 with driver 381.22.

    But fan is still same very noisy and loud. Going up and down.

    When calling Nvidia X Server setting it still says: You do not appear to be using nvidia x driver. Please edit yr config file (run nvidia-xconfig as root) again.

    How to downgrade to driver version before?

    1. I have no Fan issue, but I’m quite sure that is caused because Nouveau drivers are in use instead of Nvidia ones.

      BUT I do have same issue with 381.22 as you do… those not get loaded after upgrade. I did “dnf history undo id” to fix this for now.

      I hope some advices how to make it work.

      1. ARGH! dnf history undo didn’t saved me from trouble! I’m stuck with Nouveau drivers for now… 🙁

        1. I found the issue, it is related to the introduction of the planned fallback service. The systems loads nouveau and the Mesa stack if there is any problem with the Nvidia drivers.
          I was able to reproduce the problem on one laptop, new build coming in a minute.

          Just a dnf update and a reboot should be fine.

      2. I found the issue, it is related to the introduction of the planned fallback service. The systems loads nouveau and the Mesa stack if there is any problem with the Nvidia drivers.
        I was able to reproduce the problem on one laptop, new build coming in a minute.

        Just a dnf update and a reboot should be fine.

        1. Hey,

          Thank you very much from fast response.

          -This issue got fixed in Fedora 26 Alpha (Lenovo W540 Quadro K2100M)

          -This issue is STILL in Fedora 25 (Lenovo W540 Quadro K2100M) –> I even removed all Nvidia related from this workstation and I did reinstall, but no success. ( 1) sudo dnf -y remove *nvidia* –> 2) sudo dnf install nvidia-settings kernel-devel dkms-nvidia vulkan.i686 nvidia-driver-libs.i686 )

    2. I found the issue, it is related to the introduction of the planned fallback service. The systems loads nouveau and the Mesa stack if there is any problem with the Nvidia drivers.
      I was able to reproduce the problem on one laptop, new build coming in a minute.

      Just a dnf update and a reboot should be fine.

    3. How to downgrade to driver version before?

      There are the last 3 revisions of each package available in the repository.

  39. Hi, is there a way to install cuda-cudnn 5? Tensorflow is not compatible with cuda-cudnn 6 at the moment

  40. Do the drivers here work with Bumblebee? the kmod-nvidia driver and bumblebee have been the only way I can get my laptop to boot (dual Intel and nVidia GPUs) and get into gdm. I currently have an issue where I need to enable to nvidia libraries for CUDA to work, but it breaks Xorg/gdm (white screen before login).

    If I can use these drivers for CUDA and not bother with bumblebee and still be able to get into gdm, that would be even better.

  41. Hi slaanesh,
    Thanks for the work on the repo.
    I’m having some issues on F26, which is actually why I found your repo

    Reboot after an update to kernel 4.10.10, my drivers stoped working. Long story short, I installed the packages from here and it is still not working.
    No errors in messages nor Xorg.log files, the last messages are Option “fd” “46” and systemd-logind: got pause for XX:XX

    any ideas on how to debug this futher?

    B

  42. Thanks for all of your efforts in creating these repositories.
    I just installed the drivers and cuda packages under Fedora 25.
    I just got a new Nvida 1070 card and the graphics work beautifully.

    However, the cuda applications are not recognizing the card.
    Could I be missing a configuration setting somewhere or a conflict from
    a file for my previous Nvidia GTX280 card?

    1. What do you mean by “not recognized”? Did you install the nvidia-driver-cuda package and reboot (it requires the nvidia-uvm module to be loaded).

      1. The problem was between the seat and keyboard. I had all of the cuda packages installed except nvidia-driver-cuda. it works now. Thanks.

      2. Thank you for the repo. I have GTX 980M and the driver works with fedora 25. On same laptop I installed centos 7.3 workstation on second disk (uefi, secure boot disabled) and the driver loaded but no logon screen. I tried with kmod then dkms and same result. The driver loaded but just bomb out with no logon screen. Thanks in advance for any help.

        1. You install nvidia-driver-cuda and reboot. Then check this for an explanation:

          $ cat /usr/lib/modprobe.d/nvidia-uvm.conf

  43. Thanks for the package! However, the akmod compile fails on me on a fresh new F26-alpha (kernel 4.11.0-0.rc5):

    X86_64/nvidia-drm/nvidia-drm-drv.c:682:31: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]

    .unload = nvidia_drm_unload,

    Do you know if any fix is incoming, or should I go back to F25?

  44. Running Fedora 25 Gnome. Do you save the nvidia settings as “nvidia.conf” or “nvidia-xorg.conf” in the /etc/x11 folder? Which one works? When I reboot the boxes are unchecked (ForceCompositionPipeline and Force Full Composition Pipeline).Thanks.

    1. It depends on what you need to do. If you just want to add an additional settings to the Device section then you might just edit /etc/X11/xorg.conf.d/10-nvidia.conf.

  45. Hi negativo,

    For some reasons, dkms seems unable to build with following result

    DKMS make.log for nvidia-378.13 for kernel 4.10.5-200.fc25.x86_64 (x86_64)
    Sun Mar 26 23:30:10 PDT 2017
    Makefile:19: /Kbuild: No such file or directory
    make: *** No rule to make target ‘/Kbuild’. Stop.

    kernel-devel is already installed as listed below
    $ dnf list installed *kernel* | grep 4.10.5-200
    kernel.x86_64 4.10.5-200.fc25 @updates-testing
    kernel-core.x86_64 4.10.5-200.fc25 @updates-testing
    kernel-devel.x86_64 4.10.5-200.fc25 @updates-testing
    kernel-headers.x86_64 4.10.5-200.fc25 @updates-testing
    kernel-modules.x86_64 4.10.5-200.fc25 @updates-testing
    kernel-tools.x86_64 4.10.5-200.fc25 @updates-testing
    kernel-tools-libs.x86_64 4.10.5-200.fc25 @updates-testing

    Graphic card is Nvidia Geforce GTX 460v2

  46. I have Optimus Asus Geforce 930M enabled system on Fedora 25. I install your driver and Nvidia GPU is working fine along with “nvidia-smi” from CUDA packages, other options never worked correctly. Now my X11 is on Nvidia GPU, I can see glxgears and everything performing excellent.

    Now when I use my laptop on Battery power, how do I switch to Intel Integrated Graphics on your drivers, switcheroo?

    Any pointers would be appreciated. Thanks in Advance.

    BTW, Great Work! on Fedora 25, nothing else works. Yours is just perfect.

    1. Now when I use my laptop on Battery power, how do I switch to Intel Integrated Graphics on your drivers, switcheroo?

      Unfortunately not, that’s limited by Nvidia design. With the Nvidia solution, both chipsets are always on unfortunately. The switcheroo part disappears the moment the nvidia kernel module is loaded. With Optimus enabled, the rendering is always done by the Nvidia chipset, so you can not switch off the discrete card if you don’t use it.

      1. Let me explain, I was on Ubuntu Optimus configuration the other day, you can prime-select to Intel, log out and log back in, and Intel drives the display, the Nvidia module is unloaded. I was looking for a similar solution in Fedora.

        For example, when I want to run CUDA apps, I will switch to Nvidia and system will load Nvidia Modules, when I just want lightweight usage, Intel GPU is fine. Eventhough Nvidia GPU is “powered on”, it will not perform any computation…

        I don’t want to turn either of them off…

        1. There is none like that. That is unsupported by both Nvidia and upstream X.org components, it does switch GL libraries on the fly etc. The correct implementation requires GLVND support (so GL libraries on demand) and plain RandR support with Sink offloading. The Ubuntu implementation uses an acpi module derived from Bumblebee that triggers a specific ACPI call per hardware module.

          In my latest job that very thing would actually break some systems up to the point that they required a hard reboot to revive the Nvidia card. Even going in the bios settings would not allow you to bring the card back to life.

          1. Thanks for the excellent info. Yes ubuntu has Nvidia Prime fork which allows to do so. I found this project to claim the same functionality, I haven’t tried it. I will give it a shot & will update.

            https://github.com/bosim/FedoraPrime

            Agreed, the enterprise systems shouldn’t toggle this thing on the fly. This is something which concerns more to personal user.

    2. Hey Subodh, I recently got a laptop with similar configs – asus geforce 940mx, installed fedora 25. I installed negativo’s drivers but X11 seems to be picking up intel, not nvidia gpu. Could you please tell me your xorg.conf file contents? Where could I be going wrong? I’d like to use gpu to render display as well as take tensorflow compute load. I

  47. Recent F26 (branched) mesa-libGL update is conflicting with /usr/lib64/libGLX_indirect.so.0 from nvidia-driver-libs – you’re probably already aware. Is this going to require a package update?

    1. Nevermind – I see the post below. I’m guessing the update hasn’t been pushed for devel repos yet. 🙂

Leave a Reply to Jeremy RimpoCancel reply