Nvidia driver

nvidia-settings
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.

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.
  • 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 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.
  • Starting from version 343.13, the nvidia-settings binary is compiled with GTK3 instead of GTK2 on Fedora and RHEL/CentOS 7+.

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 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.
  • Added the GPU Deployment kit to the repository. This is constructed with NVML (NVIDIA Management Library) included with the drivers plus headers, docs and samples from a separate tarball. The separate tarball is using a different version number than the drivers. This is packaged in the nvidia-driver-NVML and nvidia-driver-NVML-devel packages. Installing these, the gpu-deployment-kit dependency provided by the CUDA repositories is preserved.
  • Along with NVML, the nvidia-healthmon package is provided to monitor TESLA GPU clusters.

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 can also rely on the nvidia-modprobe command in the system, so the new optional package has been added.
  • UDev rule to autoload the nvidia-uvm module in nvidia-driver-cuda.

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.
  • Starting from Fedora 21, all driver X.org configuration can be managed by simply adding/removing X.org configuration snippets in /etc/X11/xorg.conf.d.
  • Use new OutputClass directive on Fedora 21 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.
  • Add the IgnoreABI directive by default on Fedora rawhide builds.

Here is an example on my Fedora laptop at work:

================================================================================
 Package                 Arch        Version                Repository     Size
================================================================================
Updating:
 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 systemel6 / el7f19 / f20f21 / f22
Driver branchLong LivedShort Lived
Long Lived
Beta
Short Lived
Long Lived
Driver version340.65343.36346.22
Architectures:

i686
x86_64
YesYesYes
Basic nvidia driver:

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

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

nvidia-driver-NvFBCOpenGL
YesYesYes
Nvidia tools:

nvidia-healthmon (x86_64)
nvidia-modprobe
nvidia-settings
nvidia-xconfig
YesYesYes
Binary kernel
module (kABI):

kmod-nvidia
YesNoNo
DKMS kernel
module:

dkms-nvidia
YesYesYes
aKMOD kernel
module:

akmod-nvidia
NoYesYes
32 bit compatibility on x86_64:

nvidia-libXNVCtrl
nvidia-driver-libs
nvidia-driver-cuda-libs
nvidia-driver-NVML
YesYesYes
GPU Deployment kit + development:

nvidia-driver-NVML-devel
nvidia-driver-devel
YesYesYes

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:

yum-config-manager --add-repo=http://negativo17.org/repos/fedora-nvidia.repo

To install the repository on CentOS/RHEL:

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

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 kernel-devel

Requirement on kernel-devel is required as otherwise the package kernel-debug-devel is pulled in automatically in place of the normal non-debug package.

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.

Bugs

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

81 thoughts on “Nvidia driver”

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

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

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

    1. 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.

  2. 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! =)

    1. 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.

      1. 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?

        1. 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
          kernel-devel-uname-r

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

          1. in the spec file the kernel-devel is treated as kernel-devel-debug instead of kernel-devel
            to get the kernel-devel work as dependency

            Requires: akmod-nvidia
            Requires: kernel-devel(x86-64)
            Requires: kernel-debug-devel
            Requires: kmod-nvidia
            Requires: xorg-x11-drv-nvidia-libs(x86-32)

  3. 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?

  4. 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?

  5. 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?

    1. 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.

  6. 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.

  7. 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:

    (331.67)
    [ 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

    (334.21)
    [ 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.

    1. 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"
      EndSection
      
      Section "Module"
          Disable "glamoregl"
      EndSection
      # 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
      1. 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/"
        EndSection

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

          1. 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"
            EndSection
            $ cat /etc/X11/xorg.conf.d/00-nvidia.conf 
            Section "Files"
            	ModulePath   "/usr/lib64/nvidia/xorg"
            	ModulePath   "/usr/lib64/xorg/modules"
            EndSection
            
            Section "Module"
                Disable "glamoregl"
            EndSection
          2. 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.

          3. I seem to have encountered the same issue in Fedora 20, X wouldn’t start because it was trying to use the wrong GLX module.

            I had previously been using the packages from the RPMFusion repos without problems and switched over with:

            yum remove \*nvidia\*
            yum install nvidia-driver akmod-nvidia nvidia-driver-libs.i686

            On reboot I got a blank screen. Looking in the Xorg.0.log I could see that it was loading libglx.so from /usr/lib64/xorg/modules/extensions instead of /usr/lib64/nvidia/xorg. I checked both my /etc/X11/xorg.conf and /etc/X11/xorg.conf.d/00-nvidia.conf files and both are exactly as Simone listed but nonetheless X was loading the wrong GLX module. As I workaround I tried copying the “Files” Section from /etc/X11/xorg.conf.d/00-nvidia.conf into my /etc/X11/xorg.conf and after that everything worked fine so it seems that my problem was that the /etc/X11/xorg.conf.d/00-nvidia.conf file was being ignored by X.

  8. So where’s the libcudart.so.5.5 for 64-bit.

    I keep getting:
    error while loading shared libraries: libcudart.so.5.5: wrong ELF class: ELFCLASS32

    1. That’s part of CUDA 5.5, which I’m not packaging. It seems you’re loading the 32 bit libcudart.so.5.5 in your 64 bit environment.

      1. Thought it was a negativo17 repo problem because it happened when I did yum update…

        But something about this started to sound familiar so I went back through my notes. Managed to find that I had this problem before and found my fix: (so I’m good now)

        sudo ln -sf libcuda.so.340.24 /usr/lib64/nvidia/libcuda.so
        sudo ln -sf libcuda.so.340.24 /usr/lib/nvidia/libcuda.so
        
        sudo rsync -arv /usr/local/cuda-5.5/lib64/* /usr/lib64/nvidia/
        sudo rsync -arv /usr/local/cuda-5.5/lib/* /usr/lib/nvidia/
        
        sudo ldconfig
        1. First of all, this has nothing to do with libcudart libraries error you were referring to. Second, this is all wrong as you’re duplicating libraries all over, including linking x86_64 in i686 folders.

          To find the library you are requiring type the following command:

          # yum provides \*libcuda.so

          This will tell you that it’s in the nvidia-driver-devel package; so assuming you are on an x86_64 system, the only thing you need to do to have the library on the system is to do the following:

          # yum install nvidia-driver-devel nvidia-driver-devel.i686

          Second step is to make sure your system can find the CUDA libraries. Copying the libraries you require somewhere else is totally wrong. You actually need to make your system find the CUDA ones instead.

          Copy the two /etc/ld.so.conf.d/nvidia-lib*.conf files as /etc/ld.so.conf.d/cuda-lib*.conf and replace the contents with your cuda paths.

          Afterwards, rerun ldconfig to rebuild the library cache. Running ldconfig -p | grep library.so will tell you where the system is getting its libraries.

  9. I just installed driver 343.22 on F20 and system fails to boot on graphic mode. I have a 9800 GT, and driver 343.22 release notes state that “removed support for G8x, G9x […] Ongoing support for new Linux kernels and X servers, as well as fixes for critical bugs, will be included in 340.* legacy releases through the end of 2019.”
    Probably a dumb question, but does the G9x above includes the 9800GT? If so, which driver should I download? It seems that there’s no 340-legacy packages yet.

    1. Replying to myself: yep, 9800 GT has been officially labeled legacy with the release of 343.x driver series (full list of cards here). So, I guess I’ll just have to revert back to nouveau until 340xx legacy drivers are available… :-/

      Any ETA?

      1. I’m creating a separate repository for the 340 branch as yours it’s not the first request I receive. Will post it on the blog once it’s ready.

        Please note that today’s games do not run well on old hardware such as the 9800GT, and if you don’t play games and don’t need full hardware acceleration the nouveau driver is more than fine.

        1. The repository has been created. Just grab the appropriate *340.repo file and put it in place in /etc/yum.repos.d.
          To sync you can use the yum distro-sync command.

          Example for Fedora when using aKMOD packages:

          yum-config-manager --disable fedora-nvidia
          yum-config-manager --add-repo=http://negativo17.org/repos/fedora-nvidia-340.repo
          yum remove kmod-nvidia\*
          yum distro-sync \*nvidia\*
          reboot
          1. Wow, that was fast! =) I just installed, and it is working flawlessly. I’m back in the game ;-)

            Thank you so much for such awesome support =))

  10. Thks for the info, and for providing support for legacy cards. I will probably upgrade my graphics card in the near future but, in the meantime, being able to use NVidia drivers would be great. I am currently running Nouveau as a workaround, and overall it indeed works fine, but aside from the worse performance, it also has some issues (sometimes it freezes after login on GNOME, Google Sheets doesn’t redraw sometimes on Google Chrome etc.).

  11. Hello. I am using Fedora 20 on laptop with Optimus. I have read ur article about complex setup with Nvidia Optimus. I wanted to give it a try with Optimus enabled used Nvidia support but first i wanted to try only installing nvidia driver and using only onboard Nvidia card (which is 630M).

    I tried installing driver from ur repo “nvidia-driver” (which also installed akmod automaticly) but when i reboot i get black screen with flashing “_”. When i enter tty and try to “startx” i get error “(EE) no screens found(EE)” after line “Loading extension GLX”, and in the log file there’s also “(EE) No devices detected)”. Could you give me a hand ?

    1. A bit too vague.
      Did the module load correctly? Check if the module is loaded, if yes check if kmod-nvidia rpm is installed, and if not check for errors in akmod building the module.
      Did you have a pre-existing xorg.conf file?
      Have you disabled your Intel card in the bios? Are you sure that you are not using Intel on the first card and trying to load the Nvidia module without disabling it hardware or software wise?

      Most of your questions are answered in the page or in the previous comments.

      1. I cannot disable my intel card in BIOS. Before booting i see three blue-like loading bars so i assume that akmod is working.
        I use xorg.conf file that was automaticly created when installing Your drivers.
        Everything is installed correctly. How do i disable Intel card software wise ? I though it should be done in the xorg.conf

        1. If you can’t disable it in the Bios and the main LVDS display is attached to your Intel card there’s not much you can do. Just opt for the intel/nvidia Optimus configuration or the intel/nouveau Prime configuration. How to configure X.org for this is written in the guide.

  12. So… updated and now I’m getting:

    NVRM: The NVIDIA GeForce 210 GPU installed in this system is
    NVRM: supported through the NVIDIA 340.xx Legacy drivers. Please
    NVRM: visit http://www.nvidia.com/object/unix.html for more
    NVRM: information. The 343.22 NVIDIA driver will ignore
    NVRM: this GPU. Continuing probe…

    Any way to downgrade?

  13. There is a bug in the nvidia-persistenced package. It tries to start /usr/bin/nvidia-persistenced, but the daemon is installed to /usr/sbin/nvidia-persistenced.

    Another question, do you have the “nvcc” program packaged? It normally comes with the cuda installation from nvidia, but I cannot find it with a yum provides search.

    1. Thanks for spotting the mistake, I’m updating all nvidia-persistenced packages now.

      Regarding CUDA binaries; I have packaged the latest CUDA libraries and binaries (6.5.19) and I’m looking for someone to test them before publishing them along with the rest of the Nvidia packages. Are you interested to test them and give some feedback?

  14. For anyone who runs into the same problems I did, trying to run ccminer using this driver package: make sure to install nvidia-driver-devel/nvidia-driver-cuda-libs and nvidia-modprobe, these are not normally brought along with the driver installation. I’m using a cuda toolkit 6.5 installation separate from RPMs as I’m not sure how to compile ccminer with the packaged nvidia-driver-cuda. (I also installed nvidia-driver-cuda for the nvidia-smi binary.) But I am just glad to have an up to date packaging of the driver.

    1. Actually to get all headers required for compiling software against the Nvidia driver libraries you should just install the nvidia-driver-devel package; this will pull in almost all of the original Nvidia tarball:

      $ rpm -q --requires nvidia-driver-devel | grep ^nvidia
      nvidia-driver-NVML(x86-32) = 2:343.22-1.fc21
      nvidia-driver-NvFBCOpenGL(x86-32) = 2:343.22-1.fc21
      nvidia-driver-cuda-libs(x86-32) = 2:343.22-1.fc21
      nvidia-driver-libs(x86-32) = 2:343.22-1.fc21

      The package nvidia-modprobe should not actually be needed anymore (I’m offering it for compatibility reasons) as the main driver gets loaded automatically and the UVM extra module is loaded through an UDEV rule:

      $ rpm -ql nvidia-driver-cuda  | grep uvm
      /usr/lib/udev/rules.d/60-nvidia-uvm.rules

      What is exactly that your setup was missing that needed you to install the nvidia-modprobe package?

      Thanks.

  15. I couldn’t compile ccminer without nvcc so I didn’t try (and it is the only cuda application I use), but sure I can help test when I get some time. Without nvidia-modprobe, ccminer would not run saying that it could not query the number of CUDA devices; I looked up the error and saw calls to nvidia-modprobe so I tried installing it and then it worked. Do you have my email, or IRC?

    1. I have your email, thanks. Will send you the link with the packages (hopefully tomorrow) after reviewing them.

      Many thanks!

  16. Hi,
    first of all thanks for packaging the new nvidia driver for fedora!
    Runs fine here on a F20 installation but there is one thing i miss…

    Kernel-RT support.
    The RPM-Fusion driver worked well with akmods enabled to build for the ccrma-kernel but this here is different. Don’t know if nvidia changed something or maybe its the packaging?
    Trying to –force the build give me this errror:
    *** Failed PREEMPT_RT sanity check. Bailing out! ***
    Any Ideas? Things i can try?

    Thanks!

    1. Hello, the kernel module is compiled with IGNORE_PREEMPT_RT_PRESENCE=1. Which driver version are you using? Can you check that this is passed during the build in the logs?

      Also, where is the RT enabled kernel on planetccma? I can’t find it.

        1. Hi,
          i changed the spec file and rebuild the akmod with success. yay!
          Don’t know where you added the option but this way it worked for me:

          for kernel_version in %{?kernel_versions}; do
          %if !0%{?_nv_build_module_instances}
              pushd _kmod_build_${kernel_version%%___*}/
                  make %{?_smp_mflags} \
                      IGNORE_XEN_PRESENCE=1 \
                       IGNORE_PREEMPT_RT_PRESENCE=1 \
                      SYSSRC="${kernel_version##*___}" \
                      module
              popd
              pushd _kmod_build_${kernel_version%%___*}/uvm
                  make %{?_smp_mflags} \
                      IGNORE_XEN_PRESENCE=1 \
                       IGNORE_PREEMPT_RT_PRESENCE=1 \
                      SYSSRC="${kernel_version##*___}" \
                      module
              popd
          %else
              pushd _kmod_build_${kernel_version%%___*}/
                  make \
                      IGNORE_XEN_PRESENCE=1 \
                       IGNORE_PREEMPT_RT_PRESENCE=1 \
                      SYSSRC="${kernel_version##*___}" \
                      NV_BUILD_MODULE_INSTANCES=%{?_nv_build_module_instances} \
                      module
              popd
          %endif

          best regards

  17. Hi,

    Great that you’ve built the 346 beta drivers for fc21, but the 343 packages seem to be gone. Example :-

    yum list *nvidia*
    
    Loaded plugins: langpacks
    Available Packages
    akmod-nvidia.x86_64                                           2:343.22-2.fc21                        fedora-nvidia

    But the install says :-

    No Presto metadata available for fedora-nvidia
    akmod-nvidia-343.22-2.fc21.x86 FAILED                                          
    http://negativo17.org/repos/nvidia/fedora-21/x86_64/akmod-nvidia-343.22-2.fc21.x86_64.rpm: [Errno 14] HTTP Error 404 - Not Found

    I’ll try installing the 346 rpm manually for now

    1. You simply had the old metadata on your computer and I had already uploaded the new packages and metadata on the site. Next time, just delete your yum cache; there’s no need to do anything manual:

      yum clean all
      yum update
  18. I could not build the kernel module for Fedora 21. It says missing auto.conf and autoconf.h somewhere in the middle of the akmod log. My kernel is 3.17.3-300.fc21.x86_64

    Is there a way to fix that or is it possible for you to provide the rpm for the kernel module?

    1. You’re missing the kernel-devel package that matches your system. Follow the instructions on the page and rebuild the modules (akmods --force) or reboot.

      1. I do have the matching kernel-devel
        kernel-devel-3.17.3-300.fc21.x86_64

        I have been using akmods –force successfully with the packages from rpmfusion before. Suddenly it stops working. Not sure if it is the nvidia part or the fedora part that breaks.

          1. I still could not get it compiled with akmods. It turns out not missing those files, but something else that I could not figure out. If you could kindly help, the log is available at

            Click here to see the log

            At the start of the error , it says

            In file included from /tmp/akmodsbuild.w3LHxRAw/BUILD/nvidia-kmod-346.16-x86_64/_kmod_build_3.17.4-300.fc21.x86_64/nv-linux.h:107:0,
            from /tmp/akmodsbuild.w3LHxRAw/BUILD/nvidia-kmod-346.16-x86_64/_kmod_build_3.17.4-300.fc21.x86_64/nvlink-linux.h:14,
            from /tmp/akmodsbuild.w3LHxRAw/BUILD/nvidia-kmod-346.16-x86_64/_kmod_build_3.17.4-300.fc21.x86_64/nvlink.c:13:
            /tmp/akmodsbuild.w3LHxRAw/BUILD/nvidia-kmod-346.16-x86_64/_kmod_build_3.17.4-300.fc21.x86_64/nvlink.c: In function 'nvlink_init':
            include/linux/pci.h:1122:45: error: 'KBUILD_MODNAME' undeclared (first use in this function)
            __pci_register_driver(driver, THIS_MODULE, KBUILD_MODNAME)

  19. Hi, nice packaging.

    Any chance you could also provide ‘legacy’ drivers? Just noticed my card is no longer supported by the latest drivers, only by the 340.xx series…

  20. hello..
    want to try this primarilly in order to use gpu rendering in cycles, cuda being a prerequisit..
    a question pops, excuse my ignorance.. new to .rpm/ yum..
    taken that rpmfusion needs to be added/ enabled, for akmod to work, how do i point to the wanted drivers?? as in, not the rpmfusion ones??
    thanks..

  21. Hello, I have a problem with the new Fedora 21. With the 340 driver, I got stuck on gnome-shell start, just after GDM login.
    Gnome shell hangs with 90+ CPU load and I can’t go beyond a grey screen.

    1. Ok, I fixed it. For anyone having same problem, just remove the ‘gnome-shell-extension-background-logo’ package
      sudo yum remove gnome-shell-extension-background-logo

  22. Hello negativo17. First of all I wanna say thank you for your work. I came here to ask you – how about nvidia driver installation key? I use Fedora 21 with enabled Ultra Fast and Secure Boot UEFI options and I need import key which should be in /usr/share/nvidia/ folder by mokutil. The problem is i cant find him in /usr/share/nvidia after installation driver from your repository. I have to manually download nvidia driver from nvidia’s website, then manually install it and in the installation process choose option to generate key. After that i have to import that key with sudo mokutil --import /usr/share/nvidia/nvidianvidia-modsign*.der then restart computer and add key using Shim UEFI Keys Manager. Where nvidia driver from your repository put the key? Or maybe driver from you repositories doesn’t generate key during the installation process? Please reply me on my email or in the comment below. I’ve marked option “Notify me the new posts”.

    1. Hello, thanks for the information.

      No I haven’t tried doing what you describe. Usually I disable UEFI Secure Boot if using the Nvidia Drivers. I will include required files and instructions on the page.
      How do you “add key using Shim UEFI Keys Manager”? Can you provide the commands?

  23. Hi,

    I just installed F21, and for some reason nvidia driver is not working, gnome just shows that vague error page saying that “something wrong happened”. I have a GTX 750 Ti that was working just fine on F20. Any tips on how to understand what’s wrong?
    I followed the instructions to the letter, the only thing I had to workaround was the installation of kmodtool, I had to disable gpg checking because for some reason rpmfusion is providing the F20 package instead of F21.

    To make matters worse, nouveau is not working, and either I fix this or I’ll have to go back to F20…

    1. Nevermind… I just rebooted today and it just worked :-) One of my last attempts to fix the problem probably did it, I guess I was just one reboot away from success ;-)

  24. Dude!
    Thanks so much for your comprehensive and clearly worded instructions, and indeed your repos themselves. New Fedora 21 installation this weekend, beating my head against a wall with Nvidia drivers, no 340xx series drivers available in Fusion, 304xx broken and uninstallable. Your 340 repo really came to the rescue.

    Keep up the good work!

  25. Thanks for the great repo!

    I’ve recently switched from Ubuntu to Fedora 21 and I did not want to install RPMFusion just for the Nvidia drivers for my 660ti, so I was surely happy when I found this alternative – I like the clean documentation and you seem to know what you are doing.

    Keep the good work up!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

I'm not dumb. I just have a command of thoroughly useless information.

%d bloggers like this: