Oh no, another Nvidia driver repository? Why? This repository 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.
Table of Contents
Repository installation
To install the repository on a supported Fedora distribution, run as root the following command:
dnf config-manager --add-repo=https://negativo17.org/repos/fedora-nvidia.repo
To install the repository on CentOS/RHEL:
yum-config-manager --add-repo=https://negativo17.org/repos/epel-nvidia.repo
The Nvidia software packages are available for installation by default also in Gnome Software.
Please note that the driver will show up only if your system matches one of the PCI ID supported by the driver. Otherwise, only the other Nvidia programs (mostly for CUDA development) will show up in the software center.
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.
What follows below, is a detailed explanation of all the “differences” from the various Nvidia driver packages that I was able to spot on the web and a detailed description on how to install components, etc.
Nvidia drivers
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.
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-driver-NvFBCOpenGL. - The
nvidia-settingspackage now builds the externallibXNVCtrl.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. - The
nvidia-settingsbinary is compiled with GTK3 instead of GTK2 on Fedora and RHEL/CentOS 7+. - The driver can be installed separately from the
nvidia-settingsutility, so if you simply want a working driver and do not care about details, your experience should be as close as possible to the one with open source drivers.
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/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 ~120 MB worth of installed libraries. nvidia-persistenced falls in this category as it’s not needed 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).
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.
- The Nvidia udev rules leverage
nvidia-modprobecommand in the system to create devices and set permissions even when the userspace libraries have not been loaded yet, covering the case of Wayland only sessions and compute only system without display userspace components installed. - The
nvidia-uvmmodule has a soft dependency on thenvidiamodule, making sure that these modules are not included in the initrd (thing that would happen by using systemd’s configuration (module-s-load.d). UDev rules make sure the module has proper permissions. - Choice of proprietary or open source license kernel modules.
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.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.
- Use new OutputClass directive on 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 thexorg.conffile from the package scriptlets. This does not hardcode the 96 DPI resolution. - Add the
IgnoreABIdirective by default on Fedora rawhide builds.
Kernel modesetting and Wayland support
Kernel mode setting on the nvidia-drm module is enabled by default along with the console frame buffer driver.
Distribution and Nvidia driver version support
Here is a rundown of Nvidia supported drivers and options split by distribution. Basically, CentOS/RHEL will always get a Long Lived branch release if possible, Fedora always a Short Lived branch release, and unreleased distributions will always get a Beta driver.
| Operating system | CentOS / RHEL | Fedora | rawhide |
|---|---|---|---|
| Driver branch | Long Lived | Short Lived Long Lived | Short Lived Long Lived Beta |
| Video Codec SDK | Yes | Yes | Yes |
| Architectures: x86_64 aarch64 | Yes | Yes | Yes |
| Basic nvidia driver: nvidia-driver nvidia-driver-libs nvidia-libXNVCtrl nvidia-kmod-common | Yes | Yes | Yes |
| CUDA libraries and tools: libnvidia-ml nvidia-driver-cuda nvidia-driver-cuda-libs nvidia-persistenced | Yes | Yes | Yes |
| OpenGL Framebuffer Capture: libnvidia-fbc | Yes | Yes | Yes |
| Nvidia tools: nvidia-modprobe nvidia-settings nvidia-xconfig | Yes | Yes | Yes |
| Binary kernel modules (kABI): kmod-nvidia | Yes | No | No |
| DKMS kernel modules: dkms-nvidia | Yes | Yes | Yes |
| aKMOD kernel modules: akmod-nvidia | No | Yes | Yes |
| 32 bit compatibility on x86_64: libnvidia-ml nvidia-libXNVCtrl nvidia-driver-libs nvidia-driver-cuda-libs | Yes | Yes | Yes |
| VDPAU libraries | Yes | Yes | Yes |
| EGLStream-based Wayland external platform | Yes | Yes | Yes |
| GBM EGL external platform library | Yes | Yes | Yes |
Optimus laptops
The driver should install and operate cleanly whether you are installing it on a system which has one or more discrete Nvidia cards or an Optimus laptop with an Intel and a Nvidia card. Nothing to do to enable or configure Optimus.
This is up to the point that when the drivers are installed, you can even turn off Optimus on or off in your system Bios (if your laptop allows that) and the only difference you should see is that there’s an additional VGA card enabled in your system (check with lspci) and that the Nvidia control panel switches between a PRIME Display, like in this picture:
And a normal RandR managed one, like in this one:
Everything else should not be different from your normal experience.
Limitations with the Nvidia driver
The limitations are the same as provided by the Nvidia driver, this means that if you are running it on an Optimus laptop, the Intel card can never power off. Which means higher power consumption, unfortunately. If you have an Optimus laptop and absolutely need the proprietary drivers, my suggestion is still to disable Optimus in the Bios.
Limitations with the OSS stack
On the contrary, if you use the OSS stack (nouveau/intel) the second card can be powered off if there’s no application running on it or display directly connected to one of the card’s outputs. That’s the best reason to use the OSS drivers at all if you you’re not doing serious gaming or 3D work:
$ sudo cat /sys/kernel/debug/vgaswitcheroo/switch 0:IGD:+:Pwr:0000:00:02.0 1:DIS: :DynOff:0000:01:00.0
You also got the nifty selection menu about running your game on the discrete card on Gnome, which is really cool:
It will power up the video card just before launching the process. Launching a program through that menu entry is like starting it from the command line with the DRI_PRIME variable declared. For example, the same as above would be:
$ DRI_PRIME=1 quake3 & $ sudo cat /sys/kernel/debug/vgaswitcheroo/switch 0:IGD:+:Pwr:0000:00:02.0 1:DIS: :DynPwr:0000:01:00.0
As you can see, the discrete video card is turned on. For Steam, you still need to edit each of your game to run on the Nvidia card:
SLI systems
SLI is now enabled by default with the Auto profile, there’s nothing to do if you have a SLI system. If you need any different SLI option (AA, SFR, etc.), just override it in X.org configuration files.
Nouveau fallback
With the new expanded OutputClass support for X, as carried out by Hans, it’s now super easy to switch to the OSS stack if the proprietary Nvidia driver somehow does not work. No user space component is touched, as soon as the Nvidia kernel module is not loaded (check on /sys/module/nvidia), the desktop starts with the normal OSS components you get with a normal installation. Thanks to all the work done on libglvnd, the libraries loaded are the correct one for the driver you are running.
This means that the performance of the Nvidia card would be abysmal, but still you would get a nice desktop and browser to Google around for answers on how to fix it :).
Sample installation
Here is an example. Let’s assume you have a freshly installed CentOS system with a recent Nvidia GPU and you want to:
- Install the driver for gaming
- Play Vulkan enabled games
- Want to be comfortable with the Nvidia control panel
- Play 32 bit games (Vulkan included) on a 64 bit system
- Play 32 bit Vulkan games on a 64 bit system
# yum install nvidia-driver nvidia-driver-libs.i686 Last metadata expiration check: 0:05:30 ago on Tue 05 Feb 2019 06:52:50 AM CET. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: nvidia-driver x86_64 3:415.27-4.fc29 fedora-multimedia 2.4 M nvidia-driver-libs i686 3:415.27-4.fc29 fedora-multimedia 18 M Installing dependencies: akmod-nvidia x86_64 3:415.27-1.fc29 fedora-multimedia 10 M nvidia-driver-cuda-libs x86_64 3:415.27-4.fc29 fedora-multimedia 25 M nvidia-driver-libs x86_64 3:415.27-4.fc29 fedora-multimedia 34 M nvidia-kmod-common noarch 3:415.27-1.fc29 fedora-multimedia 10 k akmods noarch 0.5.6-17.fc29 updates 22 k egl-wayland x86_64 1.1.1-3.fc29 updates 29 k kernel-devel x86_64 4.20.6-200.fc29 updates 13 M mesa-libEGL i686 18.2.8-1.fc29 updates 112 k mesa-libgbm i686 18.2.8-1.fc29 updates 39 k libglvnd-egl i686 1:1.1.0-2.fc29 fedora 45 k libglvnd-gles i686 1:1.1.0-2.fc29 fedora 32 k libglvnd-opengl i686 1:1.1.0-2.fc29 fedora 37 k libglvnd-opengl x86_64 1:1.1.0-2.fc29 fedora 39 k libva-vdpau-driver x86_64 0.7.4-22.fc29 fedora 60 k libwayland-server i686 1.16.0-1.fc29 fedora 38 k Transaction Summary ================================================================================ Install 17 Packages Total download size: 103 M Installed size: 385 M Is this ok [y/N]:
As you can see, this system has akmod enabled kernel modules 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.
Package installation
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 system due to RPMFusion, ELRepo, or the Nvidia CUDA repository. This is usually accomplished with the following root command:
yum -y remove *nvidia*
Then, to install the Nvidia driver and its control panel utility in CentOS/RHEL with the binary kABI (Kernel ABI whitelist) module (this is the default on CentOS/RHEL), perform the following command:
yum -y install nvidia-driver nvidia-settings
To do the same in Fedora, using akmod modules, perform the following command:
dnf -y install nvidia-driver nvidia-settings
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 EPEL repository enabled if you plan to use DKMS modules on CentOS/RHEL.
akmod kernel module variant (Fedora):
dnf -y install nvidia-driver akmod-nvidia
DKMS kernel module variant (Fedora/CentOS/RHEL):
yum/dnf -y install nvidia-driver dkms-nvidia
To add 32 bit libraries on a 64 bit system (for games or applications like Steam):
yum/dnf -y install nvidia-driver-libs.i686
Proprietary and open source kernel modules
Since almost a year, the Nvidia driver ships with two different implementations of the kernel modules, one proprietary and one open source. The open source one as of drivers 545.x is now considered beta quality also for the workstations, so it seems a good moment to start shipping it.
The open source one is supposed to be the only one that will be kept in the future, but at the moment both are available and both differ in terms of functionality. You can read about the main differences in terms of functionality and what chips they support in the official documentation.
I did not want to introduce another variation of the kernel modules beside akmods, kABI and DKMS, this would have created even more confusion and lots of dependencies in the SPEC files for the variations. The new akmod and DKMS packages ship both sources (MIT/GPL and proprietary kernel modules) and allow you to switch between one or the other through a configuration file.
Considering that in the long run only the open source variant will remain, I wanted to make this as transparent as possible for the users. Basically, if you don’t care and just want something that works, nothing has changed for you.
The two sources get referenced as they are referenced inside the Nvidia run file, namely “kernel” for the original proprietary kernel modules and “kernel-open” for the new open source variation.
The following instructions show you how to switch between one implementation or the other.
DKMS
Check which version you have installed:
# modinfo -l nvidia
NVIDIAChange the type of modules you want to use and trigger a rebuild and a reinstall:
# sed -i -e 's/kernel$/kernel-open/g' /etc/nvidia/kernel.conf
# dkms build -m nvidia/545.29.02 --force
# dkms install -m nvidia/545.29.02 --forceNow check again the license and you should see that it has changed to MIT/GPL:
# modinfo -l nvidia
Dual MIT/GPL
# rebootTo switch back, change the configuration again and then trigger the same process for rebuilding installing:
# sed -i -e 's/kernel-open$/kernel/g' /etc/nvidia/kernel.conf
# dkms build -m nvidia/545.29.02 --force
# dkms install -m nvidia/545.29.02 --force
# rebootakmods
Check which version you have installed:
# modinfo -l nvidia
NVIDIAChange the type of modules you want to use and trigger a rebuild and a reinstall:
# sed -i -e 's/kernel$/kernel-open/g' /etc/nvidia/kernel.conf
# akmods --rebuildNow check again the license and you should see that it has changed to MIT/GPL:
# modinfo -l nvidia
Dual MIT/GPL
# rebootTo switch back, change the configuration again and then trigger the same process for rebuilding installing:
# sed -i -e 's/kernel-open$/kernel/g' /etc/nvidia/kernel.conf
# akmods --rebuild
# rebootAdditional driver configuration to your system
To add additional configuration to your system, just create the /etc/X11/xorg.conf file. For example:
Section "Device"
Identifier "Device0"
Driver "nvidia"
Option "NoLogo" "true"
Option "DPI" "96 x 96"
Option "SLI" "Auto"
Option "nvidiaXineramaInfoOrder" "DFP-0"
Option "metamodes" "GPU-a493fbbb-7d76-86a2-8764-d76d487a75a7.DVI-I-1: nvidia-auto-select +0+0, GPU-c02960a4-be28-d5ce-8b02-be04b5e2550b.DVI-I-1: nvidia-auto-select +1680+0"
Option "BaseMosaic" "on"
EndSection
In this example we have 2 video cards with one monitor each, so we enabled SLI, Base Mosaic to have multi monitor support on SLI and make a layout with the second GPU monitor on the right of the first one. Also, we fix the DPI to 96×96, which is the hardcoded default in Gnome and in Open Source drivers.
Configuration for CUDA only systems
Your system might only be used for CUDA development and not require the X server to be running the DDX driver at all, so you might want to tweak the configuration a bit to make the system load (for example) the Intel driver as the main display and just the Nvidia driver for GPU workloads. In this case you have two options.
Option with only CUDA components installed
To install just the CUDA components of the driver and not the OpenGL libraries and all files required by the DDX part of the driver, proceed to install as follows:
# yum install nvidia-driver-cuda Last metadata expiration check: 0:22:51 ago on Tue 05 Feb 2019 06:52:50 AM CET. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: nvidia-driver-cuda x86_64 3:415.27-4.fc29 fedora-multimedia 308 k Installing dependencies: akmod-nvidia x86_64 3:415.27-1.fc29 fedora-multimedia 10 M nvidia-driver-NVML x86_64 3:415.27-4.fc29 fedora-multimedia 457 k nvidia-driver-cuda-libs x86_64 3:415.27-4.fc29 fedora-multimedia 25 M nvidia-kmod-common noarch 3:415.27-1.fc29 fedora-multimedia 10 k nvidia-persistenced x86_64 3:415.27-2.fc29 fedora-multimedia 40 k akmods noarch 0.5.6-17.fc29 updates 22 k kernel-devel x86_64 4.20.6-200.fc29 updates 13 M Transaction Summary ================================================================================ Install 8 Packages Total download size: 49 M Installed size: 168 M Is this ok [y/N]:
As you can see, there are no components providing OpenGL or DDX drivers installed on the system. This will not use any X (or Wayland) configuration compared to what has been installed by default on your system.
On top of this, you can still select what kind of kernel modules you want ot have installed (kABI, akmods and dkms).
The device files are created by the udev rules that call the nvidia-modprobe command, it contains a SUID binary that creates the device files and set the appropriate permissions. The same binary is called directly by Nvidia libraries when accessing a user space component that would require device files access:
$ for i in $(rpm -ql nvidia-driver-libs.x86_64 nvidia-driver-cuda-libs.x86_64 | grep \.so); do strings $i | grep nvidia-modprobe > /dev/null && echo $i done /usr/lib64/gbm/nvidia-drm_gbm.so /usr/lib64/libnvidia-allocator.so.1 /usr/lib64/libnvidia-allocator.so.545.29.02 /usr/lib64/libnvidia-api.so.1 /usr/lib64/libnvidia-cfg.so.1 /usr/lib64/libnvidia-cfg.so.545.29.02 /usr/lib64/libnvidia-eglcore.so.545.29.02 /usr/lib64/libnvidia-glcore.so.545.29.02 /usr/lib64/libnvidia-glsi.so.545.29.02 /usr/lib64/vdpau/libvdpau_nvidia.so.1 /usr/lib64/vdpau/libvdpau_nvidia.so.545.29.02 /usr/lib64/libcuda.so /usr/lib64/libcuda.so.1 /usr/lib64/libcuda.so.545.29.02 /usr/lib64/libnvcuvid.so /usr/lib64/libnvcuvid.so.1 /usr/lib64/libnvcuvid.so.545.29.02 /usr/lib64/libnvidia-opencl.so.1 /usr/lib64/libnvidia-opencl.so.545.29.02
This requires some testing and adjustments with specifics to your setup, but is definitely possible to use the integrated Intel card and or rely on a system without X installed to run the CUDA components.
CUDA
Packaging
- Previously in the repository was included the GPU Deployment kit. This was constructed with NVML (NVIDIA Management Library) headers, docs and samples from a separate tarball. The separate tarball was using a different version number than the drivers and was packaged in the
nvidia-driver-NVMLandnvidia-driver-NVML-develpackages. Starting from CUDA version 8, the NVML header is provided by a CUDA subpackage (cuda-nvml-devel) and no longer provided as part of the GPU Deployment kit. - Included is also the Video Codec SDK (Decoder/Encoder) headers, docs and code samples. Again, this uses a different version than the drivers.
- All the libraries are split into subpackages, much like in the original Nvidia CUDA repository. This allows you to install and build software relying on specific components without the need to install all the CUDA toolkit just to satisfy a library dependency. Also, for the same reason, static libraries have been included in each respective
staticsubpackage. - In addition to the libraries bundled in the CUDA toolkit, also the cuDNN library for distributed neural networks is included in the repository. See the table below for details.
Distribution and CUDA version support
All the currently supported Red Hat Enterprise Linux versions (including rebuilds and similar forks – CentOS Stream, AlmaLinux, RockyLinux, EuroLinux, etc.) and Fedora versions are available.
In case of yet unsupported compilers in recent distributions, a compatibility cuda-gcc package is available that brings the distribution to a working level with nvcc.
By installing the cuda-gcc package, a variable is loaded automatically that adds the appropriate NVCC options to override the default system GCC when compiling:
$ cat /etc/profile.d/cuda-gcc.sh
export NVCC_PREPEND_FLAGS='-ccbin /usr/bin/cuda'CUDA installations
To install just a runtime CUDA support (required for running CUDA enabled programs), without DDX drivers:
yum -y install cuda nvidia-driver-cuda
To just install packages required for enabling CUDA development:
yum -y install cuda-devel
Or if you just want to enable everything:
dnf/yum -y install nvidia-driver nvidia-driver-cuda cuda-devel
A couple of examples. Just the basic tools:
# yum install cuda Last metadata expiration check: 0:30:55 ago on Tue 05 Feb 2019 06:52:50 AM CET. Dependencies resolved. ================================================================================ Package Arch Version Repository Size
================================================================================ Installing: cuda x86_64 1:10.0.130-1.fc29 fedora-multimedia 17 M Installing dependencies: cuda-libs x86_64 1:10.0.130-1.fc29 fedora-multimedia 8.6 M nvidia-driver-cuda-libs x86_64 3:415.27-4.fc29 fedora-multimedia 25 M Transaction Summary ================================================================================ Install 3 Packages Total download size: 51 M Installed size: 178 M Is this ok [y/N]:
The basic tools along with all the libraries (note that the NVML headers are included):
# yum install cuda-devel Last metadata expiration check: 0:35:09 ago on Tue 05 Feb 2019 06:52:50 AM CET. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: cuda-devel x86_64 1:10.0.130-1.fc29 fedora-multimedia 1.6 M Installing dependencies: cuda x86_64 1:10.0.130-1.fc29 fedora-multimedia 17 M cuda-cublas x86_64 1:10.0.130-1.fc29 fedora-multimedia 31 M cuda-cublas-devel x86_64 1:10.0.130-1.fc29 fedora-multimedia 32 M cuda-cudart x86_64 1:10.0.130-1.fc29 fedora-multimedia 135 k cuda-cudart-devel x86_64 1:10.0.130-1.fc29 fedora-multimedia 533 k cuda-cufft x86_64 1:10.0.130-1.fc29 fedora-multimedia 64 M cuda-cufft-devel x86_64 1:10.0.130-1.fc29 fedora-multimedia 127 M cuda-cupti x86_64 1:10.0.130-1.fc29 fedora-multimedia 1.4 M cuda-cupti-devel x86_64 1:10.0.130-1.fc29 fedora-multimedia 226 k cuda-curand x86_64 1:10.0.130-1.fc29 fedora-multimedia 38 M cuda-curand-devel x86_64 1:10.0.130-1.fc29 fedora-multimedia 61 M cuda-cusolver x86_64 1:10.0.130-1.fc29 fedora-multimedia 40 M cuda-cusolver-devel x86_64 1:10.0.130-1.fc29 fedora-multimedia 15 M cuda-cusparse x86_64 1:10.0.130-1.fc29 fedora-multimedia 27 M cuda-cusparse-devel x86_64 1:10.0.130-1.fc29 fedora-multimedia 28 M cuda-libs x86_64 1:10.0.130-1.fc29 fedora-multimedia 8.6 M cuda-npp-devel x86_64 1:10.0.130-1.fc29 fedora-multimedia 58 M cuda-nvgraph x86_64 1:10.0.130-1.fc29 fedora-multimedia 68 M cuda-nvgraph-devel x86_64 1:10.0.130-1.fc29 fedora-multimedia 13 k cuda-nvjpeg x86_64 1:10.0.130-1.fc29 fedora-multimedia 372 k cuda-nvjpeg-devel x86_64 1:10.0.130-1.fc29 fedora-multimedia 14 k cuda-nvml-devel x86_64 1:10.0.130-1.fc29 fedora-multimedia 53 k cuda-nvrtc x86_64 1:10.0.130-1.fc29 fedora-multimedia 6.3 M cuda-nvrtc-devel x86_64 1:10.0.130-1.fc29 fedora-multimedia 15 k cuda-nvtx x86_64 1:10.0.130-1.fc29 fedora-multimedia 33 k cuda-nvtx-devel x86_64 1:10.0.130-1.fc29 fedora-multimedia 41 k nvidia-driver-NVML x86_64 3:415.27-4.fc29 fedora-multimedia 457 k nvidia-driver-cuda-libs x86_64 3:415.27-4.fc29 fedora-multimedia 25 M Transaction Summary ================================================================================ Install 29 Packages Total download size: 650 M Installed size: 1.6 G Is this ok [y/N]:
An example where your CUDA application just uses the CUDA Runtime API and not the kernel runtime:
$ sudo dnf install cuda-cudart Last metadata expiration check: 0:13:10 ago on Sun Oct 23 13:11:01 2016. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: cuda-cudart x86_64 1:8.0.44-4.fc24 fedora-nvidia 131 k Transaction Summary ================================================================================ Install 1 Package Total size: 131 k Installed size: 536 k Is this ok [y/N]:
This will avoid you pulling in all the libraries as before just because you need a single library. This is useful for example for programs that leverage just some part of the CUDA toolkit, like the Nvidia Performance Primitives for image and signal processing in FFmpeg, and similar things.
Bugs
Just open an issue to the specific package on GitHub.
Any chance of rolling back to the last driver version? gnome-shell keeps crashing when GDM tries to start up with nvidia-driver-355.11-1.fc23.x86_64 on Fedora 22 and Fedora 23 with a GeForce GTX 780 Ti. I checked the repo URL to see if I could roll back manually but I don’t see previous versions.
[ 229.817576] traps: gnome-shell[5128] trap int3 ip:7f12a32668eb sp:7ffecc8db420 error:0
[ 233.605400] traps: gnome-shell[5165] trap int3 ip:7fdcf08c28eb sp:7fff89b1b500 error:0
[ 237.459072] traps: gnome-shell[5202] trap int3 ip:7fc7ee1878eb sp:7ffe00da84b0 error:0
[ 241.272302] traps: gnome-shell[5239] trap int3 ip:7efc51e528eb sp:7ffd321776e0 error:0
[ 245.121385] traps: gnome-shell[5277] trap int3 ip:7f97499cc8eb sp:7ffdd0b43650 error:0
on Fedora 22 and Fedora 23.
There is no previous version, but this does not seem to be related to the drivers. Do you have any additional X.org configuration apart from the one provided by the drivers?
No additional X.org configuration other than what nvidia-driver provides.
I was able to get more out of journalctl andit seems that it can’t find the drm kms device with the new driver. It was working fine with the previous driver.
Sep 24 15:48:31 desktop systemd[1]: Started User Manager for UID 42.
Sep 24 15:48:31 desktop gnome-session[2431]: (gnome-shell:2437): mutter-ERROR **: could not find drm kms device
Sep 24 15:48:31 desktop kernel: traps: gnome-shell[2437] trap int3 ip:7f54c24fa8eb sp:7fffff26dd20 error:0
Sep 24 15:48:38 desktop systemd-coredump[2441]: Process 2437 (gnome-shell) of user 42 dumped core.
Stack trace of thread 2437:
#0 0x00007f54c24fa8eb g_logv (libglib-2.0.so.0)
#1 0x00007f54c24faa5f g_log (libglib-2.0.so.0)
#2 0x00007f54c622b9bb meta_launcher_new (libmutter.so.0)
#3 0x00007f54c62269e8 meta_backend_native_init (libmutter.so.0)
#4 0x00007f54c2816b09 g_type_create_instance (libgobject-2.0.so.0)
#5 0x00007f54c27f7ebb g_object_new_internal (libgobject-2.0.so.0)
#6 0x00007f54c27f97d1 g_object_newv (libgobject-2.0.so.0)
#7 0x00007f54c27fa104 g_object_new (libgobject-2.0.so.0)
#8 0x00007f54c61b9846 meta_clutter_init (libmutter.so.0)
#9 0x00007f54c61ec782 meta_init (libmutter.so.0)
#10 0x00007f54cb6a843a main (gnome-shell)
#11 0x00007f54c0916580 __libc_start_main (libc.so.6)
#12 0x00007f54cb6a8849 _start (gnome-shell)
Stack trace of thread 2439:
#0 0x00007f54c09ed11d poll (libc.so.6)
#1 0x00007f54c24f423c g_main_context_iterate.isra.29 (libglib-2.0.so.0)
#2 0x00007f54c24f434c g_main_context_iteration (libglib-2.0.so.0)
#3 0x00007f54c24f4389 glib_worker_main (libglib-2.0.so.0)
#4 0x00007f54c251ab25 g_thread_proxy (libglib-2.0.so.0)
#5 0x00007f54c0cbe60a start_thread (libpthread.so.0)
#6 0x00007f54c09f8bbd __clone (libc.so.6)
Stack trace of thread 2440:
#0 0x00007f54c09ed11d poll (libc.so.6)
#1 0x00007f54c24f423c g_main_context_iterate.isra.29 (libglib-2.0.so.0)
#2 0x00007f54c24f45c2 g_main_loop_run (libglib-2.0.so.0)
#3 0x00007f54c39a54a6 gdbus_shared_thread_func (libgio-2.0.so.0)
#4 0x00007f54c251ab25 g_thread_proxy (libglib-2.0.so.0)
#5 0x00007f54c0cbe60a start_thread (libpthread.so.0)
#6 0x00007f54c09f8bbd __clone (libc.so.6)
Sep 24 15:48:38 desktop gnome-session[2431]: Unrecoverable failure in required component gnome-shell-wayland.desktop
Sep 24 15:48:38 desktop systemd-logind[1405]: Removed session c6.
Sep 24 15:48:38 desktop /usr/libexec/gdm-wayland-session[2427]: Activating service name=’org.gtk.vfs.Daemon’
Sep 24 15:48:38 desktop /usr/libexec/gdm-wayland-session[2427]: Successfully activated service ‘org.gtk.vfs.Daemon’
Sep 24 15:48:38 desktop /usr/libexec/gdm-wayland-session[2427]: Activating service name=’ca.desrt.dconf’
Sep 24 15:48:38 desktop gnome-session[2431]: gnome-session[2431]: WARNING: Application ‘gnome-shell-wayland.desktop’ killed by signal 5
Sep 24 15:48:38 desktop org.gtk.vfs.Daemon[2429]: A connection to the bus can’t be made
Sep 24 15:48:38 desktop systemd[1]: Stopping User Manager for UID 42…
Have you tried disabling Wayland support in GDM? Your system is looking for a KMS driver but Nvidia provides none yet.
Hi, Thanks for the repo.
I am just having one issue, I am trying to make my monitor layout stay after reboot.
I created a .conf file under /etc/X11/xorg.conf.d/
with the following:
Section “Monitor”
# HorizSync source: edid, VertRefresh source: edid
Identifier “Monitor0”
VendorName “Unknown”
ModelName “DELL 2208WFP”
HorizSync 30.0 – 83.0
VertRefresh 56.0 – 76.0
Option “DPMS”
EndSection
Section “Screen”
Identifier “Screen0”
Device “Device0”
Monitor “Monitor0”
DefaultDepth 24
Option “Stereo” “0”
Option “nvidiaXineramaInfoOrder” “DFP-0”
Option “metamodes” “DVI-D-0: nvidia-auto-select +2970+480, DVI-I-1: nvidia-auto-select +1050+480, HDMI-0: nvidia-auto-select +0+0 {rotation=left}”
Option “SLI” “Off”
Option “MultiGPU” “Off”
Option “BaseMosaic” “off”
SubSection “Display”
Depth 24
EndSubSection
EndSection
but still no luck. Am I doing something wrong?.. still new to fedora and linux.
Thanks.
Hi.
What it could http://www.youtube.com/watch?v=bcgvjg0OaXA
(this odd but when I try to make video using gnome screencast this issue did’t appears)
Appears only on fullscreen apps and nvidia blob;
this box have fresh fedora 22 setup and nvidia quadro 4000.
This seems something specifically driver related. You should ask for help on the Nvidia forum.
This seems to work now, two additional packages are showing up now with dnf update:
libglvnd.x86_64 0.0.0-3.fc22
nvidia-driver-NVML.x86_64 2:355.11-1.fc22
Hi, the newest update fails to find all files I guess. GDM crashed, only 2D acceleration was enabled and I got this error:
(II) LoadModule: “glx”
(II) Loading /usr/lib64/nvidia/xorg/libglx.so
(EE) Failed to load /usr/lib64/nvidia/xorg/libglx.so: libnvidia-tls.so.352.30: cannot open shared object …
I tried simply symlinking and it seems to work now:
ln -s /usr/lib64/libnvidia-tls.so.352.30 /usr/lib64/nvidia/xorg/
There is something wrong with your system, that is absolutely not needed. Libraries are loaded through ldconfig, and if your system would not be able to find libraries in
/usr/lib64it would not boot at all. Or you have screwed your permissions in/usr/lib64/libnvidia*or you have some other issue, because permissions are correct inside the package.$ rpm -qpvl nvidia-driver-libs-352.30-3.fc22.x86_64.rpm | grep tls-rwxr-xr-x 1 root root 12912 Jul 22 03:25 /usr/lib64/libnvidia-tls.so.352.30
Your problem is not related to the packages.
I think it happened because I tried to install both the driver and the 32bit libs at once. This happened on a new system again, and when I installed just the driver first, it worked fine.
You install instructions are missing key information for novice user like me or dozen others. You say to install driver install only “nvidia-driver” package, but that will not work. What about adding “nvidia-driver-libs”? How many users were left with broken computer unable to boot?
The instructions are correct, it’s that with the latest library reorganization I accidentally deleted the
nvidia-driver-libsrequirement innvidia-driver. It is fixed now and the libraries are installed automatically (as it was last week).OK thanks.. Sorry for rant. I asume i will also need dkms-nvidia if kernel gets updated in the future?
You can use both DKMS or aKMOD, your choice. By default the first one providing
nvidia-kmodgets pulled in, so in alphabetical order isakmod-nvidiathendkms-nvidiain Fedora, and binarykmod-nvidiaanddkms-nvidiaon CentOS/RHEL. Please read the repository page for instructions.Hmm i quite don´t understand, even if i have Googled for differences between KMOD, AKMOD and DKMS. I guess i was dumbed down by Ubuntu 🙂 where i didn´t needed to choose anything and nvidia driver was one-click install in Additional Drivers GUI. So i have installed “nvidia-driver”, “nvidia-driver-libs” both 32/64 bit for Steam and now which kernel module you recommend to install for future so my system will boot after kernel update, KMOD or DKMS?
If you have installed nvidia-driver, then you already have some module, as it’s automatic. That’s the point, you should not worry about it if you don’t know the differences. Try this to see what’s installed:
$ rpm -qa \*nvidia\* | sortWow. Thanks.
I’m running Fedora 22 and no other option has worked + 32-bit rendering.
This worked first time.
So, finally I’ve removed the proprietary driver and installed again nouveau… it seems this has basic support for optimus (at least I can use digital output of my docking which was not working with intel only config), so if it will be stable enough I’ll stay with open source again 🙂
Hi,
After playing a bit with optimus/bumblebee I’ve found I really don’t need this and it is more pain than gain 🙂 So, I’ve removed everything installed by this, and moved back to negativo’s repo. Unfortunately my cinnamon/gnome crashes maybe due to some version conflict.
I have messages like this
glxgearsError: couldn't get an RGB, Double-buffered visual
glxinfo64name of display: :0.0
Error: couldn't find RGB GLX visual or fbconfig
less /var/log/Xorg.0.log | grep gl[ 92.159] (WW) "glamoregl" will not be loaded unless you've specified it to be loaded elsewhere.
[ 92.159] (II) "glx" will be loaded by default.
[ 92.159] (II) LoadModule: "glx"
[ 92.159] (II) Loading /usr/lib64/nvidia/xorg/libglx.so
[ 92.159] (EE) Failed to load /usr/lib64/nvidia/xorg/libglx.so: libnvidia-tls.so.352.30: cannot open shared object file: No such file or directory
[ 92.159] (II) UnloadModule: "glx"
[ 92.159] (II) Unloading glx
[ 92.159] (EE) Failed to load module "glx" (loader failed, 7)
dnf list installed |grep nvidia
akmod-nvidia.x86_64 2:352.30-1.fc22 @System
kmod-nvidia-4.1.4-200.fc22.x86_64.x86_64
nvidia-driver.x86_64 2:352.30-2.fc22 @System
nvidia-libXNVCtrl.x86_64 2:352.30-1.fc22 @System
nvidia-settings.x86_64 2:352.30-1.fc22 @System
my system is 4.1.4-200.fc22.x86_64
Any idea?
Thanks
Seems, it is solved by
dnf --best install nvidia-driver-libs-2\:352.30-2.fc22ldd ./libglx.solinux-vdso.so.1 (0x00007ffc741e8000)
libnvidia-tls.so.352.30 => /lib64/libnvidia-tls.so.352.30 (0x00007f2e5733f000)
libnvidia-glcore.so.352.30 => /lib64/libnvidia-glcore.so.352.30 (0x00007f2e548ac000)
libc.so.6 => /lib64/libc.so.6 (0x00007f2e544ec000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f2e542e8000)
libm.so.6 => /lib64/libm.so.6 (0x00007f2e53fe0000)
/lib64/ld-linux-x86-64.so.2 (0x00005556b0291000)
nvidia-driver-libsit’s a dependency ofnvidia-driver, this means you have forced installation of the main package ignoring the rest as it is normally automatically pulled in.Also, don’t forget to install
nvidia-driver-libs.i686if you want to play Steam games 🙂Now, everything is installed from negativo repo, and there is no major error in my logs, however it seems glx extensions is missing/not working… do you have any idea how to fix it?
Usually it’s an all in one, either you have OpenGL/GLX Nvidia libraries loaded or not. You can not have “some glx extensions”. What extensions are you referring to?
Hi, I just installed Fedora22 64bit on my desktop PC with Nvidia GTX480.
I updated all packages before attempting to install your nvidia driver like this:
dnf remove \*nvidia\*
dnf install nvidia-driver
GDM crashed at boot, and journalctl showed that there was no 3D acceleration available.
I tried ‘akmods –force’ and it showed that the module was OK.
‘nvidia-driver-libs’ were not installed however, after installing them manually, GDM went fine.
Thank you for your work!
Regards,
Sladi
Hello, yes, unfortunately with the latest library reorganization I accidentally deleted the
nvidia-driver-libsrequirement innvidia-driver. It is fixed now and the libraries are installed automatically.great! works! all other attempts failed…
You have saved me! could not get graphics working properly on my new HP Zbook 17 G2. Your repo worked perfectly!
oh dear… as of 4.0.7-300.fc22.x86_64 “which updated automatically” this stopped working for me..
i have redone all the above with no success…
i get plasma crashing on me “no menus etc..”
and no second diaplay despite rebuilding the modules…
dell inspiron 17 7000 series “Optimus” type…
08:00.0 3D controller: NVIDIA Corporation Device 1344 (rev ff) (prog-if ff)
!!! Unknown header type 7f
Kernel modules: nouveau, nvidia
> Kernel modules: nouveau, nvidia
You can not load nouveau and nvidia at the same time.
sorry i did notice that and decided to start from scratch…
to that end i have done the following:
yum -y remove \*nvidia\*
and
yum -y install nvidia-driver
Kernel params in grub = rd.driver.blacklist=nouveau nomodeset
this should give me a clean starting point….
I now have both displays working.
However when I login plasma crashes and I get screen scrolling rapidly on the laptop almost to a blur.
Lspci -vv shows kernel driver in use nvidia
Kernel modules: nouveau, nvidia
Not sure where it’s getting nouveau from as I can’t find any reference to it.
I should mention that I’m not too clued up on this sort of issue. It’s just always worked for me.
To enable the fix now, you can just do:
dnf --enablerepo=updates-testing update clutter\*thanks !
The crash issue has been fixed in:
clutter >= 1.22.4
clutter-gtk >= 1.6.2.
Which is currently being pushed to stable:
https://admin.fedoraproject.org/updates/FEDORA-2015-10997/clutter-1.22.4-1.fc22,clutter-gtk-1.6.2-1.fc22
Can you try the following?
$ CLUTTER_BACKEND=x11 totem
$ CLUTTER_BACKEND=x11 gnome-maps
I’m not on a Nvidia equipped computer at the moment and do not have a chance to check until evening.
https://bbs.archlinux.org/viewtopic.php?id=196029
Does anybody else has problem with totem that crashes after installing the drivers on F22 ?
(totem:2936): Gdk-ERROR **: The program ‘totem’ received an X Window System error.
This probably reflects a bug in the program.
The error was ‘BadMatch (invalid parameter attributes)’.
(Details: serial 393 error_code 8 request_code 153 (GLX) minor_code 31)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
and the same with gnome-maps…
Thank you!!! This works amesomely on Fedora 22!!!
I’m running Fedora 22. I have a GT240 card, and am using the 340 branch. I also had to manually run
/usr/sbin/akmods –kernels 4.0.5-300.fc22.x86_64
Until now I have had to keep rebooting into the older 4.0.4 kernel, because the modules for 4.0.5 did not build.
Thank you sadsfae for the tip!!!
Hi there, great tutorial you’ve got here. Unfortunately, I still can’t use my nvidia gpu. Info: Running fedora 22 dual boot with win7, all non uefi, Asus k55 laptop, i7 with a gtx 850M. There’s no way to change between gpus in BIOS. Kernel 4.0.5-300.fc2.x86_64
Here’s what’s happening, with the nouveau drivers, the battery life sucks, running cs go in fedora is ridiculous, and, this happens very often, the noveau drivers give me a ton of errors at startup, so I have to turn off my laptop 2, 3 times before it fully boots. This is why I want to try different drivers, in this case, the Nvidia ones.
I’ve tried the bumblebee 2 times, and both times I had to reinstall fedora, I wasn’t able (probably because I’m ignorant) to undo what was done. But this time, with your tutorial, everything went fine when installing, I managed to run nvidia settings, had to install nvidia-xconfig, also ran that without any problem. when I rebooted my laptop, i couldn’t boot anymore.. I’m stuck in “A Start job is running for Wait for Plymouth Boot Screen to Quit (45s / no limit).
From here, i’m able to enter the console, remove the nvidia drivers, but still can’t boot.
If you could give me some help, I would appreciate it, because I’m not going to give up. I like these puzzles, but I’ve spent a good amount of time in this.. Oh, And I only started to mess with a linux os about 2 weeks ago, so go easy on me please 🙂
You should disable Optimus in your laptop, otherwise you’re asking for trouble and need to run a setup similar to this:
http://negativo17.org/complex-setup-with-nvidia-optimus-nouveau-prime-on-fedora-20/
I was able to install the drivers for my GT200GL Quadro FX3800 using the fedora-nvidia-340.repo on my HP Z800 Fedora 22 KDE dual screens and it was running OK until I did a dnf upgrade to load 322 updates. This loaded new kernel-4.0.5-300.fc22.x86_64 and kernel-devel-4.0.5-300.fc22.x86_64. I yum removed and yum -y install nvidia-driver but the window sessions would not come up. After unloading I get only a single lo resolution screen. Any suggestions? Thanks!
I used to have a Quadro card and only the 340 legacy drivers worked for me.
I believe the fedora-nvidia-340.repo is the legacy drivers as I had them working just fine, but I think they only work with the kernel prior to kernel-4.0.5-300.fc22.x86_64. Does the fedora-nvidia-340.repo have to be somehow updated in order to work with the new kernel?
Hello, thank you for building these and offering them to the public – it’s greatly appreciated.
For the latest Fedora 22 kernel (4.0.5-300) I had to run “/usr/sbin/akmods –force” to get the nvidia.ko to build as it did not do this automatically like in the past.
I’m not sure if this is something specific to kernel-4.0.5+ but this was not needed for prior 4.0.4* kernels. Hoping this helps someone.
FWIW I’m using a Geforce GTX 560 with the latest 352-series drivers.
Thanks again for providing these to the public.
I’m sorry but it’s not happening here (GTX 560ti x2 in SLI on same kernel). If the new driver comes along with the new kernel-devel package (i.e. when updating all together), the module will get built at next boot.
First of all, if you have an Optimus laptop, there’s no out of the box support.
If it is not, do you have an /etc/X11/xorg.conf file? You should not have one. From the line in your log it is not loading the module from the appropriate folder, and the thing is in the /etc/X11/xorg.conf.d/99-nvidia*.conf files.
It’s a desktop computer with a nVidia GeForce GTX 650 graphics card, rpm fusion drivers work with no issues out of the box.
There was no /etc/X11/xorg.conf file after installation (and reboot), there were two /etc/X11/xorg.conf.d/99-nvidia*.conf files. Everything as expected from the standard installation.
@slaanesh any idea why nvidia would fail on my desktop?
The nvidia drivers from rpmfusion works great… but I cannot make yours to work 🙁
Hello,
I have installed Fedora 22 (fresh install) and then tried to install nvidia drivers from your repository. As reported before – nvidia driver is not loaded after reboot and resolution drops to 1024×768 maximum… the only thing I did was:
dnf config-manager –add-repo=http://negativo17.org/repos/fedora-nvidia.repo
then:
yum -y install nvidia-driver
What do I need do to actually get the driver working?
Many thanks,
Marek
from the log file:
# cat /var/log/Xorg.0.log| grep -i glx
[ 6.045] (II) “glx” will be loaded by default.
[ 6.045] (II) LoadModule: “glx”
[ 6.046] (II) Loading /usr/lib64/nvidia/xorg/libglx.so
[ 6.221] (II) Module glx: vendor=”NVIDIA Corporation”
[ 6.222] (II) NVIDIA GLX Module 352.21 Tue Jun 9 21:22:54 PDT 2015
[ 6.898] (EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not found)
Do you have the correct kernel-devel package for your kernel as described in the repository page?
Looks like I have right version installed:
$ rpm -qa kernel\* | sort
kernel-4.0.4-301.fc22.x86_64
kernel-4.0.4-303.fc22.x86_64
kernel-core-4.0.4-301.fc22.x86_64
kernel-core-4.0.4-303.fc22.x86_64
kernel-devel-4.0.4-303.fc22.x86_64
kernel-headers-4.0.4-303.fc22.x86_64
kernel-modules-4.0.4-301.fc22.x86_64
kernel-modules-4.0.4-303.fc22.x86_64
kernel-modules-extra-4.0.4-301.fc22.x86_64
kernel-modules-extra-4.0.4-303.fc22.x86_64
kernel-tools-libs-4.0.4-303.fc22.x86_64
and I can see the module is being built:
# find / | grep nvidia.ko
/var/lib/dkms/nvidia/352.21/4.0.4-303.fc22.x86_64/x86_64/module/nvidia.ko
I have same error as finite9, fresh install. No optimus, kernel-devel package installed for that specific kernel.
For Fedora 22, a file from the cuda-devel package (/usr/share/man/man3/deprecated.3.gz) conflicts with a file from the qwt5-qt4-devel package.
Just thought you should know.
Cheers
Stu
Thanks, will look into it when updating to CUDA 7.0.
i did kmods –force to try re-building for kernel 4.0.4-303 but get this error:
[root@frodo andrew]# akmods --forceChecking kmods exist for 4.0.4-303.fc22.x86_64 [ OK ]
Building and installing nvidia-kmod [FAILED]
Building rpms failed; see /var/cache/akmods/nvidia/352.09-1-for-4.0.4-303.fc22.x86_64.failed.log for details
Hint: Some kmods were ignored or failed to build or install.
You can try to rebuild and install them by by calling
'/usr/sbin/akmods --force' as root.
Do you have the
kernel-develpackage for 4.0.4-303.fc22.x86_64 installed?You can check with:
rpm -qa kernel\* | sortyes I do have the kernel-devel package installed for that specific kernel
forgot to mention im using Optimus. Don’t know if that makes any difference?
we turn off Optimus in BIOS, and select discreet graphics rather than Nvidia. There may be other options, but this seems to work best for us.
There is no option in my Dell XPS L502X BIOS to turn off Optimus.
More specifically, the error I see in /var/cache/akmods/nvidia/352.09-1-for-4.0.4-303.fc22.x86_64.failed.log is:
install: cannot stat '_kmod_build_4.0.4-303.fc22.x86_64/uvm/nvidia*.ko': No such file or directorysorry, full error here which gives more insight:
+ install -p -m 0755 '_kmod_build_4.0.4-303.fc22.x86_64/uvm/nvidia*.ko' /tmp/akmodsbuild.SKeKT5hh/BUILDROOT/nvidia-kmod-352.09-1.fc22.x86_64//usr/lib/modules//4.0.4-303.fc22.x86_64//extra/nvidia//install: cannot stat '_kmod_build_4.0.4-303.fc22.x86_64/uvm/nvidia*.ko': No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.2G7CfH (%install)
i get the ‘oh no something went wrong’ after installing nvidia-driver on F22. I already had kernel-devel installed, and im using kernel 4.0.4-303. I tried using the dkms-nvidia instead but same error. has something changed with latest kernel?
Thank You so much for your efforts! I was able to install the drivers for my GT200GL Quadro FX3800 using the fedora-nvidia-340.repo on my HP Z800 Fedora 22 KDE. I was running Fedora 21 with the nvidia drivers successfully until a yum update broke it. The Download from Nvidia’s site no longer runs and there is some patch on the developer site I did not understand how to compile/implement. Until I found your site, I was stuck. Unable to revert back to the Nouveau drivers due to a lack of concise instructions.
I realized that when adding a repos with dnf config-manager, the files do not have read rights for group and other. So a dnf search would fail for that repos.
Workaround: execute “chmod +r /etc/yum.repos.d/fedora-nvidia.repo” as root (or via sudo)
I have an issue with Fedora 22 KDE Spin. Installed fresh system from ISO. I added negativo17 repo. Nvidia driver works ok. System boot up, however KDE doesn’t start properly. I have one krunner error and 3 plasma errors and and the end plasma doesn’t start. With nouveau driver all is OK. Is there anybody how had the same issue?
I had this issue until I realized my card needed the 340 driver. I had installed fedora-nvidia rather than the needed fedora-nvidia-340.repo. I disabled the fedora-nvidia repo , added the -340.repo, removed then installed per the instructions and it worked.
Glad you fixed it. To go from one version to the other, you could just replace the .repo file and just do a dnf distro-sync or dnf downgrade command.
i think the repo for fc21 is broken , there a mix between drivers version 349 and 352 , and it broke for me with the new kernel 4.0.4 ( akmod failed to build with 346 )
The upload is now finished (352.09). Thanks for letting me know.
Hello,
I have Fedora 22 x64 with GTX 760Ti. By default is your repo suggesting to install beta driver? Why not stable? Can you please help me ho to install stable?
Hello, not at the moment. You can just rebuild the source RPMS for 349.xx.
Normally I have beta drivers available only for the unreleased Fedora versions, but this time the schedule did not match with Nvidia, and I had the beta driver in before the Fedora release.
thanks for the work
i got a problem , i did use akmod-nvidia with f22 and i got a problem with the X server , it didn’t load the path /usr/lib64/nvidia/xorg which is present in
/etc/X11/xorg.conf.d/99-nvidia-modules.conf
log of the failed X server
#/var/log/Xorg.0.log
[ 2866.166] Build ID: xorg-x11-server 1.17.1-12.fc22
[ 2866.167] (==) Using config file: “/etc/X11/xorg.conf”
[ 2866.167] (==) Using config directory: “/etc/X11/xorg.conf.d”
[ 2866.167] (==) Using system config directory “/usr/share/X11/xorg.conf.d”
[ 2866.167] (==) ModulePath set to “/usr/lib64/xorg/modules”
[ 2866.178] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so
[ 2866.190] (II) Loading /usr/lib64/xorg/modules/drivers/nvidia_drv.so
[ 2866.195] (II) Loading /usr/lib64/xorg/modules/libfb.so
[ 2866.196] (II) Loading /usr/lib64/xorg/modules/libwfb.so
[ 2866.578] (II) Loading /usr/lib64/xorg/modules/input/libinput_drv.so
so i did create a symlink
ln -s /usr/lib64/nvidia/xorg/libglx.so /usr/lib64/xorg/modules/extensions/libglx.so
and now it works
am i the only one which got this bug ?
It is loading fine on my system. I have other problems relating to the X 1.16+ server always loading glamor, but not that one you’re mentioning.
Is there a problem with akmod-nvidia for F22?
At the moment the newest driver in your repo is 2:352.09-1.fc22. There is no corresponding akmod-nvidia package. Thus nvidia-driver wants to pull in dkms-nvidia.
Thanks for notifying, I missed that (running Fedora 21 here). Will update the repository in a moment.
Thanks, works well now!
Hi, thanks for maintaining this and keeping up with us.
I haven’t been able to get BOINC to find my GPU. I got it working last year with the RPMFusion drivers and the CUDA package from NVIDIA (I think it was 5.5 back then). I’ve got most of this repository installed. Anynthing I should look for?
Which version of CUDA is supported by it?
I couldn’t find it exactly in their docs. I know it ran with Cuda 5.5, and I think (don’t remember clearly) with 6.0. I’ve got a GTX650TiBOOST, if it’s relevant. Should still be supported.
I just installed ccminer from your repository, to see if I could get anything working. When I ran “ccminer –benchmark” I got:
[2015-05-02 02:49:15] GPU monitoring is not available.[2015-05-02 02:49:15] 1 miner thread started, using 'x11' algorithm.
[2015-05-02 02:49:15] GPU #0: quark_blake512_cpu_init invalid device symbol
[2015-05-02 02:49:16] GPU #0: aes_cpu_init invalid device symbol
[2015-05-02 02:49:17] GPU #0: aes_cpu_init invalid device symbol
[2015-05-02 02:49:18] GPU #0: x11_simd512_cpu_init invalid texture reference
[2015-05-02 02:49:19] GPU #0: quark_blake512_cpu_init invalid device symbol
[2015-05-02 02:49:20] GPU #0: aes_cpu_init invalid device symbol
[2015-05-02 02:49:21] GPU #0: aes_cpu_init invalid device symbol
[2015-05-02 02:49:22] GPU #0: x11_simd512_cpu_init invalid texture reference
[2015-05-02 02:49:23] GPU #0: GeForce GTX 650 Ti BOOST, 0.00 H/s
[2015-05-02 02:49:23] Total: 0.00 H/s
[2015-05-02 02:49:23] GPU #0: quark_blake512_cpu_init invalid device symbol
[2015-05-02 02:49:24] GPU #0: aes_cpu_init invalid device symbol
[2015-05-02 02:49:25] GPU #0: aes_cpu_init invalid device symbol
[2015-05-02 02:49:26] GPU #0: x11_simd512_cpu_init out of memory
[2015-05-02 02:49:27] GPU #0: GeForce GTX 650 Ti BOOST, 0.00 H/s
[2015-05-02 02:49:27] Total: 0.00 H/s
[2015-05-02 02:49:27] GPU #0: quark_blake512_cpu_init invalid device symbol
...
Mmmh. This is not what’s happening here:
[2015-05-03 11:14:20] GPU monitoring is not available.[2015-05-03 11:14:20] 1 miner thread started, using 'x11' algorithm.
[2015-05-03 11:14:30] GPU #0: GeForce GTX 860M, 2474.76 kH/s
[2015-05-03 11:14:30] Total: 2474.76 kH/s
The problem I mentioned in the post above was resolved with today’s update to the 2:349.16-2 versions. Thanks!
Blender official build looks for
libcuda.sobeing available and thenvidia-uvm.kobeing loaded. You don’t need the CUDA packages. Please also see my latest post:http://negativo17.org/cuda-enabled-programs/
So no way for the moment to have blender with CUDA working in F22 ?
Hello, I’m literally swamped with apartment move and daily work. I will be rebuilding everything during the weekend, expect it next week.
Works with the release downloaded from the official site…
A quick question about Blender —
When using nvidia’s installer, I’m able to use the graphics card as a ‘compute device’ for the Cycles Renderer (User Preferences/System/Compute Device/CUDA) — on your package, however, I don’t see the graphics card listed at all. This holds for the stable release, as well as the daily builds from blender.org.
I’ve installed (all from the @fedora-nvidia repo)
akmod-nvidia.x86_64
kmod-nvidia.x86_64
kmod-nvidia-3.19.5-200.fc21.x86_64.x86_64
nvidia-driver.x86_64
nvidia-driver-NVML.x86_64
nvidia-driver-NvFBCOpenGL.x86_64
nvidia-driver-cuda.x86_64
nvidia-driver-cuda-libs.x86_64
nvidia-driver-devel.x86_64
nvidia-driver-libs.i686
nvidia-driver-libs.x86_64
nvidia-libXNVCtrl.x86_64
nvidia-persistenced.x86_64
nvidia-settings.x86_64
cuda.x86_64
cuda-cli-tools.x86_64
cuda-devel.x86_64
cuda-extra-libs.x86_64
cuda-libs.x86_64
What do you think I might be missing?
I’m having trouble building graphics programs like blender, and it appears to be due to do something about the nvidia-340 branch. Even though NVidia doesn’t recommend any other options for my card (Quadro FX 1800) other than the 340 branch, is it safe for me to use the 346 drivers and libraries (including CUDA and OpenCL) on my desktop (Dell Precision T7500 w/Fedora 21)?
Hello and thank you for the work!
I’m trying to add your repo to a fresh Fedora22 install without success. I’ve tried both “yum-config-manager –add-repo=http://negativo17.org/repos/fedora-nvidia.repo” and “sudo dnf config-manager –add-repo=http://negativo17.org/repos/fedora-nvidia.repo” but i get the error: “Error: No matching repo to modify: –add-repo=http://negativo17.org/repos/fedora-nvidia.repo”. would you possibly have a hint for me on what i’m doing wrong and how to get your repo& driver on my system please?
By a quick look to the comment you are not using a double dash (–) to the add-repo parameter:
yum-config-manager --add-repo=http://negativo17.org/repos/fedora-nvidia.repoYou can still copy the repository file in
/etc/yum.repos.dmanually, though.oh thank you so much! 🙂
Following Infinite’s comment above (manually installing the kernel-devel package) seems to have fixed the issue.
Which by the way is part of the instructions provided in the page…
Hi,
I’m unable to get the proprietary drivers working under Fedora 22:
$ Linux notebook 4.0.0-1.fc22.x86_64 #1 SMP Mon Apr 13 10:03:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
This is a notebook with a Geforce 560M card.
After installing with ‘# yum -y install nvidia-driver’, the system reboots to the infamous “Oh no! Something has gone wrong … Please log out and try again” screen, instead of a functional GDM. Nouveau, on the other hand, works perfectly.
Can you help me further debug this? Thank you.
FYI,
“dnf install kernel-devel” will fix “something wrong happened” when booting Fedora 22, and possibly older Fedora too. Now things works!
Thank you for your contribution.
Hello, installation of the
kernel-develpackage is in the instructions for the aKMOD variant. aKMOD pulls inkernel-debug-devel, this is why I added it to the instructions. DKMS, on the other hand, already pulls inkernel-devel.For update,
Solved this problem with the right command for dnf in Fedora 22 and good internet connection:
sudo dnf config-manager –add-repo=http://negativo17.org
/repos/fedora-nvidia.repo
We will see how it works.
Thank you.
Hello,
Thank you for such a contribution to Fedora community. I’ve tried to add your repo without success:
sudo yum-config-manager –add-repo=http://negativo17.org/repos/fedora-nvidia.repo
> YumRepo Error: All mirror URLs are not using ftp, http[s] or file.
sudo dnf –enablerepo=http://negativo17.org/repos/fedora-nvidia.repo
> Error: Unknown repo: ‘http://negativo17.org/repos/fedora-nvidia.repo’
What’s wrong here?
Now, it is working 🙂
thank you again!
I found this
https://devtalk.nvidia.com/default/topic/823073/linux/346-47-on-fedora-22-kernel-4-0-0-0-rc5-git4-1-fc22-x86_64/
Yes, it was an issue on 346.47 and fixed in 346.52. I have reapplied it to the 340.xx series (a new version is coming out, btw). Uploading now.
Thank you very much!
Unfortunately, I got the following errors 🙁
[ 64.201] (EE) Failed to load module “nouveau” (module does not exist, 0)
[ 64.201] (EE) Failed to load module “nv” (module does not exist, 0)
[ 64.204] (EE) open /dev/dri/card0: No such file or directory
[ 64.205] (EE) open /dev/fb0: No such file or directory
[ 64.206] (EE) Screen 0 deleted because of no matching config section.
[ 64.904] (EE) AIGLX: reverting to software rendering
[ 64.925] (EE) AIGLX error: dlopen of /usr/lib64/dri/swrast_dri.so failed (/usr/lib64/dri/swrast_dri.so: undefined symbol: _glapi_tls_Dispatch)
[ 64.925] (EE) GLX: could not load software renderer
Hello Negativo,
Thank you for your useful repos! There is any chance to start a repo for 340xx driver in fedora 22? I have a Dell precision 4500 with quadro 880m and the latest driver doesn’t work 🙁
In rpmfusion there is 304xx but doesn’t work with the fedora’s xorg version!
Currently I am using nouveau.
Thank you!
Added, it’s uploading now; give it 15 minutes.
I just wanted to say thanks — I’m on Fedora 21 (3.19.3), GNOME 3.14.2; I went from a manually installed driver (346.47 from the nvidia website; gtx970) to your repo, and not only does the shell consume significantly less vram, but has become a *lot* more responsive.
I’m not technical enough to tell whether your packaging is the cause; but the change followed up on installing it, and I’m really happy for it. Thanks!
OK. From novieau loading helps
yum remove xorg-x11-drv-nouveau
&
rdblacklist=nouveau nouveau.modeset=0 in GRUB_CMDLINE_LINUX.
But I have another problem with the drivers: now brightness is not regulated оn mу classic Thinkpad T410…
Usual tricks like «acpi_backlight=vendor» in GRUB_CMDLINE_LINUX does not help… Does anyone how to solve it?..
4.- Blacklist nouveau
1. sudo dnf -y install beesu
2. beesu gedit /etc/default/grub
I found a solution to our problem (no backlight control on Thinkpads).
I created an xorg conf file in
/etc/X11/xorg.conf.dwith the following contents and named it22-thinkpad_T510_bright.confSection "Device"Identifier "Thinkpad Brightness Control"
Option "RegistryDwords" "EnableBrightnessControl=1"
EndSection
This didn’t work previously because I had neglected to add the Identifier line. Hope this helps.
Thanks, it’s working!
Should all be one line:
Option “RegistryDwords” “EnableBrightnessControl=1″
Removing the nouveau driver is not required, as it’s not loaded. Adding the parameters through GRUB_CMDLINE_LINUX is required only if you regenerate the Grub config file through
grub2-mkconfig. Otherwise what you did is not needed, the driver package adds the required parameters throughgrubby:$ rpm -q --scripts nvidia-driver postinstall scriptlet (using /bin/sh): if [ "$1" -eq "1" ]; then ISGRUB1="" if [[ -f /boot/grub/grub.conf && ! -f /boot/grub2/grub2.cfg ]]; then ISGRUB1="--grub" fi /sbin/grubby $ISGRUB1 --update-kernel=ALL --args='nouveau.modeset=0 rd.driver.blacklist=nouveau nomodeset gfxpayload=vga=normal' &>/dev/null fi || : preuninstall scriptlet (using /bin/sh): if [ "$1" -eq "0" ]; then ISGRUB1="" if [[ -f /boot/grub/grub.conf && ! -f /boot/grub2/grub2.cfg ]]; then ISGRUB1="--grub" fi /sbin/grubby $ISGRUB1 --update-kernel=ALL --remove-args='nouveau.modeset=0 rd.driver.blacklist=nouveau nomodeset gfxpayload=vga=normal' &>/dev/null fi ||:Nevermind. It occurred to me shortly after sending that that I’ve dealt with this before. It’s a Thinkpad-specific issued.
The solution which used to work is to add a .conf to /etc/X11/xorg.conf.d, specifically with the content:
Section “Device”
Option “RegistryDwords” “EnableBrightnessControl=1”
EndSection
Unfortunately it now hangs at (something like) “waiting for Plymouth boot screen to quit” which it never does and therefore never fully gets to runlevel 5.
I’ll keep experimenting. Thanks