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.
I can’t seem to find the
nvidia-smiutility. In which package is it located? I can swear in the past I only needed to installnvidia-driverto have it, but it’s not being the case.It’s in
nvidia-driver-cuda.Hi
I updated fedora 28 to fedora 29 and now dkms fails to build module for any kernel-5.0.*
This is from the build/make.log:
/var/lib/dkms/nvidia/418.56/build/common/inc/nv-linux.h:1287:31: error: ‘swiotlb_dma_ops’ undeclared (first use in this function); did you mean ‘swiotlb_map’?
swiotlb_in_use = (ops == &swiotlb_dma_ops);
^~~~~~~~~~~~~~~
swiotlb_map
I don’t get any error when building modules for kernel-4.*
I searched with google but found no information on this issue.
Thank you
For Fedora 29, I would recommend going into software center and search for nvidia. The one item there will show you how to install the drivers in a way that works. It was the only way that I had working there. For Fedora 30, that didn’t work and it worked with the instructions here lol. Fun stuff.
Is Fedora 30 supported? The beta was released this week.
Happy to say that at least today with the release, it is working.
What worked for me was $ dnf install nvidia-driver nvidia-driver-libs.i686 nvidia-settings and reboot.
Note that WaylandEnabled=false is uncommented in /etc/gdm/custom.conf. So XWayland is good to go.
$ lspci -nnk | grep -iA2 vga
…
Kernel driver in use: nvidia
i lost my driver but i cannot install again
its giving wrong hypertext always..
What? “lost your driver”? Wrong “hypertext”?
What does it all mean?
It’s spam, see the link in the “user’s” profile. (Which goes to a Turkish online store that sells… power tools, looks like.)
Hi. I notice this error message in the system log file.
Feb 21 09:03:36 phe kernel: NVRM: API mismatch: the client has the
version 410.73, but#012NVRM: this kernel module has the version 415.27.
Please#012NVRM: make sure that this kernel module and all NVIDIA dri
ver#012NVRM: components have the same version.
The nvidia kernel module and package are based on version 415.27.
[root@phe]# modinfo nvidia nvidia_drm nvidia_modeset
nvidia_uvm nvidia | grep ^version
version: 415.27
version: 415.27
version: 415.27
version: 415.27
[root@phe]# rpm -qa *nvidia* | sort
akmod-nvidia-415.27-1.fc28.x86_64
kmod-nvidia-4.19.13-200.fc28.x86_64-415.27-1.fc28.x86_64
kmod-nvidia-4.19.16-200.fc28.x86_64-415.27-1.fc28.x86_64
kmod-nvidia-4.20.8-100.fc28.x86_64-415.27-1.fc28.x86_64
nvidia-driver-415.27-5.fc28.x86_64
nvidia-driver-cuda-libs-415.27-5.fc28.x86_64
nvidia-driver-libs-415.27-5.fc28.i686
nvidia-driver-libs-415.27-5.fc28.x86_64
nvidia-kmod-common-415.27-1.fc28.noarch
nvidia-libXNVCtrl-415.27-1.fc28.x86_64
nvidia-settings-415.27-1.fc28.x86_64
Can you show me how to fix the warning message above? I
don’t understand why the client shows version 410.73 when
everything is updated to 415.27.
Thank you!
It seems it still detecting version 410.73 in the user space components. 410.73 is from october last year, 415.27 is from middle January, I guess your system is really messed up. Just remove all Nvidia components, reboot, reinstall, reboot.
You are doing fantastic job, thank you!
Could you please update cuda-gcc to more recent than 7.3.1 version, since it can not build recent tensorflow because of gcc bug:
In file included from tensorflow/python/eager/pywrap_tfe_src.cc:23:0:
external/com_google_absl/absl/types/variant.h: In substitution of ‘template using variant_alternative_t = typename absl::variant_alternative::type [with long unsigned int I = I; T = absl::variant<tensorflow::TensorShape, _object*>]’:
external/com_google_absl/absl/types/variant.h:581:7: required by substitution of ‘template<class T, long unsigned int I, class Tj, typename std::enable_if<(std::is_assignable::value && std::is_constructible<Tj, T>::value), void>::type* > absl::variant<tensorflow::TensorShape, _object*>& absl::variant<tensorflow::TensorShape, _object*>::operator=<T, I, Tj, >(T&&) [with T = const absl::variant<tensorflow::TensorShape, _object*>&; long unsigned int I = ; Tj = ; typename std::enable_if<(std::is_assignable<Tj&, T>::value && std::is_constructible<Tj, T>::value), void>::type* = ]’
tensorflow/python/eager/pywrap_tfe_src.cc:914:20: required from here
external/com_google_absl/absl/types/variant.h:581:7: internal compiler error: unexpected expression ‘I’ of kind template_parm_index
class Tj = absl::variant_alternative_t<I, variant>,
^~~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See https://gcc.gnu.org/bugs/ for instructions.
Oh. Can you downgrade the package to 7.3.0 in the meanwhile and see if it works (
dnf downgrade cuda-gcc)?Downgrading cuda-gcc to 7.3.0 does fix the problem for me.
Hi, I use Fedora 29 Kde spin with latest updates, also use nvidia driver from negativo17.
X works nice, however when I switch to a virtual terminal with ctrl alt f1 or f2, the screen is unreadable, see https://forums.fedoraforum.org/attachment.php?attachmentid=29963&d=1545916637
I suspect this is related to the nvidia driver, but really unsure. Do you any hint on how to fix that ?
Dropping the rhgb from boot options fixes the problem, but is this a bug in fedora or nvidia driver ?
Fedora, scroll in the comments for the bugzilla link.
Hi,
I was previously using kernel-4.18.12-200.fc28.x86_64 and had bumblee working perfectly with my Nvidia GTX 1060. I have just upgraded to Fedora 29 – kernel-4.19.10-300.fc29.x86_64 and I can no longer use my nvidia card.
Output from optirun is:
optirun -b none nvidia-settings -c :8
[ 440.029113] [ERROR]Cannot access secondary GPU – error: [XORG] (EE) NOUVEAU(0): [drm] failed to set drm interface version.
[ 440.029142] [ERROR]Aborting because fallback start is disabled.
optirun glxspheres64
[ 210.258044] [ERROR]Cannot access secondary GPU – error: [XORG] (EE) NOUVEAU(0): [drm] failed to set drm interface version.
[ 210.258073] [ERROR]Aborting because fallback start is disabled.
These all worked perfectly before the upgrade.
I haven’t investigated what needs to be repaired yet as I had been expecting the upgrade to work without any intervention. Any pointers welcome.
Thanks,
John
A recent change in Fedora 29 [4.19.7-300.fc29.x86_64] has broken the latest nvidia driver. This is true for both the negativo and rpmfusion nvidia packaging. gdm clears the screen but the screen remains blank and logging in is not possible. Reverting to the nouveau driver by removing the nvidia packages results in X11 working again.
When attempting to run with the nvidia driver, error messages are logged to the console as shown here: https://snag.gy/1lpykS.jpg
Is no one else having this issue? I tried it a couple of times. The nvidia driver had been working fine for months and then suddenly stopped working after an update. If it’s just my system, then I’ll spend time troubleshooting it rather than waiting for a kernel or driver update. If the latest version of the nvidia driver is working fine on your up to date fedora 29 system, please let me know. Thanks!
I also have the same problem. I reinstalled nvidia driver after kernel update but it did not help. Before update driver was working.
Thank you for confirming! This is the first time the nvidia driver has not worked on fedora 29. Did you happen to notice whether the problem started after a driver update or whether it started after a kernel update? I did not notice which update broke it. But when it stopped working, I did try booting using the previous kernel and that did not work either. Both the negativo17 and rpmfusion packaging of the driver exhibit the same issue. I am hoping we can get accelerated graphics back soon. I may try force installing older versions of the driver and will report back if I get a working configuration.
Same problem
OK, I think I figured this out. The problem appears to be with gdm – the gnome display manager. I got the desktop working again with the accelerated driver by switching to lightdm instead. Please try it and see if it works for you too.
sudo dnf install lightdm
sudo systemctl -f enable lightdm
It probably already is, but make sure that WaylandEnable=false in /etc/gdm/custom.conf
Should you want to switch back to gdm, just use:
sudo systemctl -f enable gdm
If using 4.19.7-300.fc29.x86_64 breaks it then why use 4.19.7-300.fc29.x86_64? Sometimes you can’t use some kernels without problems because they have problems.
Also, if an update of a kernel breaks something then its the kernel at fault.
Further experimenting and searching has led me to the conclusion that the problem is not in the kernel or the driver, but in gdm. Using another display manager, in my case lightdm, has solved the problem for me.
When the problem first happened, the first thing that I did was reboot using the previous kernel and this obviously didn’t help since the kernel was not the problem.
I tried using lightdm and sddm with your help and other source but they didn’t start. Recent kernel update did not help. I guess I have to wait for update for gdm or/and kernel
I am trying to remember anything else that I may have done. I think the only other thing was in /etc/gdm/custom.conf where I made sure that:
WaylandEnable=false
##AutomaticLoginEnable=True
Oh, wait – I just realized that I was trying both the negativo driver and the rpmfusion driver – basically, the same driver with different packaging and options and it is actually the rpmfusion version that is working for me right now. I found the driver information on setup here: https://rpmfusion.org/Howto/NVIDIA
Fedora 29 is up-to-date (there was another kernel update today) and I’m still using lightdm as a display manager and will leave things as they are now because everything is working. I hope you can get your driver working again. If you decide to try the rpmfusion version, make sure you remove all the negativo nvidia packages first. You can always switch back and forth
I just received 415.25 and it starts fine with Fedora 29 fully updated. The first boot after the Fedora update installer finished sat for 5-10 minutes. Did a forced reboot and it went right into the OS and everything is good as is typical.
I’m not seeing what you were seeing. I will just assume its fixed or its because I have the Nvidia driver installed a bit differently (according to what’s found in the software application reviews)
Am also using X-Wayland and not x11 directly
415.22 is now released with transform feedback! Please add support it asap!
It seems the 415.18 is crashing some Unity games with Valve’s Proton (I didn’t have the issue with 410). Do you already know if the recently released 415.18.02 fix the issue ?
The only thing they communicated on, is the presence for VK_EXT_Transform_Feedback extension support (at last).
Hi. Anyone also experiencing problems with latest driver (410.73-4) and latest kernel (4.19.2-301) on F29? Since either one has been updated (I can’t recall exactly which one), my system takes a long time (5-10 min on a SSD drive) to shutdown or restart, with lots of errors which seem unrelated to nvidia driver (eg. can’t unmount some partitions — /home and /tmp), but, the fact is that removing nvidia-driver and dependent packages and reverting back to nouveau seems to fix the problem… Any ideas on how to better diagnose this — or, even better, fix it 😉 — would be much appreciated.
I had the same issue. Fixed with the latest 415 driver.
Was also fixed by newer kernels once they arrived.
What I mean by that is that the Nvidia driver didn’t need to be changed for a fix.
The last update (410.73-3.fc28.x86_64) broke “something” on my Fedora-28 setup. GDM lets root login, but users are kicked out.
Some selected (relevant entries from “journalctl -xb”)
Oct 29 16:04:59 gnome-shell[1833]: Failed to set CRTC mode 3840×2160: Permission denied
Oct 29 16:05:00 /usr/libexec/gdm-x-session[5209]: (EE) modeset(G0): drmSetMaster failed: Permission denied
I suspect some selinux “issue” related to modesetting (based on the github entry: “Enable modesetting and remove ignoreabi setting for Fedora.”)
Known issue / workaround? Thanks
Hi,
Is there any plan to update the current Vulkan driver to use the latest 396.54.09 version, which includes VK_EXT_transform_feedback extension support ?
Anyway, thanks for your work.
No sorry, only long lived, short lived and beta branches, depending on the distribution as depicted there: https://negativo17.org/nvidia-driver/
Scroll down to “Distribution and Nvidia driver version support”.
415.22 has this. No need for Vulkan dev driver
Any love for 396.54.09 driver? It includes VK_EXT_transform_feedback, which is pretty big deal…
No sorry, only long lived, short lived and beta branches, depending on the distribution as depicted there: https://negativo17.org/nvidia-driver/
Scroll down to “Distribution and Nvidia driver version support”.
415.22 has this. No need for Vulkan dev driver. So the Vulkan dev driver use is not that big of a deal 😉
Hi!
Just wanted to ask, if you have any plans for the 396.54.09 driver.
It implements the “VK_EXT_transform_feedback” extension that is needed for DXVK (https://github.com/doitsujin/dxvk/issues/695) and the new Proton beta (https://github.com/ValveSoftware/Proton/blob/proton_3.16/CHANGELOG.md).
Thanks!
I retract my question, based on https://github.com/negativo17/nvidia-driver/issues/62
No sorry, only long lived, short lived and beta branches, depending on the distribution as depicted there: https://negativo17.org/nvidia-driver/
Scroll down to “Distribution and Nvidia driver version support”.
Are you able to update your driver package to include “legacy NVIDIA GPU driver releases”?
Video cards in the legacy list here: https://download.nvidia.com/XFree86/Linux-x86_64/396.54/README/supportedchips.html do not use the unified driver you provide in your install thus I am only able to utilize your repo for software such as the nvidia-settings among other things.
I’ve submitted a issue via your GitHub repo for review.
Nope sorry, no plan to package the legacy drivers.
hi
after installing on my laptop (otpimus)
i’m still on “nouveau” driver and nvidia X server settings won’t start
using this : lspci -k | grep -A 2 VGA
result
00:02.0 VGA compatible controller: Intel Corporation Device 591b (rev 04)
Subsystem: Lenovo Device 38e1
Kernel driver in use: i915
01:00.0 VGA compatible controller: NVIDIA Corporation GP106M [GeForce GTX 1060 Mobile] (rev a1)
Subsystem: Lenovo Device 38e1
Kernel driver in use: nouveau
also when i try to start nvidia-settings it result
ERROR: Unable to find display on any available system
how do i force it to charge nvidia driver ?
thank you
If you’re on Fedora 28 you can use the directions that you can find in the software center review of a search for nvidia. I don’t know why the directions or even software center installs might not work, but the review instructions do.
Correct, that brings you the drivers from the RPMFusion repository. If you go that way, please don’t add the repositories hosted here to your system.
Any Idea why I’m getting this:
$ LIBGL_DEBUG=verbose glxinfo | grep render
Error: couldn’t find RGB GLX visual or fbconfig
I’m trying to render X server with Intel and let CUDA for things like nvidia.
I’m in Fedora 28.
Is it possible to put back fedora 26 with cuda 8? I have an old GPU and just updated to fedora 27. Please, I beg you.
Fedora 26 is EOL. You can build the RPMs from the github repositories, the commits are still there.
There needs to be an option to allow Fedora users to choose between the long lived branch and the short lived branch. Right now, as stated here, Fedora users are locked into the short lived branch.
I have a GeForce GT630 which is compatible with 390.xx (long lived) but failed after I did a dnf update and 395.xx (short live branch) was installed. 395.xx is not compatible with my GT630. I was able to roll back to 390.xx because there was still xorg-x11-drv-nvidia-390.xx in the repository. The next update broke my display again with the install of 396.xx. Now, xorg-x11-drv-nvidia-390.xx is no longer in the repositiory.
I finally gave up on fedora-nvidia, removed it and had to install Nvidia’s native 390.xx driver.
No legacy releases supported here (no hardware available to test). Only long lived, short lived are supported: https://negativo17.org/nvidia-driver/
It looks like my card is no longer supported by the current driver and can’t seem to find a way to downgrade. Are the older packages available anywhere, as they were working just fine?
Thanks!
No sorry, only long lived, short lived and beta branches, depending on the distribution as depicted there: https://negativo17.org/nvidia-driver/
Scroll down to “Distribution and Nvidia driver version support”.
Tried to update from version 396.24 to 396.45. On boot, X started in VGA mode with log showing
NVRM: API mismatch: the client has the version 396.45, but
NVRM: this kernel module has the version 396.24. Please
NVRM: make sure that this kernel module and all NVIDIA driver
NVRM: components have the same version.
You have mismatched files on the system.
I am getting a strange issue where GDM does not start properly when a file /etc/X11/xorg.conf exists. I generated this in two ways: nvidia-xconfig (which places a default file there), and via nvidia-settings GUI which appears to be working properly otherwise. Perhaps there is another location where I need to write the config to? When GDM fails to start, you get a black screen without cursor. Switching to TTY2, or other using CTRL+F2, you see “A start job is running for Wait for Plymouth Boot Screen to Quit”. Booting as runlevel 3 (by modifying grub), removing the .xorg file, and rebooting results back to normal behavior.
I’m trying to get a dual-monitor setup going, but it appears the system isn’t liking the xorg file? Any ideas?
Just don’t use any xorg.conf file. Use the display settings utility.
Do you mean nvidia-settings ? It detects the other monitor, but it doesn’t create a new X screen for it. So, nothing is displayed on the monitor?
So, to change something, like adding a new X screen or changing the rotation of the monitor, it asks to save the configuration to the xorg.conf file. Hence, the issue. Any help appreciated.
Is your repo available bye rsync, by chance?
Unfortunately not, my crappy hosting provider does not allow me to 🙁
Nothing prevents me to upload also somewhere else and use it as the master repo, though 🙂
erf
Hi, is it possible to install the 390.59 version of the NVIDIA drivers with your repo on Fedora 27?
No, please see here: http://negativo17.org/nvidia
BTW, for anyone trying to get the CUDA rendering kernel built in Blender’s Cycles Renderer, and having its build attempts fail every time because it’s trying to use the system
gcc(which on Fedora 28 is 8.1.1 currently, not supported even by CUDA 9.2):I discovered that blender does not respect the
HOST_COMPILERenvironment variable, so even having that set by/etc/profile.d/cuda.shwon’t help with blender. And their official docs actually recommendediting the/usr/local/cuda/include/host_config.hheader and removing the GCC version protection as a solution to that problem, which is just shockingly irresponsible.It’s also unnecessary. I discovered that blender does support a different, apparently undocumented variable (I had to read the blender source to discover it),
CYCLES_CUDA_EXTRA_CFLAGS, which is used in thenvcccommand line for the kernel build.So, if you install
cuda-gccandcuda-gcc-c++from the negativo17 repos, and then launch blender as follows:CYCLES_CUDA_EXTRA_CFLAGS="-ccbin cuda-g++" blender…then the CUDA kernel will build successfully the first time Cycles tries to use your detected GPU as a rendering device, and you’ll be happily CUDA-rendering from that point forward.
BTW, my system is a quad-core “Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz” with 8GB total system RAM, and I’m running a GeForce GT 710 with 1GB as my primary/only GPU and CUDA device, which barely meets the threshold to be considered a CUDA device at all. I think one of the CUDA 9.2 sample programs showed it as CUDA Capability 3.5.
As a result of all that, while so far I’ve only rendered the default blender scene of a cube lit by a single light source, I’m pretty sure Cycles actually rendered it faster with my CPU than when using my GPU as the CUDA renderer.
Not sure if that would hold up with more complex renders, I guess I’ll have to download some and time-trial it. But if you have a low-cost, underpowered GPU like mine, YMMV on the benefits of bothering with CUDA.
Hi, thanks for the information, I did not know that the environment
CYCLES_CUDA_EXTRA_CFLAGScould be passed at build time. There is alsoCUDA_NVCC_FLAGSwhich could be used, but I have some issues with CMake and variables with spaces in it (they get escaped by a backslash) so the list of parameters is not returned correctly.I just rebuilt Blender with CUDA support already compiled in, just install
blender-cudaand it should be good to go: https://github.com/negativo17/blender/commit/dae27208b2b82eb8ee65cb03f0e5b2aadee487bfIn case you’ll get a black screen after turning on your computer instead of the GDM login page, please see this bug report :
https://bugzilla.redhat.com/show_bug.cgi?id=1601169
Can you please provide cuda 9.1 for fedora 28? Tensorflow does not work with cuda 9.1.
The driver is outdated. The current nvidia driver is 396.24.02, and your your repo distributes just 396.24
Where do you see 396.24.02?
In the announcement page is not: https://devtalk.nvidia.com/default/board/99/
In the official list is not: http://www.nvidia.com/object/unix.html
And also there are no OSS code drops for that version:
https://github.com/NVIDIA/nvidia-settings
https://github.com/NVIDIA/nvidia-xconfig
https://github.com/NVIDIA/nvidia-modprobe
https://github.com/NVIDIA/nvidia-persistenced
Found this: https://devtalk.nvidia.com/default/topic/1035845/linux/is-vulkan-396-24-02-gt-396-24-/post/5262775/#5262775
No build until it hits one of the main branches, especially for the OSS part.
Oh, that’s unfortunate. Is there a way for 396.24.02 to maybe have a separate branch, like 396-vulkan? It includes certain necessary Vulkan extensions that are required by projects like DXVK, they simply don’t work with 396.24. Certain very popular Ubuntu PPAs even have this verison as default 396 package (https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa).
I would happily manually install driver from Nvidia’s bash script, but for some reason Wine isn’t very happy about manually installed drivers, even regular 396.24.
There was this post: https://developer.nvidia.com/vulkan-driver
Thanks for a great package. I am not sure if my previous e-mail was successful.
I am on an Optimus laptop with Nvidia and Fedora 28 (GCC 8). I am trying to build a
very simple CUDA example. I have cuda-gcc and cuda-gcc-c++ installed.
Can you please help me with this configuration?
nvcc test1.cu
/usr/include/c++/8/type_traits(1061): error: type name is not allowed
/usr/include/c++/8/type_traits(1061): error: type name is not allowed
/usr/include/c++/8/type_traits(1061): error: identifier “__is_assignable” is undefined
3 errors detected in the compilation of “/tmp/tmpxft_000001b1_00000000-8_test1.cpp1.ii”.
Just look at the output/man page of nvcc. You are just missing the -ccbin parameter.
Look also at the cuda-samples Makefiles for examples.
Thanks — can you update the Cuda notes above with cuda-gcc and ccbin? I’ll try this tonight, however I am now having trouble starting X (I’ll post more when I get back to the laptop at home).
Are you sure?
I think the error is caused by the fact that gcc 8 is not supported by any version of cuda. See “Table 1. Native Linux Distribution Support in CUDA 9.2” at https://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html
Will package CUDA 9.2 soon, but the problem remains, you will need anyway a
cuda-gccpackage for a 7.3 GCC.After installing
cuda-gccandcuda-gcc-c++from negativo17’s fedora-nvidia repo, you can build all of the examples in CUDA 9.2 (installed from Nvidia’s own Fedora 27 repo) by going into the directory created bycuda-install-samples-9.2.shand runningHOST_COMPILER=cuda-g++ make.Have you managed to fix this?
I have similar issue when compiling ethminer (Fedora 28, gcc 8.1.1, cuda 9.1):
[ 37%] Building NVCC (Device) object libethash-cuda/CMakeFiles/ethash-cuda.dir/ethash-cuda_generated_ethash_cuda_miner_kernel.cu.o
/usr/include/c++/8/type_traits(1061): error: type name is not allowed
/usr/include/c++/8/type_traits(1061): error: type name is not allowed
/usr/include/c++/8/type_traits(1061): error: identifier “__is_assignable” is undefined
3 errors detected in the compilation of “/tmp/tmpxft_000008a3_00000000-14_ethash_cuda_miner_kernel.compute_70.cpp1.ii”.
I think the reason is that version 8 of gcc is not supported by any version of cuda yet, see “Table 1. Native Linux Distribution Support in CUDA 9.2” at https://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html
Searching Google for “/usr/include/c++/8/type_traits(1061): error: type name is not allowed” gives https://www.xpra.org/trac/ticket/1800?cversion=0&cnum_hist=4 where workaround was to switch to C++ 03 instead of C++ 11…
Just install the
cuda-gccpackages, that’s a 6.4 compiler. If you check your cuda installation, there is this inside/etc/profile.d/cuda.sh:Look at the ccminer SPEC file I used to build the software on Fedora 28 using the above gcc:
https://github.com/negativo17/ccminer/blob/master/ccminer.spec
I have the same problem… The problem is reached when compiling with nvcc. I compile my C++ code with cuda-g++, but I get the exact same error when I have to compile with nvcc.
Hi,
I’m encountering the issue with black screen instead of GNOME with 396.24-1 driver.
I had the same issue with the driver from rpmfusion and hoped that newer version of NVIDIA driver will solve the issue. But the issue is still there.
This is what I see in the gdm-x-session in journalctl:
Jun 07 19:55:09 zlopez-gamestation /usr/libexec/gdm-x-session[1896]: (EE) NVIDIA(GPU-0): Failed to acquire modesetting permission.Jun 07 19:55:09 zlopez-gamestation /usr/libexec/gdm-x-session[1896]: (EE) NVIDIA(0): Failing initialization of X screen 0There is a workaround however by booting to runlevel 3 and removing the kmod and let akmod build it again.
SLAANESH,
thanx for all your work!
btw, how do I get nvidia-smi installed?
# dnf provides \*nvidia-smi396.24 reverts to Nouveau driver at boot, downgrading to 390.59 works fine. Using dkms-nvidia.
Oh, journalctl provides this:
NVRM: The NVIDIA GeForce GTX 550 Ti GPU installed in this system is
NVRM: supported through the NVIDIA 390.xx Legacy drivers. Please
NVRM: visit http://www.nvidia.com/object/unix.html for more
NVRM: information. The 396.45 NVIDIA driver will ignore
NVRM: this GPU. Continuing probe…
Getting the following when running with no xorg.conf:
[ 2983.335] (II) FBDEV(0): using default device
[ 2983.335] (EE)
[ 2983.335] (EE) Backtrace:
[ 2983.336] (EE) 0: /usr/libexec/Xorg (OsLookupColor+0x13d) [0x59d5bd]
[ 2983.336] (EE) 1: /lib64/libpthread.so.0 (funlockfile+0x50) [0x7f5644aac00f]
[ 2983.336] (EE) 2: /lib64/libpciaccess.so.0 (pci_device_next+0x108) [0x7f564620bc18]
[ 2983.337] (EE) 3: /lib64/libpciaccess.so.0 (pci_device_find_by_slot+0x3e) [0x7f564620bcbe]
[ 2983.337] (EE) 4: /lib64/libpciaccess.so.0 (pci_device_vgaarb_init+0xaa) [0x7f564620d7da]
[ 2983.337] (EE) 5: /usr/libexec/Xorg (xf86ConfigPciEntity+0x443d) [0x497bfd]
[ 2983.337] (EE) 6: /usr/libexec/Xorg (xf86BusConfig+0x12d) [0x46c68d]
[ 2983.338] (EE) 7: /usr/libexec/Xorg (InitOutput+0x96b) [0x47aebb]
[ 2983.338] (EE) 8: /usr/libexec/Xorg (InitFonts+0x20d) [0x438d5d]
[ 2983.338] (EE) 9: /lib64/libc.so.6 (__libc_start_main+0xeb) [0x7f56446fe18b]
[ 2983.338] (EE) 10: /usr/libexec/Xorg (_start+0x2a) [0x42290a]
[ 2983.338] (EE)
[ 2983.338] (EE) Segmentation fault at address 0x0
[ 2983.338] (EE)
Fatal server error:
[ 2983.338] (EE) Caught signal 11 (Segmentation fault). Server aborting
If I put an xorg.conf, I get “no devices detected”.
Any Ideas?
I am getting a “(EE) modeset(0): drmSetMaster failed: permission denied” error on startup. If I switch to the nouveau, gdm starts up just fine. I am running Fedora 28 with a P2000 using kernel 4.16.13, 396.24 nvidia driver and dkms. Any ideas?
Are you logging in with the X session or Wayland? If you are using Wayland you need mutter with EGLStream support: https://copr.fedorainfracloud.org/coprs/mati865/mutter-eglstream/
Some update today stopped the driver from working. I just get a black screen instead of the display manager.
I tried removing the nvidia-driver and nvidia-settings packages and the rest of the unneeded packages, rebooted and the system works fine with the nouveau driver
Reinstalling the nvidia-driver, nvidia-settings and rebooting give me the black screen again.
When I hit return, the black screen changes for a second to show the text mode bootup messages and that it is trying to start the display manager.
Is anyone else seeing this on Fedora 28 x86_64 workstation with 5/23 updates?
Can confirm on Fedora 27. Falled back to nouveau automatically for me.
Are you using DKMS? There is an issue when DKMS is updated along with a kernel on the same update run. You can fix it by running these commands from a terminal, also when running under Nouveau:
dkms remove nvidia/390.59 --alldkms install nvidia/390.59
reboot
Or use
akmod-nvidia.Yes I use DKMS. I read that the rpmfusion users (akmod) have broken nvidia drivers too because of a bad SELinux policy update. (https://bugzilla.redhat.com/show_bug.cgi?id=1581790)
Can this be the reason too for your DKMS version?
Thks for the tip, that fixed my problem here as well! \o/
Well, the DKMS issue is one thing, but the culprit is the SELinux policy package bug you mentioned:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-a74875b364
dnf --enablerepo=updates-testing update selinux-policy*No, I do not have dkms installed. I have akmod-nvidia-390.59-1 and kernel-4.16.10-300 on fedora 28. Before the updates yesterday that included that kernel, the nvidia driver was working fine.
As a test, I tried booting the previous kernel and the nvidia driver doesn’t work for that kernel either. So maybe it’s the SELinux issue Dave linked below.
There was another group of updates today to kernel 4.16.11-300. I applied these updates, rebooted and it didn’t make any difference.
This is a very unusual situation as the nvidia driver you supply has been rock solid for a very long time. But the fedora folks have somehow managed to muck it up!
Problem verified – downgrading selinux-policy-targeted fixes is a temporary fix.
dnf downgrade selinux-policy-targeted
An update to fix it is permanently being pushed.
You mean an update to permanently fix that SELinux thing is under its way? How can we track that? And if I run that downgrade command, what happens? And then after the fix? Sorry, I’m a noobie about SELinux 😡
https://bodhi.fedoraproject.org/updates/FEDORA-2018-a74875b364
dnf --enablerepo=updates-testing update selinux-policy*I can verify – downgrading the selinux-policy-targeted worked for me. I switched from akmod to dkms, even removed and re-installed the drive from dkms. However nothing worked until I downgraded the selinux policy stuff. I didn’t have to reboot, just let X recycle. All is working for now. Thanks!
Or you can update to the next one:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-a74875b364
dnf --enablerepo=updates-testing update selinux-policy*https://bodhi.fedoraproject.org/updates/FEDORA-2018-a74875b364
dnf --enablerepo=updates-testing update selinux-policy*@Gabriel Galli
Yes, an update to fix the problem has been created and submitted to fedora updates. After appropriate testing, it will be pushed out in one of the future updates that fedora constantly gets when you run “dnf update”. In the meantime, you can continue using the nvidia driver by downgrading the selinux package. :”Downgrading” just means to install the previous version in place of the latest version.
Whenever you run dnf update, it will update to the latest version and if that version is not one where the problem is fixed, you will need to downgrade the package again for the driver to work. It’s not a big deal – there is no downside.
@Yaconsult ohh, okay, I got it now. I think I’ll wait for that update and then reinstall the driver. From the link that @Slaanesh posted, it seems they’ve already fixed it, it’s just not a public release yet. Thank you all very much! 🙂
I’m seeing a similar issue. It seems for me as is the dkms-nvidia package is failing to install the kernel drivers properly. Fortunately my system automatically is falling back to nouveau driver.
The dkms-nvidia package even seems to leave behind the /usr/src/nvidia-* directory it uses to build the kernel modules. If I build them by hand, I see a lot of missing signing/cert file warnings. I wonder if fedora changed how it does dkms secure package signing? This also seems to be a recent bug for virtualbox-dkms as well (on ubuntu though).
There is an issue when DKMS is updated along with a kernel on the same update run. You can fix it by running these commands from a terminal, also when running under Nouveau:
dkms remove nvidia/390.59 --alldkms install nvidia/390.59
reboot
Or use
akmod-nvidia.Thanks that worked! One strange thing though… if I do a
dnf reinstall dkms-nvidiait removes the dkms and then never reinstalls it… have to run thedkms install nvidia/390.59command manually.Yeah, I’m experiencing exactly the same since yesterday. Boot halts at gdm – black screen.
Not sure what the exact issue is, but if I move the two nvidia configs out of /etc/X11/xorg.cong.d/ then gdm starts OK, but the nvidia driver is not loaded – at least that’s what nvidia settings says. But I am able to run python scripts that make use of CUDA driver. Very odd.
J.K.
Are you using DKMS? There is an issue when DKMS is updated along with a kernel on the same update run. You can fix it by running these commands from a terminal, also when running under Nouveau:
dkms remove nvidia/390.59 --alldkms install nvidia/390.59
reboot
Or use
akmod-nvidia.I am seeing the same thing.
J.K.
Are you using DKMS? There is an issue when DKMS is updated along with a kernel on the same update run. You can fix it by running these commands from a terminal, also when running under Nouveau:
dkms remove nvidia/390.59 --alldkms install nvidia/390.59
reboot
Or use
akmod-nvidia.Same here but on Fedora Rawhide.
The culprit being xorg 1.20.
for now i downgraded xorg and upgrade my system using “dnf upgrade –exclude=xorg*” until the new nvidia driver is picked up by negativo, which supports xorg 1.20.
Will do soon, I am a bit overwhelmed with daily life.
Having that issue now with 396.24. The log says the nVidia driver refused to start because my GTX550Ti is not supported beyond 390.xx
Hello there, how you doing?
So I’m running Fedora 28 and just received this 390.59 update, but now the GUI won’t load… 🙁
Just tried reinstalling, but no luck. Boots normally if I leave it uninstalled and add “nouveau.modeset=0” to grub line.
Oh, and also with the update came the kernel 4.16.10-300.
Any ideas? Should I do anything after reinstalling, before trying to reboot?
Best regards,
Gabriel
Are you using DKMS? There is an issue when DKMS is updated along with a kernel on the same update run. You can fix it by running these commands from a terminal, also when running under Nouveau:
dkms remove nvidia/390.59 --alldkms install nvidia/390.59
reboot
Or use
akmod-nvidia.No, I’m not using DKMS. Then I should install akmod-nvidia? I mean, now that I’ve uninstalled your driver, I should reinstall it and install akmod, is that correct?
Well, the DKMS issue is one thing, but the culprit is the SELinux policy package:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-a74875b364
dnf --enablerepo=updates-testing update selinux-policy*Is there somewhere I can find an explanation of what the “long lived” and “short lived” drivers are?
I’ve tried googling but the information is a bit contradictory
The table here says fc28 has both the “short lived” and the “long lived” ones. I take this to mean that there should be two different versions available, but when I use it on my fc28 install I only see 390.48, is that “long lived” or “short lived”? Is it both?
The nvidia website lists 390.59 and 396.24. Are these “short lived” or “beta”?
I’m very confused by this versioning scheme
The short lived branch (396.xx) has not been pushed to the repository. It will soon.
After installation of nvidia-driver-390.59-1.fc28 on x86_64 Linux 4.16.9-300.fc28.x86_64 dmesg tells:
quote
Bad or missing usercopy whitelist? Kernel memory exposure attempt detected from SLUB object ‘nvidia_stack_cache’ (offset 11440, size 3)!
[ +0.000008] WARNING: CPU: 5 PID: 1127 at mm/usercopy.c:81 usercopy_warn+0x7d/0xa0
unquote
What does this mean?
What to do?
Rgds
AW
Hi, quick question. I have installed already nvidia-driver, cuda-devel, cuda-cudnn followed by http://blog.mdda.net/oss/2016/11/25/nvidia-on-fedora-25.
The problem is i’m trying to compile “darknet” (DL library) with cuda. it needs to specify the folder /usr/local/cuda that is made when installing with cuda on nvidia website. But i can’t find them. Thanks in advanced.
You just need to adjust the directories specified in the Makefile, for example:
https://github.com/pjreddie/darknet/blob/master/Makefile#L49
See your locally installed
/etc/profile.d/cuda.shfile for hints.Many thanks, I have compiled darknet successfully. I’m trying to map the negativo cuda lib to a cuda folder to easier to use for further usages.
As a general rule, you can point the original “
CUDA_HOME” variable to “/usr” and just adjust where the program is looking for the headers (/usr/include/cuda). All the rest should be fine.BTW is there any other channel for bug reporting or discussions in general? Replying to this thread is not the best choice IMHO. Even a google-group mail list would be an improvement, I believe. Just my $0.02 😉
Hi,
it seems there is some sort of conflict between Negativo’s and RPMFusion’s packages:
Last metadata expiration check: 0:03:15 ago on ter 22 mai 2018 09:40:09 -03.
Dependencies resolved.
Problem: package nvidia-driver-3:390.48-1.fc28.x86_64 conflicts with xorg-x11-drv-nvidia provided by xorg-x11-drv-nvidia-3:390.59-1.fc28.x86_64
– package akmod-nvidia-3:390.59-1.fc28.x86_64 requires nvidia-kmod-common >= 3:390.59, but none of the providers can be installed
– cannot install the best update candidate for package nvidia-driver-3:390.48-1.fc28.x86_64
– cannot install the best update candidate for package akmod-nvidia-3:390.48-1.fc28.x86_64
Package Arch Version Repository Size
Skipping packages with conflicts:
(add ‘–best –allowerasing’ to command line to force their upgrade):
xorg-x11-drv-nvidia x86_64 3:390.59-1.fc28 rpmfusion-nonfree-updates 2.5 M
Skipping packages with broken dependencies:
akmod-nvidia x86_64 3:390.59-1.fc28 rpmfusion-nonfree-updates 74 k
Transaction Summary
Skip 2 Packages
Nothing to do.
Complete!
@Slaanesh: just to make sure you are aware. Should we just wait a little longer, or is there any other recommended course of action?
Thank you as always for all the hard work!
The packages have been updated. If you plan to use RPMFusion packages as well, I suggest you just switch to their Nvidia driver.
Hi Slaanesh, thank you for your reply, and for the fix. I understand there might be some conflicts, but, is it really necessary to disable all RPMFusion repos? I am interested in some other packages they provide. Is there any less drastic solution? Like, for example, raising the priority for your packages over RPMFusion’s?
I have all these config files with enabled=1 on /etc/yum.repos.d:
rpmfusion-free.repo
rpmfusion-free-updates.repo
rpmfusion-nonfree.repo
rpmfusion-nonfree-updates.repo
And I also have rpmfusion-nonfree-nvidia-driver.repo, but it is disabled.
Probably not, as there might be conflicts and dependency issues. If you need other packages in RPMFusion, I suggest you to use RPMFusion directly and disable the repositories hosted here. My resources are limited and at the moment I’m interested in maintaining a definite set of packages.
Since kernel 4.16.6+ (I am currently running 4.16.9) on Fedora 28 my Gnome session no longer opens with nvidia drivers installed from negativo repository. Prior, with Fedora 27 there was no issues at all. On Fedora 28 with kernel 4.16.3, I had to uninstall/reinstall the nvidia-driver along with the dkms library after each halt in order to have a running session. Now, even that is no longer working.
In journalctl, I noticed the following message:
nvidia: module verification failed: signature and/or required key missing – tainting kernel
If I understand, UEFI should be disabled but I never needed that previously. Is it a new requirement?
Please note that removing the nvidia driver (thus using the nouveau driver) resolves the problem but its not a viable solution since I need to use some applications that requires the nvidia driver.
Any other person with the same issue?
UEFI should not be disabled, I guess you are confusing with Secure Boot on UEFI. Secure boot must be disabled, as the modules are not signed and the original signing keys of the kernel (and built in modules) is a throw away key that is not usable. Unless you plan to manually sign the modules yourself, I would suggest to disable Secure boot.
nvidia-libXNVCtrl.i686 seems to have been dropped from F28 repo, was this for a reason or by mistake?
Actually it was planned. For Fedora 28 I just pushed x86_64 builds with i686 multilibs only; and nobody complained so far. Also the latest driver is 64 bit only.
nvidia-libXNVCtrl.i686 is used only by nvidia-settings.i686, why would you need it on a x86_64 system? I can re-add it, but I don’t see the point.
No, not needed. I had it installed just in case, but I confirmed your findings that its only used by nvidia-settings. Thanks for the confirmation
Linux driver 396.24 has dropped NVS 5400M support. Do you have any plans to issue a “legacy” driver like 396.18 (beta) which supported NVS 5400 chips.
bump! (don’t you love it when a driver just decides to stop supporting your existing hardware?)
aha, I was able to fix with
dnf remove *nvidia* && dnf install dkms-nvidia-390*This does not come from these repositories, I don’t have any hardware for the 390 series driver.
I have laptop with intel and nvidia graphic card when i install akmod-nvidia, nvidia-drivers etc. system starts with nvidia graphic as default. I use fedora 28 in fedora 27 system was started with intel as default and nvidia as discrete.
What im doing wron or where i can set default card ?
Quick question: does this have the latest driver release by nvidia (396.24)? Thanks.
Hello, not yet (it has been released today!). Being a new official release, not long lived, I will update all Fedora versions with it as per the table in the page.
Is it possible to pack nvidia-docker for Fedora? Thank you.
I was already planning it actually. I have some other CUDA issues to solve first though.
Thank you for the recent addition of support for Fedora 28! Keep up the good work!
All packages for Fedora 28 along with the latest updates should be there, with the exception of
gstreamer1-plugins-bad, which will be probably pushed tomorrow.There is not yet a working
cuda-gccpackage as I was not able yet to create a working GCC 6 on Fedora 28 (soccminerandblenderare also missing.This basically means any CUDA development on F28 is not possible now – I have just ran into this issue :/… CUDA version used here is 9.1 which does not work with gcc 8…
The cuda-gcc package has been uploaded a few days ago.
Thank you! It it wasn’t for your packages, using CUDA would be incredibly painful.