Nvidia driver

Oh no, another Nvidia driver repository? Why?

This driver 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.

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.

Here is a list of all the “differences” from the various Nvidia driver packages that I was able to spot on the web.


  • nvidia-settings, nvidia-persistenced, nvidia-xconfig and nvidia-modprobe are compiled from source.
  • CUDA libraries and tools 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 ~100 MB worth of installed libraries. nvidia-persistenced falls in this category as it’s not neeeded on a normal laptop or gaming system.
  • 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.
  • 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.
  • 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.
  • 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!
  • armv7hl support is included in Fedora 20+ packages.
  • 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 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”
  • 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; 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 based on drivers version 165.

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.
  • Starting of drivers version 331.17, the kernel module packages contain the main Nvidia kernel module (nvidia.ko) but also the Unified Memory kernel module and support for multiple kernel modules as specified by the Nvidia documentation. These are optional and can be configured manually for CUDA enabled systems that need to address a specific GPU or to share memory between the CPU and GPU in CUDA programs.
  • When building instantiated kernel modules; both akmod and dkms packages can be configured to build the additional modules instead of the single one, so you can still choose your preferred method.
  • Starting from Nvidia driver version 334.16, the Nvidia DDX driver for X no longer loads the kernel module internally but relies on the nvidia-modprobe command in the system, so a new dependency has been added. Apparently this is not yet true, because the libraries try to load the kernel modules also with the system modprobe command if available.

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.

Here is an example on my Fedora laptop at work:

 Package                 Arch        Version                Repository     Size
 dkms-nvidia             x86_64      2:331.20-2.fc20        fedora-nvidia 3.1 M
 nvidia-driver           x86_64      2:331.20-2.fc20        fedora-nvidia 2.3 M
 nvidia-driver-libs      i686        2:331.20-2.fc20        fedora-nvidia 7.6 M
Updating for dependencies:
 nvidia-settings         x86_64      2:331.20-2.fc20        fedora-nvidia 751 k
 nvidia-driver-libs      x86_64      2:331.20-2.fc20        fedora-nvidia 7.6 M
 nvidia-libXNVCtrl       x86_64      2:331.20-2.fc20        fedora-nvidia  19 k
Transaction Summary
Install             ( 3 Dependent packages)
Upgrade  3 Packages (+3 Dependent package)
Total download size: 20 M
Is this ok [y/d/N]:

As you can see, this system has dkms enabled kernel module 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. And no nvidia-persistenced or multiple kernel modules.

All packages have Epoch set to 2; so they should never be upgraded on your system when you enable this repository along the RPMFusion or ELRepo ones.

Here is a rundown of Nvidia supported drivers and options split by distribution:

Operating system
f19 / f20
el7 / f21
Driver version331.67334.21337.12
i686 (only libs in el7)
Basic nvidia drivernvidia-driver
CUDA libraries and toolsnvidia-driver-cuda
OpenGL Framebuffer Capturenvidia-driver-NvFBCOpenGLnvidia-driver-NvFBCOpenGLnvidia-driver-NvFBCOpenGL
Nvidia toolsnvidia-settings
Binary kernel
module (kABI)
DKMS kernel
AKMOD kernel

akmod-nvidiaakmod-nvidia (f21 only)
32 bit compatibility
on x86_64

Please note that I’ve not tested the ARM builds as I don’t own any hardware that I can test on. Probably there’s some adaptation required to the %post/%postun sections in the nvidia-driver package. Any feeedback is much appreciated.

Repository installation

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

wget http://negativo17.org/repos/fedora-nvidia.repo -O

To install the repository on CentOS/RHEL:

wget http://negativo17.org/repos/epel-nvidia.repo -O

Package installation

First of all remove all the Nvidia drivers you might have on your sistem due to RPMFusion or EPEL. The packages should already take care of this for you, but better be safe than sorry. This is usually accomplished with the following root command:

yum -y remove \*nvidia\*

Then, to install the nvidia-driver packages in Fedora or CentOS/RHEL, perform the following command:

