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.
  • 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+.


  • 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 ~100 MB worth of installed libraries. nvidia-persistenced falls in this category as it’s not neeeded 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.
  • Includes 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 a rundown of Nvidia supported drivers and options split by distribution:

Operating systemel6 / el7f20 / f21f22
Driver branchLong LivedShort Lived
Long Lived
Short Lived
Long Lived
Driver version346.47346.47349.12

Basic nvidia driver:

CUDA libraries and tools:

OpenGL Framebuffer Capture:

Nvidia tools:

nvidia-healthmon (x86_64)
Binary kernel
module (kABI):

DKMS kernel

aKMOD kernel

32 bit compatibility on x86_64:

GPU Deployment kit + development:


Along with the CUDA tools and libraries:

Operating systemel6 / el7f20 / f21 / f22
CUDA branch/version6.
Basic CUDA libraries/tools:

CUDA development:

Java GUI programs:

32 bit compatibility on x86_64:


Sample installation on an office laptop

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.

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, EPEL, or the Nvidia CUDA repository. The packages should already take care of this for you, as they should be completely compatible; 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 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 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

CUDA installations

To install just a runtime CUDA support (required for running CUDA enabled programs):

yum -y install cuda

To install packages required for enabling CUDA development:

yum -y install cuda-devel

or, if you need also NVML / GPU Deployment kit libraries:

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

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.

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.

142 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

          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:

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

    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"
      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
      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/"

        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"
            $ 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"
          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\*
          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

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


  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?


    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##*___}" \
              pushd _kmod_build_${kernel_version%%___*}/uvm
                  make %{?_smp_mflags} \
                      IGNORE_XEN_PRESENCE=1 \
                       IGNORE_PREEMPT_RT_PRESENCE=1 \
                      SYSSRC="${kernel_version##*___}" \
              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} \

          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

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

  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!

  26. Hi there. Thanks for your great work with the 340xx series driver. It made my laptop usable on Fedora 21, after I’d bashed my head against RPMFusion’s version for hours.

    I was wondering if you’d be willing to apply this patch to the 340xx driver series, or if it was even possible to do given Fedora’s kernel. I have the same issue laid out in the bug where resume-from-suspend causes graphical corruption every time. It’s not too annoying, since I can just “Alt+F2 -> r” and reload GNOME but it’s still undesired behaviour.


    Or, if you know any way of getting rid of this corruption through a grub/driver setting, that’d be great too!

    Thanks a bunch.

    1. I will rebuild and update when I come back on the 8th of January, I’m currently travelling through Indochina without connectivity. Thanks for letting me know.

    2. Nice! I’ve been suffering with graphical corruption after suspend as well, I thought it could be related to the fact that 346.22 is marked as beta on Nvidia site, but I tried 343.36 from RPMFusion and the problem was still there. Hopefully this patch will fix this problem ;-)

    3. Hello, the patch you are pointing to is already included since the 331.67 release. Probably the problem you are experiencing is related to something else.

  27. Hi!

    Just installed:
    from your repository.

    How to configure Fedora to use nvidia driver, since after installation I do not see xorg.conf configuration file in the /etc/X11 folder?

    1. Since Fedora 21 (and CentOS/RHEL 6.6 with newer Xorg) there is no need for an Xorg.conf file. The configuration is using the new “OutputClass” directive (/etc/X11/xorg.conf.d/99-nvidia-driver.conf). Please look at the driver page as I’ve described it there.

  28. Hi there!

    Since I updated with fedup from F20 to F21 my nvidia drivers were missed somewhere in the universe (GeForce 9400M card, so 340xx).

    I followed your guide and I have propietary drivers again. Really you finished one of my worst headaches since long.

    Keep the good work!

  29. Fedora 340 repo is great, works fantastic and it saved me from trouble when I upgraded F20 to F21. You should add a note on blog post that it exists so people would find it easily.

    Thanks for all of this :)

  30. how to install 340 ??

    I installed repo “nvidia-repo”
    this command “yum -y install nvidia-driver” install by me driver 346 and this vs dont work.

    please what is theyum command to install 340 vs

    1. Hello, yes, there is a mistake. The package is only available for Fedora and internal RHEL builds. I’m updating all driver releases/builds with the fix. Please give a few hours for the upload. Thanks for spotting!

  31. Hello..
    First of all thanks for the tutorial and for maintaining the repo..
    Maybe you can help me because I’ve been searching for days for a solution. I have a GTX 650 and since I installed the nvidia driver I simply cannot get graphical boot. I have managed to get grub to the resolution of 2560×1080 bott as soon as fedora starts to boot I get back to an ugly resolution with no graphical boot..
    when I boot the live media I have graphical boot but I guess that’s because it is using the nouveau driver.
    here is my /etc/default/grub:

    GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
    GRUB_CMDLINE_LINUX="rd.lvm.lv=fedora_hal-terminal/root rd.lvm.lv=fedora_hal-terminal/swap rhgb quiet rdblacklist=nouveau nomodeset"

    1. Hello,

      you cannot have graphical boot with the nvidia driver enabled and the PC in bios mode. The nvidia driver expects only vga to be present on the console, otherwise it will throw an error. It can work with vesa on the console, but it’s not supported and you will still get the notice.

      What is supported, is UEFI graphical boot. The system will use efifb for the console and the nvidia driver for the DDX.

      See the table at the end of this article:


  32. Hi!

    Can not go forward with nVidia drivers installation. Can you prepare step by step installation instruction?
    I still get the “Oh no! Something has gone wrong.” information.
    There is a lot of information from people who successfully installed nVidia drivers but there is no complete how-to.
    Following steps described here-in or even somwhere else still leads to problem with driver installation.
    I believe that step by step instruction will help people like me to enjoy full features of nVidia drivers under Linux.
    I have installed:

    I run nvidia-xconfig and as an output I got warning that the X configuration file cannot be locate/open and the xorg-server was not found in the pkg-config search path, however xorg.conf file was created.
    No sucess after reboot.

    1. Hi,

      Don’t know if it will help but, in my case, installation on F21 always went wrong, but simply rebooting after the GNOME error message “fixed” the problem.



    2. The detailed instructions are printed above, there’s not much to add. Just check that your module is built and loaded.

      You can remove all of these:


      You will not need them if you don’t need to run CUDA enabled programs.

      1. I run dkms install -k 3.17.8-300.fc21.x86_64 -m nvidia -v 346.22 –verbose. Drives has been compiled successfully, but after reboot I am still in the same place.
        What I am missing to sucessfully enable nvidia drives?

        1. I have founf in the Xorg.0.log file that the glx module is loaded but it generates errors.
          Module glx )libglx.so) is loaded from /usr/lib64/xorg/modules/extensions folder instead of /usr/lib64/nvidia/xorg folder.
          Probably this is the root cause of my problem. Can you help me to solve this problem? Is it a simple way to fix it?

          1. Hi!

            Found the problem – xorg.conf created in /etc/X11 folder after run nvida-xconfig command made X server impossible to start. After xorg.conf removal and following reboot I can enjoy X server running on nvidia derivers.

            On the other hand. Do I need to reinstall (dkms install etc. …) drivers either if new driver version will appear (now I have 346.22, and new one 346.35 is available) and new kernel version will appear?
            Another question is about snippets in xorg.conf.d folder. Can you post some examples for monitor video card, mouse, keyboard etc. configurations?
            What about snippets order (question in terms of labeling Identifiers) – is it relevant or not?

          2. If you are running Fedora 21, there should be no /etc/X11/xorg.conf, so please delete it and start from scratch if you want to override the default configuration. Remember that unless you are doing something specific, you don’t need to edit xorg.conf directly. Keyboard and mouse sections are particularly useless.

            When updating, the packages will take care of everything, you don’t need to perform any action.

  33. Thanks very much for the hard work. Got my legacy card working with the 340 driver and akmods –force. Finally understand the differences in the different Nvidia drivers.

  34. Hi.

    Some applications in Fedora segfaults with libGL implementation of latest nVidia driver (from this repository). Please see [1] for details. The problem is something I don’t really understand much.

    Do you experience same issue with nVidia driver from this repository?

    Do you experience same issue with nVidia driver from RPMFusion?

    Try to install and run nomacs. It should segfault.

    Thank you.

    [1] https://bugzilla.redhat.com/show_bug.cgi?id=1181085

    1. Sorry but so far I’ve not experienced this. Driver wise, these packages and RPMFusion ones should exhibit the same problems. The driver are shipped in binary format, the difference is only on packaging and on the accompanying tools (nvidia-{settings,xconfig,modprobe,persistenced}.

  35. Hi

    Thank you very much for your great work. Really very helpful.

    I have a fresh Korora 21 Beta 64Bit (remix from Fedora kororaproject.org) installed on UEFI.

    I installed “yum install nvidia-driver akmod-nvidia kernel-devel”.

    Bootings with secure boot enabled produce always a “oh no something went wrong – log out” on GDM. No log-in possible. Access only by console with Ctrl-Alt-F2.

    Disabling secure boot in UEFI for bootings does the trick. Now GDM allows log-in and driver Nvidia 346.35 runs fine.

    Behaviour is reproducible constantly.

    So no secure boot on UEFI possible.

    Please investigate.

    Greetings from cantone San Gallo to Lugano.


    1. Hello,

      yes, drivers do not work with Secure Boot enabled. There are two ways to resolve this:

      – Rebuild the kernel modules always with the same key, and enroll the key in your system’s key database. I can’t do this for you, as I would need to send you the private key and thus rendering Secure Boot useless.

      – I could ship you a prebuilt binary and the public key only to enroll it, but you could not regenerate the rpm and would require me to sync binary updates along with the official kernel packages; which is almost impossible.

      Unfortunately there is no easy way for this, so my suggestion is not to use the binary drivers if you need Secure Boot enabled. Please see this link with instructions from Redhat:


      And this article that also covers UEFI Secure Boot:


  36. Oh oh now I did it. I was working on my conky background layout. I wanted to show the actual clock speed of my 780 Ghz Edition on it. I needed nvidia-smi to show that information. Fedora reported your missing this package, please install (I believe it was) nvidia-cuda. I did and my conky script worked awesome until I rebooted. Fedora 21 would just stop when the blue bars where moving. I went ahead and switch to terminal 2. I removed /*nvidia/* and reinstalled the driver from start again. Now it loads and it crashes at the Gnome start up with a grey screen.

    Can anyone give me some guidance and what I can do to repair and what should I have installed to get the nvidia-smi tool?

    Thanks for any help. Did not sleep very well last night thinking how to fix this today.

    1. Assuming you are using Fedora 21 (you have not specified) you can start by deleting /etc/X11/xorg.conf and rebooting. This should start X with the default settings and load the appropriate driver depending on the new DRM class (see above comments).

      Then, if it does not start anyway look in the logs, module status, etc.

    1. Hmm now that you say that, I think that was packaged i installed originally. While working on the conky script, I let Fedora 21 run some updates. One of them was a new kernel, I believe it moved to 3.18. something. I wonder if that’s what cause all my issues instead of me installing the nvidia-driver-cuda. Thank you so much slaanesh and will keep you posted once I get home from work tonight and let you know what I discover. I really do appreciate everything you do for the Fedora Community.

  37. I’m using Fedora 21 x86_64 with kernel 3.18.3-201 and nvidia 346.35 in my notebook. To be able to use external monitor using HDMI, I followed the standard xorg.conf available in the Internet. But I could only use the external monitor, the notebook monitor is undetected.


    Section "ServerLayout"
    Identifier "layout"
    Screen 0 "nvidia"
    Inactive "intel"

    Section "Device"
    Identifier "nvidia"
    Driver "nvidia"
    BusID "01:00:0"
    Option "ConstrainCursor" "no"

    Section "Screen"
    Identifier "nvidia"
    Device "nvidia"
    Option "AllowEmptyInitialConfiguration"

    Section "Device"
    Identifier "intel"
    Driver "modesetting"

    Section "Screen"
    Identifier "intel"
    Device "intel"

    Output of xrandr:

    Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 16384 x 16384
    HDMI-0 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 1600mm x 900mm
    800x600 60.32 +
    1920x1080 (0x27f) 148.500MHz
    h: width 1920 start 2448 end 2492 total 2640 skew 0 clock 56.25KHz
    v: height 1080 start 1084 end 1089 total 1125 clock 50.00Hz

    Is there a way to enable the notebook screen? Previously before 346, I have LVDS-1 shown and was able to use both the internal and external monitors.

  38. Don’t know if this is important but wanted to report it all the same:

    mplayer: /lib64/nvidia/libOpenCL.so.1: no version information available (required by /lib64/libavutil.so.54)
    MPlayer SVN-r37363-4.9.2 (C) 2000-2015 MPlayer Team
    yum provides /lib64/nvidia/libOpenCL.so.1
    2:nvidia-driver-cuda-libs-346.35-3.fc21.x86_64 : Libraries for nvidia-driver-cuda
    Repo        : @negativo17-nvidia
    Matched from:
    Filename    : /lib64/nvidia/libOpenCL.so.1
    1. Thanks, will look into it. ffmpeg is compiled with OpenCL support in the RPMFusion packages.
      Are you using OpenCL for encoding?

  39. Hi there! I want to play CS:GO in my CentOS 7 with NVIDIA Drivers and I can’t install nvidia-driver-libs.i686 because of a missing dependency ( libvdpau(x86-32) ). I have been seeking for a solution but I didnt find it!

    Any idea? Thanks!

  40. Well, slaanesh, I could be no less than thankful to you for posting about nvidia x fedora issues, so common to so many users. But unfortunately your instructions did not solve my problem, which was simply to install the latest nvidia driver. I have tried many of the available solutions without success. My laptop worked with the bumblebee, as per installation instructions in fedora site, but, as you say, bumblebee is a hack. So I returned to the noveau driver, despite all shortcomings. At least I can have my laptop working! Running fedora 21, however, I am still stuck with the bug of two displays and video instabilities already described elsewhere. I have to turn off display 2 every time I log in. Better this than nothing.

  41. Hi,
    many thanks for your great work. Yuor procedure it’s the only one that makes me able to install nvidia driver on my laptop. Anyway after all the installations yuo’ve suggested i’m unable to set my video resolution properly. it’s blocked and setted in a bad value. how could i change it please?
    Thank you so much.

    1. Maybe you have a broken EDID. Try to read X.org man pages (man xorg.conf) and Nvidia documentation (in /usr/share/doc/nvidia-driver) on how to override it.

  42. Hey thanks for the repositories mate! Would you have any idea when the driver will be available for fc22/kernel 4.0*?

  43. Hello,

    I have tried to install your nvidia drivers today – unfortunately, it was a bit a bumpy ride and is not working fully.

    First of all I’ve removed RPMFusion packaged, then I have installed nvidia-driver and dkms-nvida via yum from your repository.

    1. After boot nvidia module is not enabled and system boots into 1024×768 resolution. Installing nvidia-xconfig and running it fixes the resolution issue, but…
    2. compiz does not work – how do I enable compiz?

    Many thanks,

    1. You need to be more specific, this is totally vague.

      Which distribution are you running? Fedora 21? Have you then removed akmod after switching to dkms? What do the Xorg, dkms log say when you have a 1024×768 resolution? Does the kernel module compile and load cleanly? Have you removed/reset your xorg configuration (there should be no /etc/X11/xorg.conf file if you are running Fedora 21+).

      Which desktop environment are you running? Compiz can’t run everywhere. Have you checked that you can run it?

      1. Hi!
        Thanks for reply!

        Yes, I am running Fedora 21 with MATE-Desktop.
        Yes, I’ve used compiz with MATE-Desktop with no issues with akmod drivers :)
        Yes, I did remove akmods before installing dkms drivers.
        Yes, there was no default xorg.conf file – akmods seemed to work without it with no issues.
        Yes, modules did compile cleanly though dkms was complaining about missing dkms.conf.

        To fix the low resolution had to install nvidia-xconfig module from your repository and run it – it created an xorg.conf with bunch of settings. Only:
        Section “Device”
        Identifier “Videocard0″
        Driver “nvidia”
        seemed to be required for nvidia driver to load.
        To enable compiz/OpenGL had to add the following lines in order to get OpenGL load correctly:
        Section “Files”
        ModulePath “/usr/lib64/nvidia/xorg”
        ModulePath “/usr/lib64/xorg/modules”

        Sadly, after making everything work, totem would not play videos at all – I would only see the white screen. The reason I wanted to use your drivers was to get the native video rendering on my 2560×1440 screen… so had to revert back to akmods. After revert vidoes still don’t play in Totem, though VLC works fine.
        Will have time to play more with your drivers at weekend.

        Many thanks for your reply and comments!

        1. All the settings you have added to /etc/X11/xorg.conf are already inside the packages in the following files:


          1. I don’t recall seeing 99-nvidia-*.conf files there after installing your drivers… as I said – I’ll give it another go on the weekend. Thanks!

  44. Hey– Thanks for this project. I LOVE your repos!

    I discovered that after installing or upgrading (kernel along with new nvidia driver) a line in Grub2 is still loading nouveau or, at least, passing arguments to it. Right after that statement is a blacklisting of nouveau. I always boot into the “Ooops! Something went wrong.” every time I boot. When I removed the nouveau line from Grub and ran grub2-mkconfig and rebooted, the log-in screen came right up along with by secondary monitor. I’d thought I’d share that here. BTW, I’m always running the latest stable Fedora (21 at the moment).

    Thanks again!
    Matt Hutchinson

    1. Fedora 21 running on a Lenovo W540 installed in a docking station.

      I am running into the same “Oh no! Something has gone wrong!” issue after installing the nvidia driver and akmod packages given here. The only way I was able to recover was to switch to a tty console, and uninstall all of the nvidia code.

      I will try again and remove the nvidia switches (except the blacklist one) from the boot line.

      1. Just tried again, this time removing nouveau.modeset=0 from /boot/grub2/grub.cfg, but it didn’t make any difference. I still get “Oh no! …”

        1. I also have to ctl-alt F2, log in as root and run the nv modprobe command (can’t remember it off the top of my head).

  45. Hi! Whether it is possible install driver version 340xx? My graphics card – NVidia 200, so never version of the driver does not work …

  46. Hi!
    Thanks for the repos. Everything is working great! However, I have a questions. I’m sorry if it’s very “newbie” for all of you, but I figure that other might have the same question.

    All I did to install the driver was:
    – Install repo
    – Remove othe nvidia drivers
    – And: yum -y install nvidia-driver cuda

    I thought that I would need the akmod module to make sure that the driver do not breatk after kernel update. But I did not install it, did 2 kernel update after that and everything is working great still.

    So, my question: On a standard Fedora installation,
    – Why would I install akmod modules?
    – Why would I install dkms driver?

    Thank you!

    1. If you have installed nvidia-driver and did not specify akmod or dkms, you will get akmod by default on Fedora. Do you need cuda?

      1. ok, got it. Thanks for the reply.
        You are right. I probably don’t have any programs using cuda… Handbrake maybe? Probably not. I installed it, I figured that it would not do much harm to have it installed…

  47. Thanks! I install 340 drivers from your repository, and a few days everything was fine, but then (possibly after Yum partial update, but without kernel!) was again loaded driver novieau and disappeared 3-D effects… How to disable novieau and check the installation?..

  48. Usually in my Korora I can log-in as user xy and then switch to a log-in for a second user (or more) simultaneously without logging out user xy. I can have two or more users logged-in the same time and jumping from one user to another without logging out a user.

    This is not possible with my Korora 21 (Fedora 21) with recent nvidia drivers installed out of repo http://negativo17.org/repos/fedora-nvidia.repo

    As soon as trying to log-in a second user I get a “OOPS something went wrong” (from Gnome) on console 2 (Ctrl-Alt-F2) and the already logged-in user on console 1 is logged-out automatically.

    May be this due to problems with graphic drivers and/or Xorg.

    Here is what happens.

    What is wrong?


    1. If you look at the log, you can see that there are numerous errors (EE). Are you sure you have only the bundled /etc/X11/xorg.conf.d/*nvidia* files?

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: