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.
First of all the packaging is a lot simplified; more stuff is compiled from source, smaller packages and more options. This packages try to comply as maximum to the Fedora Packaging Guidelines; which means they have debuginfo packages, default Fedora’s GCC compile time options (where possible) and standard locations for binaries, data and docs.
Here is a list of all the “differences” from the various Nvidia driver packages that I was able to spot on the web.
- nvidia-settings, nvidia-persistenced, nvidia-xconfig and nvidia-modprobe are compiled from source.
- CUDA libraries and tools are split into subpackages. There’s no need to install all the CUDA libraries and tools on a system that has only one adapter and is used for occasional gaming or for simple office use. This can save ~100 MB worth of installed libraries. nvidia-persistenced falls in this category as it’s not neeeded on a normal laptop or gaming system.
- All RPM filters except for GL and OpenCL libraries have been removed, so there is no weird dependency option in the SPEC file. RPM pulls in all correct requirements on its own. This is to avoid pulling in the Nvidia drivers instead of the Mesa libraries or in place of the new open source OpenCL support that’s in Fedora.
- Simplified packaging with much simpler and readable SPEC file.
- Dependency on libva-vdpau-driver. So in Totem, or any other libVA supported application you can benefit from VDPAU acceleration.
- ELRepo ships 32 bit compatibility libraries in a separate package with x86_64 as the architecture and “32bit” in the name. 32 bit libraries should be like in RPMFusion, with an i686 package installable in parallel with the x86_64 one. There are no other packages in the distribution that are built for x86_64, with “32bit” in their name that contain i686 binaries (!), so Nvidia drivers should not be an exception. So no separate “32bit.x86_64″ package for 32 bit libraries also on CentOS/RHEL; just install
- Sources are generated with a script and inserted individually in the various packages; so it can be easily reproduced just by changing the version and rerunning the script.
- Versions are not hidden; all packages have the same driver version.
- No alternatives system, only the latest version which integrates CUDA support is available. For older releases nouveau works great; and anything below a GeForce 8xxx it’s in my opinion too low end to play anything modern. And Quake 3 and Doom 3 work greatly with nouveau, so that’s not a case!
- armv7hl support is included in Fedora 20+ packages.
nvidia-xconfigis not required on anything that uses the modular X.org directives, as it writes too much in the configuration file (keyboards, monitors, etc.) and the required entries should be written in separate configuration files under
/etc/X11/xorg.conf.d. The package is still available as it’s required to speed up some configuration like multi-monitor setups with SLI Mosaic enabled from the command line, but not installed by default.
- The CentOS/RHEL repository contains the “Long Lived Branch version” where less changes occur; while Fedora repositories contains the “Short Lived Branch version”. Beta and Fedora’s rawide repositories will contain the “Beta Branch version”
- The NVIDIA OpenGL-based Framebuffer Capture (NvFBCOpenGL) libraries (NvFBC and NvIFR) are private APIs that are only available to NVIDIA approved partners for use in remote graphics scenarios; so they are packaged in another small package called
nvidia-settingspackage now builds the external
libXNVCtrl.solibrary 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.
- Multiple choice of kernel module packages; akmod (RPMFusion) for Fedora and binary kmod (Kernel ABI whitelists) for CentOS/RHEL. In addition to this, on both distributions dkms packages are available. This way all cases and personal preferences are covered for both distributions.
- Starting of drivers version 331.17, the kernel module packages contain the main Nvidia kernel module (
nvidia.ko) but also the Unified Memory kernel module and support for multiple kernel modules as specified by the Nvidia documentation. These are optional and can be configured manually for CUDA enabled systems that need to address a specific GPU or to share memory between the CPU and GPU in CUDA programs.
- When building instantiated kernel modules; both akmod and dkms packages can be configured to build the additional modules instead of the single one, so you can still choose your preferred method.
- Starting from Nvidia driver version 334.16, the Nvidia DDX driver for X no longer loads the kernel module internally but relies on the
nvidia-modprobecommand in the system, so a new dependency has been added. Apparently this is not yet true, because the libraries try to load the kernel modules also with the system
modprobecommand if available.
- 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.confconfig file. Why? Gnome 3 by defaults hard-codes a 96×96 DPI resolution, most of the free drivers do (intel, nouveau, etc.) as the EDID is almost never reliable (please see the excellent Adam’s Jackson post where he explains this). As an example, if you install the Nvidia drivers on a RHEL/CentOS 6 laptop where you used to have nouveau installed (96 DPI hardcoded), the fonts gets 90% of the time supersize and ugly as Gnome 2 and the Nvidia driver do not hard-code 96 DPI like Gnome 3.
Here is an example on my Fedora laptop at work:
================================================================================ Package Arch Version Repository Size ================================================================================ 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:
el6 / el7
f19 / f20 / f21
|Driver version||331.49 / 334.21 (el7)||334.21|
|i686 (only libs in el7)|
|Basic nvidia driver||nvidia-driver|
|CUDA libraries and tools||nvidia-driver-cuda|
|OpenGL Framebuffer Capture||nvidia-driver-NvFBCOpenGL||nvidia-driver-NvFBCOpenGL|
|kmod-nvidia (el6 only)||-|
|32 bit compatibility|
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.
To install the repository on a supported Fedora distribution, run as root the following command:
wget http://negativo17.org/repos/fedora-nvidia.repo -O /etc/yum.repos.d/fedora-nvidia.repo
To install the repository on CentOS/RHEL:
wget http://negativo17.org/repos/epel-nvidia.repo -O /etc/yum.repos.d/epel-nvidia.repo
First of all remove all the Nvidia drivers you might have on your sistem due to RPMFusion or EPEL. The packages should already take care of this for you, but better be safe than sorry. This is usually accomplished with the following root command:
yum -y remove \*nvidia\*
Then, to install the nvidia-driver packages in Fedora or CentOS/RHEL, perform the following command:
yum -y install nvidia-driver
Specific package installations
For both Fedora and CentOS/RHEL distributions it’s possible to install additional packages and / or variant of the basic kernel modules. This paragraph contains some examples.
Make sure you have the RPMFusion repository enabled if you plan to use AKMOD kernel modules:
yum -y install nvidia-driver akmod-nvidia
To install in CentOS/RHEL with the binary kABI (Kernel ABI whitelist) module:
yum -y install nvidia-driver kmod-nvidia
To add 32 bit libraries on a 64 bit system (for games or applications like Steam):
yum -y install nvidia-driver-libs.i686
To use the Nvidia driver with the DKMS enabled kernel module (on CentOS/RHEL it requires the EPEL repository being enabled):
yum -y install nvidia-driver dkms-nvidia
To install CUDA support:
yum -y install nvidia-driver-cuda
To install CUDA 32 bit support on a 64 bit system:
yum -y install nvidia-driver-cuda-libs.i686
Enabling multiple (instantiated) kernel modules
Version 325 and newer of the drivers support multiple kernel modules for driving multiple GPUs in a single system. According to the documentation; this helps when separate GPUs are intended to process independent workloads in a single system.
Multiple kernel modules are supported on the DKMS and aKMOD variant of the kernel packages. Binary kMOD packages are not generated for RHEL/CentOS as the required kernel symbols are not inserted in the package at build time and would result in a ~100 mb download of kernel modules even if the system is used for normal desktop usage.
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-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:
To revert to the single kernel module just remove the
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-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
The address for contacting me is in the package’s changelog.