Nvidia driver, CUDA tools and libraries

nvidia-logo-1

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

Repository installation

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

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

To install the repository on CentOS/RHEL:

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

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

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

What’s different?

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

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

Nvidia drivers

Packaging

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

Versioning

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

CUDA support

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

Kernel modules

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

Default configuration

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

Kernel modesetting and Wayland support

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

Distribution and Nvidia driver version support

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

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

x86_64
aarch64		YesYesYes
Basic nvidia driver:

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

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

libnvidia-fbc		YesYesYes
Nvidia tools:

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

kmod-nvidia		YesNoNo
DKMS kernel
modules:

dkms-nvidia		YesYesYes
aKMOD kernel
modules:

akmod-nvidia		NoYesYes
32 bit compatibility on x86_64:

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

Optimus laptops

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

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

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

Everything else should not be different from your normal experience.

Limitations with the Nvidia driver

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

Limitations with the OSS stack

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

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

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

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

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

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

SLI systems

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

Nouveau fallback

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

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

Sample installation

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

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

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

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

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

Package installation

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

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

yum -y remove *nvidia*

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

yum -y install nvidia-driver nvidia-settings

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

dnf -y install nvidia-driver nvidia-settings

Specific driver installations

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

akmod kernel module variant (Fedora):

dnf -y install nvidia-driver akmod-nvidia

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

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

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

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

Proprietary and open source kernel modules

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

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

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

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

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

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

DKMS

Check which version you have installed:

# modinfo -l nvidia
NVIDIA

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

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

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

# modinfo -l nvidia
Dual MIT/GPL
# reboot

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

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

akmods

Check which version you have installed:

# modinfo -l nvidia
NVIDIA

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

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

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

# modinfo -l nvidia
Dual MIT/GPL
# reboot

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

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

Additional driver configuration to your system

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

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

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

Configuration for CUDA only systems

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

Option with only CUDA components installed

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

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

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

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

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

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

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

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

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

CUDA

Packaging

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

Distribution and CUDA version support

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

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

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

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

CUDA installations

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

yum -y install cuda nvidia-driver-cuda

To just install packages required for enabling CUDA development:

yum -y install cuda-devel

Or if you just want to enable everything:

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

A couple of examples. Just the basic tools:

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

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

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

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

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

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

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

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

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

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

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

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

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

Bugs

Just open an issue to the specific package on GitHub.

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

  1. I just followed your instructions to install nvidia using dkms, everything seem to have gone well but for not finding more than one monitor out of three and it threw an error in Xorg log saying not being able to find nv. Searching it manually shows none, what did I miss?

    BTW, it reports: nvidia, 367.35, 4.6.5-300.fc24.x86_64, x86_64: installed

    GLXGears work well, as well.

    Reply

    1. For actual bugs in the drivers you should report to the Nvidia forums. Regarding the nv driver, it has been obsoleted in Fedora 19 and by default X.org will try to use the nouveau (or modesetting) driver in case of Nvidia cards. But since you are using the proprietary driver you can ignore the message.

      Reply

  2. Does the driver include Vulkan headers so I can compile and link things using Vulkan? I haven’t found anything…

    Reply

    1. Nope, they are part of the Vulkan package. The Vulkan package is not yet part of Fedora but should be soon as the review has already been completed.

      Reply

  3. i dont understand why all your repos are insecure http & also on the same server, can you host the gpg keys on github? are you allowed to put a package into main fedora that simply contains the keys?

    Reply

    1. Hello, sorry for the late reply, the comment is not blocked, it was simply pending. The plan is to get everything in one repository as more and more things have dependency on each other, so the various names HandBrake, nvidia, cdrtools, etc. will go away. As part of that there will be a release package with the keys and the mirror urls. I already have a few mirror offers.

      As soon… as I have time 🙁

      Reply

      1. so you’re saying we just have to cross check from multiple connections at multiple times with multiple users & hope for the best?

        i just think it would be useful for now to manually mirror the .repo file & the keys on github/google/etc to minimize the effect of a MITM on the user that could have them installing a fake repo

        btw your instructions keep mentioning rpmfusion but not free vs nonfree

        Reply

  4. Hi Slaanesh,
    First of all, thanks for all your work on this repo. It has been by far the best nvidia driver solution for my fedora workstation(s) for years now.

    Just wondering if the Fedora 22 repo has been discontinued? The fedora-22 dir is now gone from the repo.

    Sorry if this was already announced somewhere and I missed it (I have had a look through the comments here and searched your blog posts by can’t find anything to that effect).

    Thanks!

    Reply

      1. Yeah, I normally leave the repository in place until the next push, in which case EOL distributions get deleted.
        Thanks for feedback!

        Reply

        2. Many thanks from here as well. We might plan in advance that fc24 is not “normal”, in the sense that nvcc — even in the Cuda 8 beta — does not play with fc24’s gcc 6.1. Has anyone here had success? I haven’t abandoned all hope of compiling cuda programs on fc24 with a local gcc 5.4 install, but at present have reverted back to fc23 — less proliferation of libraries. If Nvidia resolves their gcc 6.x issues before fc23 eol all will be good. If not, the easiest path may be to wait them out.

          Reply

          1. I haven’t tried CUDA 8 yet, so I don’t know its state. Do you have any pointers for new issues/features/things I should look for when packaging it?
            So far most of the (Fedora/RHEL) CUDA users I’ve seen are using CentOS and not Fedora. There works fine for everything.

  5. I am running a fresh install

    System: Kernel: 4.6.4-301.fc24.x86_64 x86_64 (64 bit) Desktop: Xfce 4.12.3
    Distro: Korora release 24 (Sheldon)
    Graphics: Card: NVIDIA GM107 [GeForce GTX 750 Ti]
    Display Server: Fedora X.org 118.4 drivers: nvidia (unloaded: fbdev,vesa,nouveau)
    Resolution: 1920×1080@60.00hz
    GLX Renderer: GeForce GTX 750 Ti/PCIe/SSE2 GLX Version: 4.5.0 NVIDIA 367.35

    I just installed with “dnf install nvidia-driver” out of negativo17.org repo

    Running xfdashboard
    libGL error: No matching fbConfigs or visuals found
    libGL error: failed to load driver: swrast
    [xcb] Unknown sequence number while processing queue
    [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
    [xcb] Aborting, sorry about that.
    xfdashboard: xcb_io.c:274: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost’ failed.
    Aborted (Speicherabzug geschrieben)

    locate swrast
    /usr/lib64/dri/kms_swrast_dri.so
    /usr/lib64/dri/swrast_dri.so
    /usr/lib64/gallium-pipe/pipe_swrast.so

    https://askubuntu.com/questions/541343/problems-with-libgl-fbconfigs-swrast-through-each-update

    I reinstalled nvidia-driver after kernel-update.

    glxgears is running with no problems.

    What to do to have xfdashboard?

    With Korora 23 most recent kernel and most recent nvidia-driver from negativo17.org xfdashboard had no problems.

    Please help.

    Thks
    AW

    Reply

    1. The problem is that xfdashboard uses /usr/lib64/libGL.so.1 while the proper symlink is /usr/lib64/libglvnd/libGL.so.1

      A workaround is to do this:

      env LD_PRELOAD="/usr/lib64/libglvnd/libGL.so.1" xfdashboard

      This is probably not Negativo’s fault but xfdashboard using a hardcoded path to the shared library.

      Reply

      1. Yes, that is the solution. It works. Thanks.

        On a native/original installation of Korora 24 XFCE with driver nouveau xfdasboard is running.

        Reply

  6. There appears to be some problem between mesa-libGLES and libglvnd on libGLESv2.so.2()(64bit). I haven’t yet installed the nvidia driver yet on my desktop, but I did enable the nvidia repo (as well as the multimedia repo) and did an update which upgrades gstreamer1-plugins-bad. This pulls in libglvnd rather than mesa-libGLES (as my laptop did) which breaks nouveau and leads to an oops screen. It complains about missing symbol _glapi_check_multithread. The goal is install the nvidia driver, but seems this strange intermediate state causes some problems. Just want to make you and others aware of this problem enabling the nvidia repo and the multimedia repo but not yet having the nvidia driver installed. To fix the problem I installed mesa-libGLES then removed libglvnd. Maybe this could be an explicit requires so it somehow prefers the mesa-libGLES package?

    Reply

    1. Hello, yes there is some cause/effect thing in place. First of all, gstreamer1-plugins-bad requires libGL and libEGL to be present:

      # rpm -q --requires gstreamer1-plugins-bad | egrep "libGL|libEGL"
libEGL.so.1()(64bit)
libGL.so.1()(64bit)
libGLESv2.so.2()(64bit)

      These in turn are offered by both mesa-libGL and mesa-libEGL. But if you have Nvidia driver repository enabled, they are provided by libglvnd; at least until Fedora base components will provide a libglvnd compatible mesa libGL. Those will take precedence, as if you have the Nvidia driver repository enabled this means you are actually asking for the driver. So, if you don’t need the driver, do not enable the repository for it.

      Otherwise, if you now want everything (Nvidia driver + CUDA + 32 bit GL support), just do a:

      dnf -y install kernel-devel dkms-nvidia nvidia-driver-cuda nvidia-driver-libs.i686

      and you should be good to go. Something similar to the GL thing is the libcuda.so.1 loading in FFMpeg:

      # rpm -q --whatrecommends nvidia-driver-cuda-libs
ffmpeg-libs-3.1.1-1.fc24.x86_64

      If you have the Nvidia repository enabled, then FFMpeg pulls in the “recommended” packages, otherwise it just skips them. So if you have the Nvidia driver repository enabled but you don’t want to use it, you will end up with unwanted components.

      Separate all these things is not easy, especially that now FFmpeg 3.1.1 can dynamic link CUDA libraries for the NPP acceleration (I haven’t enabled that yet). I might change it when merging all repositories together into 1. I will make an update on the repository page with the above details.

      Reply

  7. Hi,
    In my case you’re driver is the only working on a fresh install of F24 with 1080 cards…
    I tried RPMfusion / UnitedRPMs, with them i got the grey screen saying “oops something got wrong ….”

    Maybe someone can reply to that:
    1. How is that possible ?
    2. Can i stay with your drivers with a 90% chance they’ll don’t break (this is on production machines)
    3. I saw maybe I need to install the akamods but I don’t get a thing : with the “classic” non akmod driver if the kernel is updated do I get into trouble each times ?

    Reply

    1. Hello, good to hear that they work for you. For the answers:

      1. I don’t know, I don’t even know how they are packaged anymore
      2. Yes, they have been available for quite a few years now and if you look at the page there’s even the kind of version (long lived, short lived, beta) version that is supported on each distribution
      3. DKMS and akmods are just two variants of the same thing. It just happens that I’m also the Fedora/EPEL mantainer of DKMS, but that’s it. Feel free what you think is right for you.

      Reply

  8. Following my upgrade to Fedora 24 I have issued the command dnf repoquery –unsatisfied as recommended on site https://fedoraproject.org/wiki/DNF_system_upgrade to see if there are any old packages that should be removed because they would not be working properly anyway, and received the following messages which to me make no sense, unless I am completely misinterpreting the message.

    The kernel mentioned in the first message is the last of the Fedora 23 kernels that is still installed after the upgrade to F24, while the kernel listed in the 2nd message is the kernel installed by a sudo dnf upgrade issued the day after the upgrade to F24. Hence the bottom line is both kernels mentioned in the messages are installed, so why is dnf reporting that it can’t find them?

    package kmod-nvidia-4.5.7-200.fc23.x86_64-2:367.27-1.fc24.x86_64 requires kernel-uname-r = 4.5.7-200.fc23.x86_64, but none of the providers can be installed
    package kernel-4.6.3-300.fc24.x86_64 requires kernel-core-uname-r = 4.6.3-300.fc24.x86_64, but none of the providers can be installed

    Reply

    1. I got an X11 oops after upgrading my Fedora 23 system to Fedora 24. The nvidia driver wouldn’t load and it turned out that /lib/modules/4.6.3-300.fc24.x86_64/modules.dep wasn’t updated for the extra/nvidia drivers. I booted the Fedora 23 4.5 kernel, removed the kmod-nvidia-4.6.3-300.fc24.x86_64-367.27-1.fc24.x86_64 rpm and rebuild with akmods –kernels 4.6.3-300.fc24.x86_64. My next boot of the Fedora 24 kernel 4.6.3 worked fine. I don’t know why the modules.dep file wasn’t update properly. Thanks for all your work on creating the nvidia rpm packages.

      Reply

  9. Hello I installed a fresh Fedora 24 on a laptop with a Core I7 that has an integrated Intel graphics. And the laptop has a geforce 850m as well. So I enabled your repos and installed the drivers. It seems that nouveau is disabled automatically after installing nvidia drivers from your repo wich is great, I think. The nvidia modules are loaded and the display manager shows as normally. But when I try to log in, black screen and then it switchs back to the display manager. Any clues??

    Reply

  10. Fedora 24 using the 340 driver didn’t work. After investigation, module was not loaded.

    /var/cache/akmods/nvidia/340.96-3-for-4.6.3-300.fc24.x86_64.failed.log
    install: cannot stat ‘_kmod_build_4.6.3-300.fc24.x86_64/uvm/nvidia*.ko’: No such file or directory
    installed buildsys-build-rpmfusion-kerneldevpkgs-akmod-x86_64
    It now builds and loads on boot but all I get is a looping Nvidia logo.

    Have look further tomorrow.

    Reply

  11. After installing nvidia driver on my Fedora 24 installation, computer crashes with this message: “Wećome to emergency mode! …”

    Reply

  12. I have installed the 340 driver in fedora 24 MATE and I get a “failed to query glx server vendor” in the nvidia server settings. And of course i have no 3d acceleration.
    This is a great advance since the nvidia blob could not make a graphical start.
    Any ideas?

    Thanks very much for your help.

    Reply

  13. Hey,

    I am using Fedora 24 and your nvidia driver. I have an issue after about 5-10 minutes where the screen will disappear and show the boot log. If I then Ctrl+Alt+F2 I get back to the desktop and from there on in am good. I was using a 660 but yesterday got the 960 and both do exactly the same …

    Any help ?

    Thanks

    Reply

  14. Hello, thank you for the Nvidia drivers but I have a problem. I’m on Fedora 24, I installed the RPMFusion free and non-free repos. I installed “kernel-devel”, your repo and the drivers “$ sudo dnf config-manager –add-repo=”http://negativo17.org/repos/fedora-nvidia.repo” && sudo dnf install kernel-devel nvidia-driver dkms-nvidia nvidia-driver-libs.i686″. After a reboot that worked well but only for 5mn. After a few minutes the screen swicth to the tty ! I could go back to Gnome but the screen was corrupted and slow.

    I removed the drivers “sudo dnf remove \*nvidia\*” and I couldn’t boot anymore (black screen).

    I hope you can help me. Thanks !

    Reply

    1. I reinstall Fedora 24 and tried with “dnf install nvidia-driver akmod-nvidia kernel-devel” and it’s the same. After a few minutes the screen swicth to the tty ! The one where there is some boot infos.

      Reply

      1. For the nvidia drivers removing that produce a black screen it seems to be related to libglvnd that is not removed.

        Reply

          2. Yeah, I thought about it, but eventually this package would be replaced by an official one and there are plans to use it also on AMD Catalyst drivers, so I can’t make it require Nvidia drivers. Maybe I can add some weak requriments in the RPM package like the CUDA driver part for FFMPeg libraries?

          3. I don’t know how you can deal with this package but I know that if someone remove the nvidia driver he should not have a black screen 😀 It took me some time to find it was the culprit.

            If a weak requirement in the RPM package can avoid the black screen it’s ok. Maybe a little note should be add where you explain how to remove the driver to avoid more people having a black screen in the mean time ?

          4. Will do, you’re right. I don’t think the weak dependency would solve the issue.

      3. If you added RPMFusion, then those commands would install the RPMFusion version of the nvidia driver. AFAIK, the F24 repo for negativo17 still has some problems. It does not work with akmod-nvidia, and dkms-nvidia doesn’t actually install anything.

        Reply

        1. I’m using Fedora 24 like a lot of other people here, and it both works with akmods and DKMS packages.
          Did you follow the guide? Did you make sure that kernel-devel is installed and and not kernel-debug-devel as described in the instructions?

          There is only an issue after about 5-10 minutes where the screen will disappear and show the boot log, and you have to Ctrl+Alt+F2 to get back to the desktop. It’s not related to the Nvidia driver, it’s a bug in Gnome Shell which fix has not yet been ported to Fedora 24 packages:

          https://github.com/GNOME/gnome-shell/commit/5226d8b0864fa894f180b8584e837aaf565578b2
          https://bugzilla.gnome.org/show_bug.cgi?id=764898
          https://bugzilla.redhat.com/show_bug.cgi?id=1350184

          Reply

    2. I tried with the rpmfusion nvidia-driver and it’s the same. After a few minutes the screen swicth to the tty ! The one where there is some boot infos. journalctl show this, maybe that can help :

      https://pastee.org/npa7b

      Reply

  16. Hi,

    Thanks for the driver. Is it possible add in the nvidia.icd into /etc/OpenCL/vendors when installed to list the GPU as a OpenCL device?

    Reply

    1. Hello, it is already done, you need to install the nvidia-driver-cuda package:

      $ sudo dnf provides /etc/OpenCL/vendors/nvidia.icd 
nvidia-driver-cuda-2:367.27-1.fc24.x86_64 : CUDA integration for nvidia-driver
Repo        : fedora-nvidia

      It will also load the unified video memory module, etc…

      Reply

      1. Thanks for the quick reply! I somehow got into a state where I had the nvidia-opencl libraries but no .icd. It seems that those OpenCL libraries are loaded in with nvidia-driver-cuda-libs. I’ll keep that in mind for the future.

        Would it be better off moved it to an opencl package?

        Reply

  17. Hi,
    I still cannot get the Fedora 23 graphical boot logo after selecting the kernel to boot from, instead I get 3 different coloured horizontal bars at the bottom of the screen overlaying each other, that progress across the screen, to indicate boot progress. Playing around with GRUB_GFXPAYLOAD_LINUX doesn’t seem to impact this in any way. Is there something else I need to look at to resolve why this is happening with your drivers?

    Reply

    1. Just further to this. To try and test things out I uninstalled all the nvidia related packages that were installed except the nouveau xorg driver package. This broke xorg as the system was no longer able to start it, apparently because it could no longer find any screens.
      To work around this I booted with the rescue entry in grub, which booted with the graphical Fedora logo, which booted to a console login, but did not enable the network so I couldn’t run a dnf install to reinstall your nvidia drivers. To fix this issue I booted into another linux distro I have installed and manually downloaded the rpms to a directory on my Fedora root partition and did a manual install of all the ones that didn’t have dependency issues that could be resolved from the rescue environment.
      Having gotten the packages installed, which included kmod-nvidia and akmod-nvidia packages, when I booted into each of the existing kernels, the boot process did an akmod-nvidia build process, but could not start xorg until I did a subsequent reboot off that kernel, why was xorg not able to use the akmod built driver immediately?
      Having gotten the drivers back in and usable, the boot process has reverted back to not displaying the graphical boot logo that is displayed from the rescue boot, why is this the case?
      Also after getting the drivers reinstalled I ran a system update which installed a newer kernel. When I booted into the new kernel the akmod build did not take place, hence that process was able to use the kmod-nvidia driver, so why couldn’t the kernels that were already installed when I reinstalled the nvidia drivers able to use the kmod driver?

      Reply

  18. Having an issue getting the system to boot after installing the drivers on a fresh Fedora build. Only commands I ran after install were:

    dnf update
reboot
rpm -i rpmfusion-free-release-23.noarch.rpm
rpm -i rpmfusion-nonfree-release-23.noarch.rpm
dnf config-manager --add-repo=http://negativo17.org/repos/fedora-nvidia.repo
dnf install nvidia-driver
reboot

    After rebooting, the system hangs for a few seconds at “Starting switch root” and then crashes with the unrecoverable error screen. Uninstalling the drivers and re-enabling nouveau doesn’t seem to work either for some reason – getting the same crash. Any ideas on what’s wrong or how to fix this? Thanks.

    Reply

    1. In the instructions I wrote there’s written to install kernel-devel as well, but I don’t see it in your commands.
      I think it’s the usual problem with kernel-debug-devel providing kernel-devel, so you don’t have the correct headers installed. That’s a known bug in Fedora open since forever.

      Reply

  19. Your host is extremely slow. Have you considered using copr for this?

    All in all, amazing work. This repo has made my life running linux on Mac Pro much much simpler.

    Reply

    1. Would love to, but can not. Copr and official Fedora tools (Koji, etc.) can not be used for things that are in the list of forbidden items. So Nvidia drivers, cdrtools, all multimedia stuff, etc. They can’t serve but also can’t be used for building packages, so it’s a no go.

      Mirrors are welcome though 🙂

      Reply

      1. I wouldn’t be able to help with a mirror, but I would be happy to donate some $$$ to help you boost your capacity, if this is possible. It would be a small token of gratitude for all the effort you put into providing these packages. Have you considered something like this? Maybe others would jump in as well, and with small amounts from a lot of people, we could do something nice.

        Reply

        1. Thank you very much. That would be great. Actually in the main page there should be a button to donate through Paypal and a QR code for donating Bitcoins.
          If that is not the case… well, then I have a problem with WordPress 🙂

          Reply

          1. The button is there, don’t worry =) I must say I haven’t paid attention to it before, though. Anyway, I will stand by my offer and make a donation. After all, life on Fedora + Nvidia is *much* simpler thanks to your efforts.

            BTW negativo17.org/site/ returns a 404.

  20. On fedora 22 the nvidia samples do not build anymore (also tried on fedora 23 with the same result):

    make
make[1]: Entering directory '/usr/share/doc/cuda-samples/0_Simple/simpleTemplates'
/usr/bin/nvcc -ccbin g++ -I../../common/inc  -m64    -gencode arch=compute_20,code=sm_20 -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_52,code=compute_52 -o simpleTemplates.o -c simpleTemplates.cu
cc1plus: fatal error: cuda_runtime.h: No such file or directory
compilation terminated.
Makefile:229: recipe for target 'simpleTemplates.o' failed
make[1]: *** [simpleTemplates.o] Error 1
make[1]: Leaving directory '/usr/share/doc/cuda-samples/0_Simple/simpleTemplates'
Makefile:52: recipe for target '0_Simple/simpleTemplates/Makefile.ph_build' failed
make: *** [0_Simple/simpleTemplates/Makefile.ph_build] Error 2

    I could build gromacs using cuda but not the samples.
    Thanks

    Reply

    1. There’s a missing “-I /usr/include/cuda” somewhere, the cuda_runtime.h header is not in /usr/include folder or you will have headers everywhere. Will check if I can patch samples directly.

      Thanks for reporting.

      Reply

  21. Hi,
    I did a dnf update which install a new version of nvidia-driver but my system doesn’t work anymore and journalctl complains that the module nvidia could not be inserted. Weirdly enough the module has been built because I can see the file but modinfo nvidia throws an error after the first line (which shows the filepath). I check and it seems some version of packages are inconsistent 19-1 versus 19-2. Could this be the problem? Here is the list and I marked with an asterisk the affected packages:

    nvidia-driver.x86_64 2:364.19-2.fc22
    nvidia-driver-NVML.x86_64 2:364.19-2.fc22
    *nvidia-driver-NVML-devel.x86_64 1:352.79-1.fc22
    nvidia-driver-NvFBCOpenGL.x86_64 2:364.19-2.fc22
    nvidia-driver-cuda.x86_64 2:364.19-2.fc22
    nvidia-driver-cuda-libs.x86_64 2:364.19-2.fc22
    nvidia-driver-devel.x86_64 2:364.19-2.fc22
    nvidia-driver-libs.x86_64 2:364.19-2.fc22
    *nvidia-healthmon.x86_64 1:352.79-1.fc22
    *nvidia-libXNVCtrl.x86_64 2:364.19-1.fc22
    *nvidia-libXNVCtrl-devel.x86_64 2:364.19-1.fc22
    *nvidia-modprobe.x86_64 2:364.19-1.fc22
    *nvidia-persistenced.x86_64 2:364.19-1.fc22
    *nvidia-settings.x86_64 2:364.19-1.fc22
    *nvidia-validation-suite.x86_64 1:352.79-1.fc22
    *nvidia-xconfig.x86_64 2:364.19-1.fc22

    Thank you for your help

    Reply

    1. I think I found what the problem was. The modules are now compressed .ko.xz and my script that call sign-file to sign the modules for the secure boot was actually signing the compressed module which would make it unreadable. Unstead you need to uncompress the module by calling unxz then sign the .ko file and then compress it again by calling xy.

      (ps: I sent my initial post twice because I thought it failed but it was simply awaiting moderation, and I was on a different computer so I would not see it, sorry for this)

      Reply

      1. Thanks for letting me know. Would you mind sharing your script? Maybe I can create or provide some hook (and then instructions) for an easier signing of the modules once installed. Also, I’m about to trigger another update where I changed a bit the signing part.

        Reply

    2. I don’t see the kmod/akmod/dkms packages there… btw, the important part is satisfied by the dependencies; so unless you got a dependency error, you can be sure that the packages you have installed are correct.

      As written in the table here: https://github.com/negativo17/nvidia-driver
      you can see that versions for some components are different.

      Reply

  22. Hi,
    I updated to 364.19-2 but it doesn’t boot anymore. It seems there are some remaining 364.19-1 packages. In journalctl it complains that the nvidia module could not be inserted by modprobe. With modinfo the only things that works is modinfo -n nvidia but modinfo nvidia also throws an error.
    Do you know what is going on?
    What would be the command to rollback to 364.19-1 for all the installed packages from your repo?
    Thanks

    Reply

  23. Has anyone got this to work in fedora 24 (beta)?

    When I am trying to install nvidia-driver, it pulls in kernel-debug-devel 4.5.5-300.fc24, but the installed kernel is 4.5.6-300.fc24.x86_64.

    Also when I try to install kernel-devel it is version 4.5.5-300.fc24.

    When I go ahead and install anyway, I get the “Ooops, something went wrong” screen.

    Reply

    1. There is something wrong with the dependencies in the packages installed. To have the modules built you require matching kernel and kernel-devel packages.

      Reply

      1. Ok, yes. I will wait for the official f24 release and if the problem persists take it to askfedora. But it should work on f24 (provided I get the correct packages installed), correct?

        Reply

        1. Just happened here as well. The fedora-rpos package for Fedora 24 has been updated, disabling the updates testing repository. This lead to some packages installed which are not yet available in the released updates.

          Just run a dnf distro-sync or dnf --enablerepo=updates-testing update and you should be good to go.

          Reply

  24. I have run the rpm command and I only have the statements you have listed, which I am not surprised at as this is the first time I have ever installed these drivers. I didn’t know they existed until now.
    Is the GRUB_CMDLINE_LINUX statement in your script replacing the existing statement or inserting into the existing statement, as I have extra parameters on that statement that are not in your script.
    I had a similar problem when attempting to use the akmod drivers from rpmfusion which was resolved by using GRUB_GFXPAYLOAD_LINUX=keep, which seems to be ignored immediately upon using your drivers. It also doesn’t matter what I specify for this parameter the boot is always the same.
    It seems to me that from your script you are using grubby to generate grub.cfg and to update the mbr, is that correct, because if so it seems to me that you have the updating of /etc/defaul/grub and the execution of grubby in the wrong order in the script. Also I use grub2-mkconfig and grub2-install to create grub.cfg and to update the mbr, could that be causing an issue with your drivers?

    Reply

    1. Hello, sorry for the late reply.

      The settings used in Grubby and /etc/default/grub are totally independent. Grubby uses its own command line parameters and is used to modify the existing grub configuration file, while the latter is only used when you run grub2-mkconfig to overwrite completely the file.

      In fact at the beginning I was not even shipping the settings in /etc/default/grub.

      The parameters to GRUB_CMDLINE_LINUX are added, the whole variable is never replaced as people could have different settings like you.

      Reply

  25. I have just installed the kmod-nvidia packages into Fedora 23 and have now encountered a graphical boot issue. On a normal boot after selecting the grub boot menu entry the boot process would display a graphical boot Fedora logo for the length of the boot process. With your kmod drivers installed instead of the logo I get 3 different coloured thick lines overlaying each other at the bottom of the screen progressing across the screen to indicate boot progress. I have tried to play around with the GRUB_GFXPAYLOAD_LINUX option in /etc/default/grub but nothing I set makes any difference. I have made sure that after every change I update grub.cfg and update the mbr, but it always functions as if GRUB_GFXPAYLOAD_LINUX=text is set.
    Do you have any idea what in your drivers would be causing this or what I need to set in /etc/default/grub to get the standard Fedora Graphical Boot Screen back again?

    Reply

    1. I think you have some leftover from other installations, as I don’t disable the graphical boot up on installation. Check that you have only the lines listed in the scripts section of the nvidia-driver package:

      $ rpm -q --scripts nvidia-driver
postinstall scriptlet (using /bin/sh):
if [ "$1" -eq "1" ]; then
  /usr/sbin/grubby --update-kernel=ALL --args='nouveau.modeset=0 rd.driver.blacklist=nouveau nomodeset gfxpayload=vga=normal' &>/dev/null
  sed -i -e 's/GRUB_CMDLINE_LINUX="/GRUB_CMDLINE_LINUX="nouveau.modeset=0 rd.driver.blacklist=nouveau nomodeset gfxpayload=vga=normal /g' /etc/default/grub
fi || :
preuninstall scriptlet (using /bin/sh):
if [ "$1" -eq "0" ]; then
  /usr/sbin/grubby --update-kernel=ALL --remove-args='nouveau.modeset=0 rd.driver.blacklist=nouveau nomodeset gfxpayload=vga=normal' &>/dev/null
  sed -i -e 's/nouveau.modeset=0 rd.driver.blacklist=nouveau nomodeset gfxpayload=vga=normal //g' /etc/default/grub
fi ||:
      Reply

  26. Hi!
    There seems to be an error in package dkms-nvidia-364.19-1.fc23.x86_64.rpm. Module nvidia-uvm.ko is not being built, so opencl dependent programs fail to use opencl. It seems that in a file dkms.conf strings BUILT_MODULE_NAME and DEST_MODULE_LOCATION for “nvidia-uvm” and “nvidia-drm” have the same [number] field:

    BUILT_MODULE_NAME[2]="nvidia-uvm"
    DEST_MODULE_LOCATION[2]="/extra"

    BUILT_MODULE_NAME[2]="nvidia-drm"
    DEST_MODULE_LOCATION[2]="/extra"

    If [2] is changed to [3] for the “nvidia-drm”, all modules are built and installed without errors.

    Reply

  27. it’s working
    nvidia 10199040 106 nvidia_modeset,nvidia_uvm
    4.5.5-300.fc24.x86_64
    364.19-1.fc24

    Reply

  28. dnf install libglvnd-server-module.x86_64

    nothing provides libglvnd(x86-64) = 0.0.0-19.af2aeb0.fc23 needed by libglvnd-server-module-0.0.0-19.af2aeb0.fc23.x86_64

    Reply

    1. The server extensions has been superseded by a GLX extension. Since libglvnd 0.1.x and Nvidia drivers 364.x there is no more support for it.

      Reply

  29. Thanks for your wonderful nvidia repo in the first place!

    I found a little config oddity with the nvidia-driver-cuda-36x.xx-x.fc23.x86_64 RPMs. Both 361.42 and 364.19 are affected.

    You install
    /usr/lib/modules-load.d/nvidia-uvm.conf
    containing
    nvidia-uvm
    which itself depends on the central “nvidia” kernel module.

    Unfortunately this file gets included in initramfs.img.

    So systemd tries to load this very early from the initramfs. But it seems dracut is missing the information that it should include it there because systemd fails to load nvidia-uvm toggling away from the plymouth bootscreen and presenting the red [failed] message.

    Adding nvidia and nvidia-uvm to dracut.conf (or manually by calling dracut –add) fixes it.

    Don’t know how to handle that without including the huge nvidia.ko in the initramfs.

    The module gets loaded later anyway and everything works fine. But I don’t like “failed” messages in the boot sequence;-)

    Reply

    1. That’s really interesting, thanks for spotting. I will exclude all nvidia modules from initramfs.img (/usr/lib/dracut/dracut.conf.d/99-nvidia.conf).

      Thanks for notifying!

      Reply

  30. Nvidia driver 364.19 hangs my Fedora 23 installation. I’m using a fairly standard GTX-650 card and this keeps happening to me every once in a while. Some Nvidia drivers work like a charm, adapting perfectly to kernel updates, and then… boom! The frowning booting face. It keeps me on the edge because I never know when I’m going to lose my main working computer.

    Reply

  32. Are there plans to build the legacy 340 for Fedora 24? I do a daily use of an old notebook that still works great and it is running now F22.

    Reply

  33. Thanks for updating Fedora 23 to the 364.19 driver (works great). I was hoping to get vulkan support with the 364.19 driver, but maybe vulkan needs to packaged up separately first.

    Reply

  34. I recently found an issue with an updated tool in Fedora that seems to only happen with the nvidia driver, not with the nouveau driver.

    I am not playing any video games these days so it might be time to consider switching over to nouveau. Just posting this to see if there are any thoughts on this.

    I am using:
    nvidia-driver-340.96-1.fc23.x86_64

    My card:
    NVIDIA Corporation GT200 [GeForce GTX 260] (rev a1)

    I don’t have a pressing issue with the nvidia driver but the bug is with the new version of liveusb-creator which gives a segmentation fault. The Fedora devs don’t want to know about it since I am using the nvidia driver.

    Current reason for not switching to nouveau is that I can’t get the two GPU temperatures to show up when using it. I have a mostly default (tho I use Xfce) install on an old hard drive that I did the nouveau testing with.

    P.S. I don’t actually need the liveusb-creator since I can just use `dd` to create a bootable USB when needed.

    Reply

  36. akmod-nvidia-2:364.15-1.fc24.x86_64
    dkms-nvidia-2:364.12-1.fc24.x86_64

    Please update dkms-nvidia to match. It’s currently unusable because no other 364.12 dependencies exist. Thanks!

    Reply

  38. With stable 364.19 being released this week, are you considering updates Fedora 23 to the 364.19 driver version?

    Reply

  39. fedora 23 with NVS 5400M
    dnf complain
    /sbin/ldconfig: /usr/lib64/nvidia/libEGL.so.1 is not symbolic link

    lrwxrwxrwx. 1 root root     16  1 avril 09:04 libEGL.so -> libEGL.so.346.46
-rwxr-xr-x. 1 root root  14368 23 mars  01:24 libEGL.so.1
-rwxr-xr-x. 1 root root 952704 18 févr.  2015 libEGL.so.346.46

    must be changed??

    Reply

    1. Nvidia drivers override base Mesa EGL libraries, even with GLVND:

      $ ldconfig -p | grep EGL
        libEGL_nvidia.so.0 (libc6,x86-64) => /lib64/libEGL_nvidia.so.0
        libEGL_nvidia.so.0 (libc6) => /lib/libEGL_nvidia.so.0
        libEGL.so.1 (libc6,x86-64) => /usr/lib64/nvidia/libEGL.so.1
        libEGL.so.1 (libc6,x86-64) => /lib64/libEGL.so.1
        libEGL.so.1 (libc6) => /usr/lib/nvidia/libEGL.so.1
        libEGL.so.1 (libc6) => /lib/libEGL.so.1

      And in both Mesa and Nvidia cases, the EGL library is always a symlink, don’t know where you got that library from. ldconfig is complaining that you have a library with the SONAME it should create a link for as a physical file.

      Fedora 23 has drivers 361.42 in the repos, not 346.46, and the links/libraries are fine, so you are asking for help on your setup which has nothing to do with what I ship.

      Reply

  40. Hello! I’m having problem with installing nvidia-driver. First I uninstalled everything with:
    dnf remove *nvidia*

    Then installed with:
    dnf install nvidia-driver

    After installation I got this error:
    systemd-modules-load[219]: Failed to find module ‘nvidia-uvm’

    So I uninstalled kmod-nvidia* and akmod-nvidia* and installed akmod-nvidia again. Then build it again with akmods –force.

    And now I see this in lsmod|grep nvidia.
    nvidia_modeset 741376 7
    nvidia_uvm 561152 0
    nvidia 10014720 141 nvidia_modeset,nvidia_uvm
    drm 335872 6 nvidia

    But I’m still getting error mentioned above. Can anybody help me?

    Reply

      1. Situation is getting weirder. After uninstalling everything nvidia driver related I’m still getting this error
        systemd-modules-load[219]: Failed to find module ‘nvidia-uvm’
        When I try to install nvidia-driver again. I’m ending with blinking boot screen. This is part of the Xorg.0.log:

        [ 58.838] (II) LoadModule: “nvidia”
        [ 58.838] (II) Loading /usr/lib64/xorg/modules/drivers/nvidia_drv.so
        [ 58.838] (II) Module nvidia: vendor=”NVIDIA Corporation”
        [ 58.838] compiled for 4.0.2, module version = 1.0.0
        [ 58.838] Module class: X.Org Video Driver

        And later on there is this in log:
        [ 58.839] (EE) NVIDIA: Failed to initialize the NVIDIA kernel module. Please see the
        [ 58.839] (EE) NVIDIA: system’s kernel log for additional error messages and
        [ 58.839] (EE) NVIDIA: consult the NVIDIA README for details.

        Reply

        1. Ok, I don’t know what happened. But the driver is working again.
          This is what I did:
          rm -rf /lib/modules/$(uname -r)/extra

          At this location I found nvidia.ko, nvidia-uvm.ko and nvidia-modeset.ko.

          Then I edited /lib/modules/$(uname -r)/modules.dep and deleted lines with above kernel objects

          After this I installed nvidia driver again from your repository and everything looks good.

          Maybe this will help someone in future.

          Reply

          1. I’ve got the same problem from kernel 4.4.6-301 onward. I don’t know what’s going on. Does it mean it can’t use Kernel Modesetting with this version?

    1. Updated the Fedora 24 repository. Remember that 364.12 is beta. Wayland support is not finished, specific Nvidia patches have been rejected upstream and KMS does not work properly on every hardware.

      Reply

        1. Haven’t tested it yet… Unfortunately I don’t have an Optimus laptop anymore. Judgning from the Nvidia notes on their forum not much has changed for Optimus laptops.

          Reply

      2. Hi!

        As rpmfusion doesn’t provide FC24 packages for akmods and kmodtool, I had to build both packages from SRPMs. However, installing nvidia-driver and akmod-nvidia always resulted in installing kmod-nvidia, too.

        Right now, booting into gdm doesn’t work, as I’m stuck on the Fedora Plymouth logo. Removing kmod-nvidia and rebuilding akmod-nvidia also doesn’t seem to help.

        Is installing the dkms-nvidia RPM instead of the akmod-nvidia RPM in your repo an option? I couldn’t test it because right now there seems to be some version conflict (dkms-nvidia-364.12 vs nvidia-driver-364.15).

        GPU is NVIDIA GTX 970.

        Reply

  42. Hello! Thanks for the repo. I’m using Fedora 23, MATE spin. After hours installing and reinstalling these packages and those on rpmfusion, I finally have the nvidia driver working. The solution for me was embarrassingly simple: enter BIOS, disable ‘fast boot’ and ‘UEFI secure boot’. Now I can play Portal 2, wahey.

    Slaanesh, please could you add “disable UEFI secure boot” to instructions above? It wasn’t obvious to me. As I understand, secure boot requires kernel modules be signed, which isn’t the case for the modules in this repo or any home baked with akmod.

    Here’s what else I learnt:

    1. You really don’t need an xorg.conf . Creating one with nvidia-xconfig will only mean X crashes if the driver isn’t available, rather than fallback to low resolution.
    2. As explained above, to play 32 bit games (as on Steam), you need to install the nvidia-driver-libs.i686 package . Otherwise you’ll see an error “OpenGL GLX context is not using direct rendering, which may cause performance problems.” You can test 32-bit direct rendering with the command `glxinfo32 | grep “direct rendering”`
    3. glxgears and glmark2 are useful benchmarks. My glmark2 score increased hundredfold from 140 to 14000 after installing driver.

    Debugging guide I would have found useful:

    1. Delete rhgb (graphical boot) from grub.cfg
    2. Check lsmod lists nvidia module
    3. Which logs to check if it doesn’t.

    Thanks again.

    Reply

    1. Thanks for the suggestion, the information has been added to the installation section, with also a link for signing your own modules.

      Reply

  43. Nvidia drivers doesn’t work with the newest kernel, as of today version 4.4.3-300.fc23.x86_64…

    Reply

  44. Hi,

    It seems on cuda-samples package there are hardcoded paths that make all compilations fail:

    For example, in:
    /usr/share/doc/cuda-samples/5_Simulations/smokeParticles

    make yields:

    “/home/slaanesh/rpmbuild/SOURCES/cuda/cuda-7.5.18-x86_64″/bin/nvcc -ccbin g++ -I../../common/inc -m64 -gencode arch=compute_20,code=sm_20 -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_52,code=compute_52 -o GLSLProgram.o -c GLSLProgram.cpp
    /bin/sh: /home/slaanesh/rpmbuild/SOURCES/cuda/cuda-7.5.18-x86_64/bin/nvcc: El fitxer o directori no existeix
    Makefile:243: recipe for target ‘GLSLProgram.o’ failed

    The hardcoded path is on CUDA_PATH variable, at the beggining of the Makefile:
    # Location of the CUDA Toolkit
    CUDA_PATH ?= “/home/slaanesh/rpmbuild/SOURCES/cuda/cuda-7.5.18-x86_64”

    Reply

    1. Thanks for notifying, there was a mistake in the makeself files from Nvidia were extracted. To tell the truth I never tried building the samples, only external programs.
      If you need to fix them immediately, you can just call the Makefiles like this:

      CUDA_PATH=/usr make

      Fixed packages are building; they will be uploaded in a few minutes.

      Reply

      1. Thanks for the hotfix and the kick fix, already built stuff wuth CUDA. I was checking the samples cause I was having issues with Tensorflow and wanted to check if everything was OK.

        Reply

    1. You would need a separate repo then. 355.00.28 is older than 361.28. It will be included by default in 364.x or whatever.
      As with previous OpenGL releases, Nvidia adds the feature to some older driver so not everyone will jump on it.

      Reply

  46. Hello, I am sorry, but I encountered a problem with your version of the 361.28 driver. After install the driver from your repo, some of the Steam games began to crash. Dota 2 crashed with error “Missing basic OpenGL v1.0 -> v2.0 required OpenGL functionality.”, other Valve games CS, HL2… ended with message “Could not find required OpenGL entry point ‘glGetError’! Either your video card is unsupported or your OpenGL driver needs to be updated.}}”. 32Bit libs where of-course installed.
    I followed workarounds described in wiki.archlinux.org/index.php/Steam. I also tried to deflect libs from Steam runtime-libs (via. /etc/ld.so.conf.d/steam.conf ldconfig….) all without any success.
    After uninstall the your driver and install it from default run file downloaded from nvidia.com all games began to work properly.
    I am using F23 x64, KDE, GTX960, dualmonitor.

    Reply

    1. Unfortunately yes, this is due to some executables accessing non OpenGL ABI compliant stuff in the libGL.so.1 library, which are not exposed by libglvnd. I’ve reverted to the non-glvnd libGL.so.1 library as per Nvidia installer’s default:

      https://devtalk.nvidia.com/default/topic/915640/unix-graphics-announcements-and-news/multiple-glx-client-libraries-in-the-nvidia-linux-driver-installer-package/

      The latest nvidia-driver* packages should fix the issue.

      Reply

  47. Think there’s a problem with the latest nvidia-driver-libs.

    old install:
    # tree /lib*/nvidia
    /lib64/nvidia
    ├── [ 260 May 20 2014] alternate-install-present
    ├── [ 16 Nov 18 13:23] libEGL.so.1 -> libEGL.so.340.96
    ├── [ 965K Nov 9 2:05] libEGL.so.340.96
    ├── [ 22 Nov 18 13:23] libGLESv1_CM.so.1 -> libGLESv1_CM.so.340.96
    ├── [ 47K Nov 9 2:05] libGLESv1_CM.so.340.96
    ├── [ 19 Nov 18 13:23] libGLESv2.so.2 -> libGLESv2.so.340.96
    ├── [ 61K Nov 9 2:05] libGLESv2.so.340.96
    ├── [ 15 Nov 18 13:23] libGL.so.1 -> libGL.so.340.96
    ├── [ 1.2M Nov 9 1:05] libGL.so.340.96
    ├── [ 18 Nov 18 13:23] libOpenCL.so.1 -> libOpenCL.so.1.0.0
    ├── [ 21K Nov 9 1:20] libOpenCL.so.1.0.0
    └── [ 4.0K Jan 25 0:58] xorg
    └── [ 13M Nov 9 1:09] libglx.so
    /lib/nvidia
    ├── [ 16 Nov 18 13:21] libEGL.so.1 -> libEGL.so.340.96
    ├── [ 647K Nov 9 2:12] libEGL.so.340.96
    ├── [ 22 Nov 18 13:21] libGLESv1_CM.so.1 -> libGLESv1_CM.so.340.96
    ├── [ 42K Nov 9 2:11] libGLESv1_CM.so.340.96
    ├── [ 19 Nov 18 13:21] libGLESv2.so.2 -> libGLESv2.so.340.96
    ├── [ 58K Nov 9 2:11] libGLESv2.so.340.96
    ├── [ 15 Nov 18 13:21] libGL.so.1 -> libGL.so.340.96
    ├── [ 1.0M Nov 9 1:11] libGL.so.340.96
    ├── [ 18 Nov 18 13:21] libOpenCL.so.1 -> libOpenCL.so.1.0.0
    └── [ 21K Nov 9 1:25] libOpenCL.so.1.0.0

    Latest:
    # tree /lib*/nvidia
    /lib64/nvidia
    ├── [ 260 May 20 2014] alternate-install-present
    ├── [ 18K Feb 3 18:09] libEGL.so.1
    ├── [ 18 Feb 9 17:46] libOpenCL.so.1 -> libOpenCL.so.1.0.0
    ├── [ 26K Feb 3 18:15] libOpenCL.so.1.0.0
    └── [ 4.0K Feb 15 20:52] xorg
    └── [ 12M Feb 3 18:14] libglx.so
    /lib/nvidia
    ├── [ 14K Feb 3 18:12] libEGL.so.1
    ├── [ 18 Feb 9 17:42] libOpenCL.so.1 -> libOpenCL.so.1.0.0
    └── [ 26K Feb 3 18:18] libOpenCL.so.1.0.0

    Appears we’re missing a pile of files all of a sudden.

    Reply

    1. Actually you should do rpm -ql libglvnd nvidia-driver-libs, and not check the nvidia folder. The Nvidia labeled folder contains only the overrides to equally named system libraries; most of the libraries now have unique names.

      The libglvnd package is a placeholder that has been put in place until the base OS catches up (Mesa, etc.), so for now it’s still overriding the base libraries.

      If you want more details:
      https://devtalk.nvidia.com/default/topic/915640/unix-graphics-announcements-and-news/multiple-glx-client-libraries-in-the-nvidia-linux-driver-installer-package/

      Last question, are the packages working for you? They should pull in the libglvnd packages as a dependency.

      Reply

  48. First off, everything has been working great, I really like this repository and prefer it to the packaged binary that NVIDIA distributes.

    I recently moved from Fedora 22 to Fedora 23, and now whenever I log in my NVIDIA settings are ignored. I’ve successfully added a section to my /etc/X11/xorg.conf.d which I generated with sudo nvidia-settings, so when I get the actual login screen on first boot both monitors are on in the proper layout. When I log into my user account the main monitor turns OFF and I am with just the second monitor enabled. I can open nvidia-settings again and fix them, but if I alt-f2 -> r -> enter and restart my gnome session the monitor settings immediately jump back to just one monitor.

    Reply

    1. If anyone else is experiencing a similar problem, it has nothing to do with the NVIDIA drivers. You just need to delete ~/.config/monitors.xml and the problem should go away. Alt-F2 -> r -> enter to reset gnome session and verify.

      Reply

  50. I installed Fedora 23. Updated it, add your repo and then installed nvidia-driver but now i get

    “Oh! Something has gone wrong”

    When trying to boot up GNOME. What might be?

    I have a ASUS 970, Intel Core i5 2500K, 16 Gigs of RAM and a ASUS P8Z68-V PRO.

    Thanks.

    Reply

Leave a Reply