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.
- 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-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 NVIDIA OpenGL-based Framebuffer Capture (NvFBCOpenGL) libraries (NvFBC and NvIFR) are private APIs that are only available to NVIDIA approved partners for use in remote graphics scenarios (i.e. Steam In-Home Streaming hardware encoding); so they are packaged in another small package called
nvidia-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.
- Starting from version 343.13, the
nvidia-settingsbinary 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
- 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 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 (x86_64 systems only).
- 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-develpackages. Installing these, the
gpu-deployment-kitdependency provided by the CUDA repositories is preserved.
- Along with NVML, the
nvidia-healthmonpackage is provided to monitor TESLA GPU clusters (x86_64 systems only).
- Included is also the NVENC (Nvidia Encoder) header, docs and code samples. Again, this uses a different version than the drivers.
- 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 (up to 352.xx); 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-modprobecommand in the system to create devices and set permissions, so the new optional package has been added.
- UDev rule to autoload the
- 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.
- 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
- 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.conffile. This also removes editing of the
xorg.conffile from the package scriptlets.
- Add the
IgnoreABIdirective by default on Fedora rawhide builds.
Here is a rundown of Nvidia supported drivers and options split by distribution:
|Operating system||el6 / el7||f22 / f23||f24|
|Driver branch||Long Lived||Short Lived|
|Basic nvidia driver:|
|CUDA libraries and tools:|
|OpenGL Framebuffer Capture:|
|32 bit compatibility on x86_64:|
Along with the CUDA tools and libraries:
|Operating system||el6 / el7||f21 / f22 / f23|
|Basic CUDA libraries/tools:|
|Java GUI programs:|
Sample installation on an office laptop
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.
To install the repository on a supported Fedora 22+ distribution, run as root the following command:
dnf config-manager --add-repo=http://negativo17.org/repos/fedora-nvidia.repo
To install the repository on CentOS/RHEL:
If you are booting the system in UEFI mode; as a prerequisite to installing any external module (not built into the kernel package), you have to disable UEFI Secure Boot in the system configuration. All modules contained in the kernel package are signed with keys that are generated during build and deleted when packaging. If you want to preserve Secure Boot, you need to sign the modules yourself and import the keys into your hardware module. Doing so is out of scope here; if you need a decent guide just follow Red Hat’s guide for signing kernel modules.
First of all remove all the Nvidia drivers you might have on your sistem due to RPMFusion, ELRepo, 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
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 just a runtime CUDA support (required for running CUDA enabled programs):
yum -y install cuda nvidia-driver-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-NVML-devel
Enabling multiple (instantiated) kernel modules (up to driver 352.xx)
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.
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.