yum -y install nvidia-driver

Specific package 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 RPMFusion repository enabled if you plan to use AKMOD kernel modules:

yum -y install nvidia-driver akmod-nvidia

To install in CentOS/RHEL with the binary kABI (Kernel ABI whitelist) module:

yum -y install nvidia-driver kmod-nvidia

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

yum -y install nvidia-driver-libs.i686

To use the Nvidia driver with the DKMS enabled kernel module (on CentOS/RHEL it requires the EPEL repository being enabled):

yum -y install nvidia-driver dkms-nvidia

To install CUDA support:

yum -y install nvidia-driver-cuda

To install CUDA 32 bit support on a 64 bit system:

yum -y install nvidia-driver-cuda-libs.i686

Enabling multiple (instantiated) kernel modules

Version 325 and newer of the drivers support multiple kernel modules for driving multiple GPUs in a single system. According to the documentation; this helps when separate GPUs are intended to process independent workloads in a single system.

Multiple kernel modules are supported on the DKMS and aKMOD variant of the kernel packages. Binary kMOD packages are not generated for RHEL/CentOS as the required kernel symbols are not inserted in the package at build time and would result in a ~100 mb download of kernel modules even if the system is used for normal desktop usage.

aKMOD support

To enable building your aKMOD package with support for multiple kernel modules, as root create the /etc/rpm/macros.nvidia file with the following contents:

echo "%_nv_build_module_instances 8" > /etc/rpm/macros.nvidia

By changing the number in the macro, you can have your desired number of multiple kernel modules (up to 8). This is taken from the default RPMFusion package behaviour for the exception that the original nvidia.ko and nvidia-uvm.ko modules are not built due to compatibility with the multiple kernel modules variant.

To rebuild the kernel module package, remove the current kmod-nvidia-kernel_version package and rebuild it with the following root command:

akmods --force

To revert to the single kernel module just remove the /etc/rpm/macros.nvidia file.

DKMS support

Enabling your DKMS setup to build multiple kernel modules requires you to create the /etc/dkms/nvidia.conf configuration file that contains overrides for the default DKMS configuration recipe. As root, perform the following command using the driver version as appropriate:

cp /usr/src/nvidia-<version>/dkms-nvidia-multi.conf /etc/dkms/nvidia.conf

By editing the file, you can have your desired number of multiple kernel modules (up to default of 8). To reduce the number of modules, just remove the extra lines; the file is pretty self explanatory. The file takes care of not building the nvidia.ko and nvidia-uvm.ko modules; due to compatibility with the multiple kernel modules variant.

To rebuild the kernel modules, rebuild them with the following root command:

dkms install -k <kernel_version> -m nvidia -v <version> --verbose

To revert to the single kernel module just remove the /etc/dkms/nvidia.conf file.


The address for contacting me is in the package’s changelog.

25 Responses so far...

  1. piruthiviraj says:

    Do you have any plans to support bumblebee?

    • slaanesh says:

      I personally think Bumblebee is a hack. I support the official Nvidia implementation (i.e. X.org configuration) or the fully open Prime solution.

  2. sdch says:

    akmod needs kernel-devel package which has to be installed seperately. please include this also in above instructions..

    • slaanesh says:

      akmods already requires the latest kernel-devel package; there’s nothing to be installed separately. You can check by running rpm -q --requires akmods.

  3. Padraic says:

    I’m probably missing something obvious but will this support Optimus cards and allow switching / powering off and using external monitors?

    • slaanesh says:

      It’s written in the page, if you use the OpenSource (intel and nouveau) drivers and kernel 3.12+, dynamic power on/off of the cards works out of the box. The card of course will not power off if you’re using the external monitor.

  4. OCosta says:

    I just installed F20 and for some reason Nvidia drivers are not working. I followed the steps described above and boot happens just fine, but I get stuck at the console, graphics mode doesn’t kick in. Things were working just fine on F19 a couple of minutes ago. Any tips on what could be wrong? My card is a GT9800.

    BTW: thks for the great work! =)

    • slaanesh says:

      That’s strange. You can check for the following things:

      - /boot/grub2/grub.cfg contains the required strings (nouveau.modeset=0, etc.)
      - The kernel modules have been compiled correctly (kmod-nvidia[...] in case of aKMODs, modules under /lib/modules/kernel-/extra in case of DKMS)
      - An almost barebone X.org config file in /etc/X11/xorg.conf that loads the Nvidia driver.

      Also depending on how fast your system is, leave some minutes to compile the modules. I’m about to push an update with driver version 331.38 that splits the multiple Nvidia kernel modules from the single one thus speeding up module assembly.

      • Samir says:

        I also tryied installing everything following your instructions, i have made a picture of where the boot is stuck at:

        I also checked everything from your answer to OCosta and everything seems fine.

        I’ve got an Acer 5742G with GT540M and external monitor on HDMI.

      • OCosta says:

        Thks for your help. I found out what was wrong, after a little googling around: kernel-devel package was not installed, and for some reason this breaks akmods builds. After installing it, I successfully booted into graphics mode with Nvidia driver =)

        Maybe kernel-devel should be a dependency for akmod-nvidia?

        • slaanesh says:

          Strange you don’t have it installed. Actually the kernel-devel package is a requirement of the akmods package:

          $ rpm -q --requires akmods | grep kernel

          If this has not worked for you, you should open a bug against akmods in RPMFusion’s bugzilla.

  5. Mikey says:

    I have this weird situation (that I’ll admit I haven’t fully debugged yet) With the nvidia package from nvidia.com everything works.

    After installing your drivers (and reinstall xorg and various other things) I can log in if I init 3, startx. But the gdm menu either doesn’t come up or when it does logging in as a user gets a bunch of white boxes or full white screen. Any ideas where to start looking?

  6. DevNull says:

    When installing 32-bit Nvidia libraries for RHEL 7 beta there is a missing dependancy for libvdpau(x86-32). This is a problem since RHEL7 only have x86_64 versions. (No i686 RHEL 7).

    How can i solve this?

  7. Mark T. Kennedy says:

    i’m using an old quadro nvs card to drive four displays via xinerama (no twinview at all). i’m using the rpmfusion driver setup. lately i’ve run into a bizarre problem where the display locks (while displaying vibrating patterns) and then often triggers a crash/reboot. the logs are devoid of anything interesting or useful. i’m interested in trying your setup. is it safe and easy to switch back & forth between rpmfusion and your setup? will my xorg.conf file get clobbered/rewritten?

    • slaanesh says:

      Hello, it’s easy to switch back and forth using akmod, just backup your xorg.conf file:

      cp /etc/X11/xorg.conf /etc/X11/xorg.conf.working
      yum -y remove \*nvidia\*
      yum -y install nvidia-driver
      cp -f /etc/X11/xorg.conf.working /etc/X11/xorg.conf

      But if your problem is due to the binary driver; unless you change the driver itself there will probably be no benefit. If the versions I’m hosting are the same as RPMFusion ones, then you will have the same problems for sure.

  8. Paulo Fessel says:

    These drivers are definitely a no-go for me. Whenever I enable them I won’t get OpenGL on KWin (native or rasterized). Returning to rpmfusion drivers (even the rpmfusion-nonfree-testing ones) solves the problem for me. Fedora 20 with the latest packages installed on an x86_64 machine.

  9. With this version of the drivers, whenever I enable kwin’s composition effects I get a segmentation fault:

    Application: KWin (kwin), signal: Segmentation fault
    Using host libthread_db library "/lib64/libthread_db.so.1".
    [Current thread is 1 (Thread 0x7f80f1966900 (LWP 6300))]

    Thread 2 (Thread 0x7f80e490f700 (LWP 6318)):
    #0 0x0000003a5dc0c0c9 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
    #1 0x0000003a6be7c8b4 in QWaitCondition::wait(QMutex*, unsigned long) () from /lib64/libQtCore.so.4
    #2 0x0000003a6be6f99d in QThreadPoolThread::run() () from /lib64/libQtCore.so.4
    #3 0x0000003a6be7c3af in QThreadPrivate::start(void*) () from /lib64/libQtCore.so.4
    #4 0x0000003a5dc07f33 in start_thread () from /lib64/libpthread.so.0
    #5 0x0000003a5d0f4ded in clone () from /lib64/libc.so.6

    Thread 1 (Thread 0x7f80f1966900 (LWP 6300)):
    [KCrash Handler]
    #5 0x0000000000000000 in ?? ()
    #6 0x0000003a85e141e8 in KWin::GLShader::GLShader(QString const&, QString const&, unsigned int) () from /lib64/libkwinglutils.so.1
    #7 0x0000003a85e146cf in KWin::ShaderManager::initShaders() () from /lib64/libkwinglutils.so.1
    #8 0x0000003a85e148e0 in KWin::ShaderManager::instance() () from /lib64/libkwinglutils.so.1
    #9 0x0000003a862e48c5 in KWin::SceneOpenGL2::SceneOpenGL2(KWin::OpenGLBackend*) () from /lib64/libkdeinit4_kwin.so
    #10 0x0000003a862e4e5b in KWin::SceneOpenGL::createScene() () from /lib64/libkdeinit4_kwin.so
    #11 0x0000003a862c8355 in KWin::Compositor::slotCompositingOptionsInitialized() () from /lib64/libkdeinit4_kwin.so
    #12 0x0000003a862c8705 in KWin::Compositor::setup() [clone .part.76] () from /lib64/libkdeinit4_kwin.so
    #13 0x0000003a862c8aa5 in KWin::Compositor::slotConfigChanged() () from /lib64/libkdeinit4_kwin.so
    #14 0x0000003a8624c12d in KWin::Compositor::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) [clone .part.73] () from /lib64/libkdeinit4_kwin.so
    #15 0x0000003a6bf98cf8 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /lib64/libQtCore.so.4
    #16 0x0000003a8625cb1f in KWin::Workspace::slotReconfigure() () from /lib64/libkdeinit4_kwin.so
    #17 0x0000003a8625d145 in KWin::Workspace::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) [clone .part.157] () from /lib64/libkdeinit4_kwin.so
    #18 0x0000003a6bf98cf8 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /lib64/libQtCore.so.4
    #19 0x0000003a6bf9d0a1 in QObject::event(QEvent*) () from /lib64/libQtCore.so.4
    #20 0x00000037b45c9d8c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib64/libQtGui.so.4
    #21 0x00000037b45d0725 in QApplication::notify(QObject*, QEvent*) () from /lib64/libQtGui.so.4
    #22 0x0000003a8404ab0a in KApplication::notify(QObject*, QEvent*) () from /lib64/libkdeui.so.5
    #23 0x0000003a6bf8439d in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /lib64/libQtCore.so.4
    #24 0x0000003a6bfb5ae3 in QTimerInfoList::activateTimers() () from /lib64/libQtCore.so.4
    #25 0x0000003a6bfb6548 in QEventDispatcherUNIX::processEvents(QFlags) () from /lib64/libQtCore.so.4
    #26 0x00000037b466c5d6 in QEventDispatcherX11::processEvents(QFlags) () from /lib64/libQtGui.so.4
    #27 0x0000003a6bf82edf in QEventLoop::processEvents(QFlags) () from /lib64/libQtCore.so.4
    #28 0x0000003a6bf8322d in QEventLoop::exec(QFlags) () from /lib64/libQtCore.so.4
    #29 0x0000003a6bf88749 in QCoreApplication::exec() () from /lib64/libQtCore.so.4
    #30 0x0000003a8627e411 in kdemain () from /lib64/libkdeinit4_kwin.so
    #31 0x0000003a5d021d65 in __libc_start_main () from /lib64/libc.so.6
    #32 0x0000000000400a01 in _start ()

    Looking into Xorg.0.log I see this:

    [ 210.606] (EE) NVIDIA(0): Failed to initialize the GLX module; please check in your X
    [ 210.606] (EE) NVIDIA(0): log file that the GLX module has been loaded in your X
    [ 210.606] (EE) NVIDIA(0): server, and that the module is the NVIDIA GLX module. If
    [ 210.606] (EE) NVIDIA(0): you continue to encounter problems, Please try
    [ 210.606] (EE) NVIDIA(0): reinstalling the NVIDIA driver.

    Comparing with Xorg.1.log I still have (I use two cards here), I see that the glx driver being loaded is not NVidia’s but Xorg’s:

    [ 640.188] (II) LoadModule: "glx"
    [ 640.188] (II) Loading /usr/lib64/nvidia/xorg/libglx.so
    [ 640.204] (II) Module glx: vendor="NVIDIA Corporation"
    [ 640.204] compiled for 4.0.2, module version = 1.0.0
    [ 640.204] Module class: X.Org Server Extension

    [ 210.597] (II) LoadModule: "glx"
    [ 210.597] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so
    [ 210.597] (II) Module glx: vendor="X.Org Foundation"
    [ 210.597] compiled for 1.14.4, module version = 1.0.0
    [ 210.597] ABI class: X.Org Server Extension, version 7.0
    [ 210.597] (==) AIGLX enabled
    [ 210.597] Loading extension GLX

    So, for some reason for your drivers Xorg’s libglx is being loaded, instead of NVidia’s glx.

    • slaanesh says:

      Do you have a specific Files section in your xorg.conf that overrides the one in /etc/xorg.conf.d/00-nvidia.conf? The path is correctly specified in the drivers; in fact on my system the GLX module is loaded successfully:

      # cat /etc/X11/xorg.conf.d/00-nvidia.conf 
      Section "Files"
      	ModulePath   "/usr/lib64/nvidia/xorg"
      	ModulePath   "/usr/lib64/xorg/modules"
      Section "Module"
          Disable "glamoregl"
      # cat /var/log/Xorg.0.log| grep -i glx
      [     4.234] (II) "glx" will be loaded by default.
      [     4.234] (II) LoadModule: "glx"
      [     4.234] (II) Loading /usr/lib64/nvidia/xorg/libglx.so
      [     4.320] (II) Module glx: vendor="NVIDIA Corporation"
      [     4.320] (II) NVIDIA GLX Module  334.21  Thu Feb 27 13:54:04 PST 2014
      [     4.320] Loading extension GLX
      [     5.095] Loading extension NV-GLX
      [     5.194] (II) Initializing extension GLX
      • My xorg.conf had no Files section, when I added it everything went ok:

        Section "Files"
            ModulePath     "/usr/lib64/nvidia/xorg/"
            ModulePath     "/usr/lib64/xorg/modules/"
            ModulePath     "/usr/lib64/xorg/modules/drivers/"

        Thanks for your time. Now to check on driver’s stability.

        • Perhaps you have to add ‘ModulePath “/usr/lib64/xorg/modules/drivers/”’ to 00-nvidia.conf on xorg.conf.d? Since I had no “Files” section on my xorg.conf and had to add this section to my xorg.conf manually.

          • slaanesh says:

            Actually this is not needed. Your system should automatically add that directory as it’s a subfolder of modules. This is all I have on my Dual monitor system:

            $ cat /etc/X11/xorg.conf
            Section "Device"
            	Identifier  "Device0"
            	Driver      "nvidia"
            	Option      "NoLogo" "true"
            	Option      "DPI" "96 x 96"
            $ cat /etc/X11/xorg.conf.d/00-nvidia.conf 
            Section "Files"
            	ModulePath   "/usr/lib64/nvidia/xorg"
            	ModulePath   "/usr/lib64/xorg/modules"
            Section "Module"
                Disable "glamoregl"
          • slaanesh says:

            Forgot to say that both files are added as they are by the package; so unless you have some customization that overrides the default, it should start without problem.


Leave a Reply

%d bloggers like this: