Oh no, another Nvidia driver repository? Why?
This driver reflects my personal view for the way the driver should be packaged for Fedora and CentOS/RHEL. It’s somewhat different from ELRepo repositories for RHEL/CentOS and from RPMFusion packages for Fedora.
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 |
Starting from Fedora 25, 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 based on drivers version 165. - Starting from version 343.13, the
nvidia-settingsbinary is compiled with GTK3 instead of GTK2 on Fedora and RHEL/CentOS 7+. - 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.
- Starting from Nvidia driver version 334.16, the Nvidia DDX driver for X can also rely on the
nvidia-modprobecommand in the system to create devices and set permissions, so the new optional package has been added. - The
nvidiamodule has a soft dependency on thenvidia-uvmmodule, making sure the module is loaded when installing thenvidia-driver-cudapackage, but making sure that these modules are not included in the initrd (thing that would happen with systemd configuration (module-s-load.d). UDev rules make sure the module has proper permissions. - On Fedora, the kernel modules are compressed with XZ, like all the other 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.
- Starting from Fedora 21, all driver X.org configuration can be managed by simply adding/removing X.org configuration snippets in
/etc/X11/xorg.conf.d. - Use new OutputClass directive on Fedora 21 X.org server 1.16 (and later) to load the driver and do not rely on an edited
/etc/X11/xorg.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 has been disabled by default for various reasons. First of all, Wayland support in the drivers require a patched Wayland which has been refused upstream, and then the driver itself does not expose an FB driver for the console, so you won’t see any difference in the terminal output, you will still be limited to VGA.
There is a proposal for sorting everything out at XDC 2016 for hardware vendors that require to expose extensions for the drivers.
The Wayland libraries are still included in the Fedora builds, as all the dependencies are there but they are not used. On CentOS/RHEL 7 packages, they are not included as this would result in missing dependencies.
Vulkan support
Vulkan is now part of Fedora, so on supported Fedora releases, the Vulkan loader and libraries can be installed and you do not need to do anything to enable support in the drivers. CentOS and Red Hat Enterprise Linux do not have Vulkan yet. I’m not sure if it’s worth installing it by default along with the drivers, though.
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 | el6 / el7 | f25 / f26 / f27 |
|---|---|---|
| Driver branch | Long Lived | Short Lived Long Lived |
| Driver version | 384.98 | 387.34 |
| NVENC | 8.0.14 | 8.0.14 |
| Architectures: i686 x86_64 | Yes | Yes |
| Basic nvidia driver: nvidia-driver nvidia-driver-libs nvidia-libXNVCtrl | Yes | Yes |
| CUDA libraries and tools: nvidia-driver-cuda nvidia-driver-cuda-libs nvidia-driver-NVML nvidia-persistenced | Yes | Yes |
| OpenGL Framebuffer Capture: nvidia-driver-NvFBCOpenGL | Yes | Yes |
| Nvidia tools: nvidia-healthmon (x86_64) nvidia-validation-suite (x86_64) nvidia-modprobe nvidia-settings nvidia-xconfig | Yes | Yes |
| Binary kernel modules (kABI): kmod-nvidia | Yes | No |
| DKMS kernel modules: dkms-nvidia | Yes | Yes |
| aKMOD kernel modules: akmod-nvidia | No | Yes |
| 32 bit compatibility on x86_64: nvidia-libXNVCtrl nvidia-driver-libs nvidia-driver-cuda-libs nvidia-driver-NVML | Yes | Yes |
| Development nvidia-driver-devel nvenc nvenc-samples libvdpau-devel | Yes | Yes |
| GLVND libraries libglvnd libglvnd-egl libglvnd-gles libglvnd-glx libglvnd-opengl libglvnd-core-devel libglvnd-devel | Yes | Yes |
| VDPAU libraries libvdpau | 1.1.1 | 1.1.1 |
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 Fedora 25 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 control panel
- Play 32 bit games on a 64 bit system
- Play 32 bit Vulkan games on a 64 bit system
$ sudo dnf install nvidia-settings kernel-devel dkms-nvidia vulkan.i686 nvidia-driver-libs.i686 Last metadata expiration check: 0:33:49 ago on Mon Oct 24 14:14:30 2016. Dependencies resolved. ============================================================================================ Package Arch Version Repository Size ============================================================================================ Installing: dkms-nvidia x86_64 2:375.10-1.fc25 fedora-nvidia 6.4 M libglvnd i686 1:0.2.999-3.20161017gita813b56.fc25 fedora-nvidia 103 k libglvnd x86_64 1:0.2.999-3.20161017gita813b56.fc25 fedora-nvidia 105 k libglvnd-gles i686 1:0.2.999-3.20161017gita813b56.fc25 fedora-nvidia 29 k libglvnd-gles x86_64 1:0.2.999-3.20161017gita813b56.fc25 fedora-nvidia 28 k libglvnd-glx i686 1:0.2.999-3.20161017gita813b56.fc25 fedora-nvidia 114 k libglvnd-glx x86_64 1:0.2.999-3.20161017gita813b56.fc25 fedora-nvidia 110 k libglvnd-opengl i686 1:0.2.999-3.20161017gita813b56.fc25 fedora-nvidia 39 k libglvnd-opengl x86_64 1:0.2.999-3.20161017gita813b56.fc25 fedora-nvidia 38 k libva-vdpau-driver x86_64 0.7.4-14.fc24 fedora 61 k libvdpau i686 1.1.1-3.fc24 fedora 35 k nvidia-driver x86_64 2:375.10-1.fc25 fedora-nvidia 3.1 M nvidia-driver-NVML x86_64 2:375.10-1.fc25 fedora-nvidia 397 k nvidia-driver-libs i686 2:375.10-1.fc25 fedora-nvidia 15 M nvidia-driver-libs x86_64 2:375.10-1.fc25 fedora-nvidia 14 M nvidia-libXNVCtrl x86_64 2:375.10-1.fc25 fedora-nvidia 26 k nvidia-settings x86_64 2:375.10-1.fc25 fedora-nvidia 935 k vulkan i686 1.0.30.0-1.fc25 fedora 1.5 M vulkan x86_64 1.0.30.0-1.fc25 fedora 1.4 M vulkan-filesystem noarch 1.0.30.0-1.fc25 fedora 8.0 k Transaction Summary ============================================================================================ Install 20 Packages Total download size: 43 M Installed size: 184 M Is this ok [y/N]: |
As you can see, this system has dkms enabled kernel module and libraries for running 32 bit applications. The amount of data to download for the drivers is really small compared to packages that contain CUDA libraries and tools. All packages have an higher Epoch set; so they should never be upgraded on your system when you enable this repository along the RPMFusion or ELRepo ones.
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. The packages should already take care of this for you, as they should be completely compatible; but better be safe than sorry. This is usually accomplished with the following root command:
yum -y remove \*nvidia\* |
Then, to install the Nvidia driver 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, perform the following command:
dnf -y install nvidia-driver nvidia-settings kernel-devel |
Requirement on kernel-devel is required as otherwise the package kernel-debug-devel is pulled in automatically in place of the normal non-debug package. There is bug opened on dnf/libsolv for this.
Specific driver installations
For both Fedora and CentOS/RHEL distributions it’s possible to install additional packages and / or variant of the basic kernel modules. This paragraph contains some examples. Make sure you have the RPMFusion repository enabled if you plan to use akmod kernel modules on Fedora or EPEL if you plan to use DKMS modules on CentOS/RHEL.
akmod kernel module variant (Fedora):
dnf -y install nvidia-driver kernel-devel akmod-nvidia |
DKMS kernel module variant (Fedora/CentOS/RHEL):
yum/dnf -y install nvidia-driver kernel-devel dkms-nvidia |
To add 32 bit libraries on a 64 bit system (for games or applications like Steam):
yum -y install nvidia-driver-libs.i686 |
Additional driver configuration to your system
To add additional configuration to your system, just create the /etc/X11/xorg.conf file if it does not exist (by default it exists only in Red Hat Enterprise Linux / CentOS 6 systems). 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 headless systems
Your system might only be used for CUDA development and not require the X server to be running the 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 calculation. In this case, the Intel driver should load the modesetting driver, offload the rendering to the Nvidia driver and not use any monitor attached to the X server for the Nvidia driver.
So in this case, I would change /etc/default/grub to remove the nomodeset parameter to make the Intel KMS driver to load properly, regenerate the Grub config file, reboot and use this xorg.conf:
Section "ServerLayout"
Identifier "layout"
Screen 0 "intel"
Inactive "nvidia"
EndSection
Section "Device"
Identifier "nvidia"
Driver "nvidia"
BusID "<BusID for NVIDIA device here>"
EndSection
Section "Screen"
Identifier "nvidia"
Device "nvidia"
Option "AllowEmptyInitialConfiguration"
EndSection
Section "Device"
Identifier "intel"
Driver "modesetting"
EndSection
Section "Screen"
Identifier "intel"
Device "intel"
EndSection |
An example of the above can also be read in the official documentation.
The device file /dev/nvidia0 is normally created when loading the Nvidia driver, so if the X driver is not loaded the device file fileis not created. You can use the nvidia-modprobe command that is in the package with the same name.
It contains a SUID binary that creates the device files and set the appropriate permissions when automatic device creation is not available. It is called directly by Nvidia libraries:
$ for i in $(rpm -ql nvidia-driver-libs.x86_64); do strings $i | grep nvidia-modprobe > /dev/null && echo $i done /usr/lib64/libnvidia-cfg.so.1 /usr/lib64/libnvidia-cfg.so.381.22 /usr/lib64/libnvidia-eglcore.so.381.22 /usr/lib64/libnvidia-glcore.so.381.22 /usr/lib64/libnvidia-glsi.so.381.22 /usr/lib64/vdpau/libvdpau_nvidia.so.1 /usr/lib64/vdpau/libvdpau_nvidia.so.381.22 |
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. Installing these, thegpu-deployment-kitdependency provided by the CUDA repositories was preserved. 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 NVENC (Nvidia Encoder) header, 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. With the new packaging organization, the original
cuda-develandcuda-extra-libswill pull in all the specific subpackages giving you the same situation you are accustomed to. Also, for the same reason, static libraries have been included in each respectivedevelsubpackage. - 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
| Operating system | el6 / el7 | f24 / f25 / f26 | f27 |
|---|---|---|---|
| CUDA branch/version | 8.0.61 + cuBLAS patch | 8.0.61 + cuBLAS patch | 9.1.85 |
| CUDA cuDNN version | 5.1.10 6.0.20 7.0.5.15 | 5.1.10 6.0.20 7.0.5.15 | 7.0.5.15 |
| GCC compatibility | - | compat-gcc-53 (5.3.1) | cuda-gcc (6.4.0) |
| Basic CUDA libraries/tools: cuda cuda-libs cuda-extra-libs cuda-cublas cuda-cudart cuda-cufft cuda-cudnn cuda-cupti cuda-curand cuda-cusolver cuda-cusparse cuda-npp cuda-nvgraph cuda-nvrtc cuda-nvvp | Yes | Yes | Yes |
| CUDA development: cuda-cli-tools cuda-devel cuda-cublas-devel cuda-cudart-devel cuda-cudnn-devel cuda-cufft-devel cuda-cupti-devel cuda-curand-devel cuda-cusolver-devel cuda-cusparse-devel cuda-npp-devel cuda-nvgraph-devel cuda-nvml-devel (also i686) cuda-nvrtc-devel | Yes | Yes | Yes |
| Java GUI programs: cuda-nsight cuda-nvvp | Yes | Yes | Yes |
| Documentation and samples cuda-samples cuda-docs (noarch) | Yes | Yes | Yes |
CUDA installations
To install just a runtime CUDA support (required for running CUDA enabled programs):
yum -y install cuda nvidia-driver-cuda |
To install packages required for enabling CUDA development:
yum -y install cuda-devel |
or, if you need to develop some application that requires multiple libraries:
yum -y install cuda-devel |
A couple of examples. Just the basic tools:
$ sudo dnf install cuda Last metadata expiration check: 0:00:20 ago on Sun Oct 23 13:11:01 2016. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: cuda x86_64 1:8.0.44-4.fc24 fedora-nvidia 95 M cuda-cufft x86_64 1:8.0.44-4.fc24 fedora-nvidia 97 M cuda-curand x86_64 1:8.0.44-4.fc24 fedora-nvidia 38 M cuda-libs x86_64 1:8.0.44-4.fc24 fedora-nvidia 6.4 M Transaction Summary ================================================================================ Install 4 Packages Total size: 236 M Installed size: 469 M Is this ok [y/N]: |
The basic tools along with all the libraries (note that the NVML headers are included):
$ sudo dnf install cuda-devel Last metadata expiration check: 0:10:00 ago on Sun Oct 23 13:11:01 2016. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: cuda x86_64 1:8.0.44-4.fc24 fedora-nvidia 95 M cuda-cublas x86_64 1:8.0.44-4.fc24 fedora-nvidia 21 M cuda-cublas-devel x86_64 1:8.0.44-4.fc24 fedora-nvidia 38 M cuda-cudart x86_64 1:8.0.44-4.fc24 fedora-nvidia 131 k cuda-cudart-devel x86_64 1:8.0.44-4.fc24 fedora-nvidia 659 k cuda-cufft x86_64 1:8.0.44-4.fc24 fedora-nvidia 97 M cuda-cufft-devel x86_64 1:8.0.44-4.fc24 fedora-nvidia 73 M cuda-cupti x86_64 1:8.0.44-4.fc24 fedora-nvidia 1.2 M cuda-cupti-devel x86_64 1:8.0.44-4.fc24 fedora-nvidia 213 k cuda-curand x86_64 1:8.0.44-4.fc24 fedora-nvidia 38 M cuda-curand-devel x86_64 1:8.0.44-4.fc24 fedora-nvidia 60 M cuda-cusolver x86_64 1:8.0.44-4.fc24 fedora-nvidia 23 M cuda-cusolver-devel x86_64 1:8.0.44-4.fc24 fedora-nvidia 4.1 M cuda-cusparse x86_64 1:8.0.44-4.fc24 fedora-nvidia 23 M cuda-cusparse-devel x86_64 1:8.0.44-4.fc24 fedora-nvidia 23 M cuda-devel x86_64 1:8.0.44-4.fc24 fedora-nvidia 1.6 M cuda-libs x86_64 1:8.0.44-4.fc24 fedora-nvidia 6.4 M cuda-npp x86_64 1:8.0.44-4.fc24 fedora-nvidia 91 M cuda-npp-devel x86_64 1:8.0.44-4.fc24 fedora-nvidia 47 M cuda-nvgraph x86_64 1:8.0.44-4.fc24 fedora-nvidia 4.6 M cuda-nvgraph-devel x86_64 1:8.0.44-4.fc24 fedora-nvidia 12 k cuda-nvml-devel x86_64 1:8.0.44-4.fc24 fedora-nvidia 41 k cuda-nvrtc x86_64 1:8.0.44-4.fc24 fedora-nvidia 6.6 M cuda-nvrtc-devel x86_64 1:8.0.44-4.fc24 fedora-nvidia 16 k Transaction Summary ================================================================================ Install 24 Packages Total size: 655 M Installed size: 1.4 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.
Hello and thank you again for this repo!
One of my home PCs keeps having it’s akmodsbuild fail for the NVIDIA drivers. Could you please give me some tips for troubleshooting this, or do you know where I should ask?
To try to resolve I’ve installed mock (creating a mock group) and created a mockbuild user since that didn’t exist and there were warnings in the log. I’ve previously forced the build as root which may have mucked up permissions, so I recursively set them all back to ‘akmods:akmods’.
When I run a build manually it works, but never automatically.
For example, when run this works:
sudo -H -u akmods bash -c ‘nice /sbin/akmodsbuild –target x86_64 –kernels 4.14.11-300.fc27.x86_64 /usr/src/akmods/nvidia-kmod.latest’
The logs have:
2018/01/05 06:02:46 akmods: Building RPM using the command ‘/sbin/akmodsbuild –target x86_64 –kernels 4.14.11-300.fc27.x86_64 /usr/src/akmods/nvidia-kmod.latest’
2018/01/05 06:02:50 akmods: Building rpms failed; see /var/cache/akmods/nvidia/387.34-1-for-4.14.11-300.fc27.x86_64.failed.log for details
and:
2018/01/05 06:02:46 akmods: Building RPM using the command ‘/sbin/akmodsbuild –target x86_64 –kernels 4.14.11-300.fc27.x86_64 /usr/src/akmods/nvidia-kmod.latest’
Session terminated, killing shell… CONFTEST: follow_pfn
CONFTEST: hash__remap_4k_pfn
CONFTEST: vmap
CONFTEST: set_pages_uc
CONFTEST: set_memory_uc
CONFTEST: set_memory_array_uc
CONFTEST: change_page_attr
CONFTEST: pci_get_class
CONFTEST: pci_choose_state
CONFTEST: vm_insert_page
CONFTEST: acpi_device_id
CONFTEST: acquire_console_sem
CONFTEST: console_lock
CONFTEST: kmem_cache_create
CONFTEST: on_each_cpu
CONFTEST: smp_call_function
CONFTEST: acpi_evaluate_integer
make[2]: *** Deleting file ‘/tmp/akmodsbuild.12O2Etr3/BUILD/nvidia-kmod-387.34-x86_64/kmod_build_4.14.11-300.fc27.x86_64/conftest/compile-tests/acpi_evaluate_integer.h’
make[2]: *** Deleting file ‘/tmp/akmodsbuild.12O2Etr3/BUILD/nvidia-kmod-387.34-x86_64/_kmod_build_4.14.11-300.fc27.x86_64/conftest/compile-tests/smp_call_function.h’
make[2]: *** Deleting file ‘/tmp/akmodsbuild.12O2Etr3/BUILD/nvidia-kmod-387.34-x86_64/_kmod_build_4.14.11-300.fc27.x86_64/conftest/compile-tests/on_each_cpu.h’
make[2]: *** Deleting file ‘/tmp/akmodsbuild.12O2Etr3/BUILD/nvidia-kmod-387.34-x86_64/_kmod_build_4.14.11-300.fc27.x86_64/conftest/compile-tests/kmem_cache_create.h’
make[2]: *** [/tmp/akmodsbuild.12O2Etr3/BUILD/nvidia-kmod-387.34-x86_64/_kmod_build_4.14.11-300.fc27.x86_64/Kbuild:119: /tmp/akmodsbuild.12O2Etr3/BUILD/nvidia-kmod-387.34-x86_64/_kmod_build_4.14.11-300.fc27.x86
64/conftest/compile-tests/kmem_cache_create.h] Terminated
make[2]: *** [/tmp/akmodsbuild.12O2Etr3/BUILD/nvidia-kmod-387.34-x86_64/kmod_build_4.14.11-300.fc27.x86_64/Kbuild:119: /tmp/akmodsbuild.12O2Etr3/BUILD/nvidia-kmod-387.34-x86_64/_kmod_build_4.14.11-300.fc27.x86
64/conftest/compile-tests/on_each_cpu.h] Terminated
make[2]: *** [/tmp/akmodsbuild.12O2Etr3/BUILD/nvidia-kmod-387.34-x86_64/kmod_build_4.14.11-300.fc27.x86_64/Kbuild:119: /tmp/akmodsbuild.12O2Etr3/BUILD/nvidia-kmod-387.34-x86_64/_kmod_build_4.14.11-300.fc27.x86
64/conftest/compile-tests/smp_call_function.h] Terminated
make[2]: *** [/tmp/akmodsbuild.12O2Etr3/BUILD/nvidia-kmod-387.34-x86_64/kmod_build_4.14.11-300.fc27.x86_64/Kbuild:119: /tmp/akmodsbuild.12O2Etr3/BUILD/nvidia-kmod-387.34-x86_64/_kmod_build_4.14.11-300.fc27.x86
64/conftest/compile-tests/acpi_evaluate_integer.h] Terminated
make[1]: *** wait: No child processes. Stop.
make[1]: *** Waiting for unfinished jobs….
make[1]: *** wait: No child processes. Stop.
make: *** [Makefile:84: modules] Error 2
/var/tmp/rpm-tmp.PTVsUG: line 31: 26461 Terminated make -j4 IGNORE_XEN_PRESENCE=1 IGNORE_PREEMPT_RT_PRESENCE=1 IGNORE_CC_MISMATCH=1 SYSSRC=”${kernel_version##*___}” module
error: Bad exit status from /var/tmp/rpm-tmp.PTVsUG (%build)
After last update of nvidia-settings, I can’t use nvidia-driver anymore…
nvidia-settings show an error:
“You do not appear to be using the nvidia x server”.
I’ve tried to remove and reinstall nvidia driver from your repo… any suggestions?
File: /etc/default/grub
GRUB_CMDLINE_LINUX=”rd.driver.blacklist=nouveau rhgb quiet”
Please re-enable SELinux, you should not disable it. Try to uncomment this in
/etc/gdm/custom.conf:Kernel modules for current nvidia doesn’t build with kernel >= 4.14.9. 🙁
See for example here:
http://rglinuxtech.com/?p=2172
Could you please include this patch in your next package version:
https://devtalk.nvidia.com/default/topic/1028016/linux/patch-for-compiling-v384-98-modules-with-linux-v4-14-9-/
Tried it also with 4.14.11 like:
dkms install nvidia/384.98 -k 4.14.11-1.el7.elrepo.x86_64
and it was successful.
Thx,
Andreas
Release 384.111 should fix it, but I’m waiting for them to release the source tarballs for the various components: https://github.com/NVIDIA/nvidia-settings/issues/20
I finally compiled Tensorflow from source using these drivers – my notes / patches are here (https://github.com/tensorflow/tensorflow/pull/15614) in case anyone finds it useful!
Thanks, will make a note. I was actually thinking of packaging TensorFlow directly, so many people are using it (I’m not).
I also met the freeze issue. The Nvidia driver seems to be working but after input username/password on the GDM login screen the system become completely hangs with CPU fans run at full speed. Neither can I move the mouse cursor nor switch to other TTYs.
I finally solved this issue by disabling the nouveau driver fallback mechanism with
sudo systemctl status nvidia-fallback. Not sure why this would cause trouble.I am using Fedora 27 + kernel 4.14.7-300.fc27.x86_64 + nvidia-driver-387.34-1.fc27 + X11 + Gnome 3.26.2 + EFI boot + Secure Boot disabled + Selinux disabled.
Hardware: GTX 1070 Mobile.
Please re-enable SELinux, you should not disable it. Try to uncomment this in
/etc/gdm/custom.conf:What is the way to install xorg-x11-drv-nvidia-cuda with your repo? I need it for NVDEC accleration in ffmpeg .
You don’t use that package name. Look at the instructions: https://negativo17.org/nvidia-driver/
Giving this a spin on F27 and have discovered an issue that I would appreciate any input on.
Running your same repo on Centos 7 with driver version 384.98 the following command worked as expected when setting clock values. After the move to F27 and the latest 387.34, the command works ONLY for GPU0. Running the command against any other GPU in the system is silently ignored.
sudo /usr/bin/xinit /usr/bin/nvidia-settings -a [gpu:0]/GPUMemoryTransferRateOffset[3]=500 — :0 -once
Running the following command sees all 6 GPUs in my case.
sudo /usr/bin/xinit /usr/bin/nvidia-settings -q gpus — :0 -once
FWIW, after downgrading to 387.22 the problem still exists.
After reverting the F27 system to 384.98, I see that the same problem exists there. The Centos7 system is running kernel v3 and F27 is on kernel v4. Not sure if there could be some differences in the newer kernel that could prevent accessing these other devices.
Again, open to any suggestions.
On Fedora 27 “sudo dnf -y install cuda nvidia-driver-cuda cuda-devel” leads to
CMake Error at /usr/share/cmake/Modules/FindCUDA.cmake:682 (message):
Specify CUDA_TOOLKIT_ROOT_DIR
Call Stack (most recent call first):
libhwmon/CMakeLists.txt:13 (find_package)
cmake probably expects /usr/local/cuda. How to fix this? Thank you!
Well, the command does not lead to the error. The commands install the packages, and then you’re trying to use some CMake based build to build something. What are you building? You need to make sure it finds CUDA installed in the system paths and the header files at /usr/include/cuda. Is it ethminer?
Correct (apologies for the imprecise wording): cmake .. -DETHASHCUDA=ON -DETHASHCL=OFF fails for ethminer. rpm -ql cuda shows the locations but they are distributed.
I tried almost everything I could think of but failed; perhaps s.o. more savy can have a go at it?
CUDA_INC_PATH=/usr/include/cuda is set by default
CUDA_TOOLKIT_ROOT_DIR=/usr is the best I can think of to add
No luck!
git clone –recursive https://github.com/ethereum-mining/ethminer.git
cd ethminer
mkdir build; cd build
cmake3 .. -DETHASHCUDA=ON -DETHASHCL=OFF -DETHDBUS=OFF
cmake3 –build .
sudo make install
CMake Error at /usr/share/cmake/Modules/FindCUDA.cmake:682 (message):
Specify CUDA_TOOLKIT_ROOT_DIR
Call Stack (most recent call first):
libhwmon/CMakeLists.txt:13 (find_package)
To answer my own question, no they do not support Tesla graphics cards. 🙁
The NVIDIA UNIX drivers http://www.nvidia.com/object/unix.html are different to the TESLA driver for Linux (RHEL7) http://www.nvidia.com/download/driverResults.aspx/124725/en-us
Not happy with NVIDIA for making that so unclear. It wasn’t until I’d tried every driver available that I learned it.
Ouch, I did not know. Considering that the Tesla driver is at 384.81, you can probably rebuild the RHEL packages which are at 384.98. Or figure out if the list of supported chips is something you can just “bolt in” in some header or similar.
Then I can probably force it in the packages.
Thanks Slaanesh.
The NVIDIA documentation link was sending me to an old version of the driver. When I updated the URL to the current version (http://us.download.nvidia.com/XFree86/Linux-x86/384.98/README/supportedchips.html) I found that the Tesla M60’s are supported!
I suspect our problem is that we need to update the VMware drivers (VIBs) underneath the vGPUs presented to Linux virtual machines to a newer version. So I’m going to have a colleague do that and try your drivers again.
For the record, after updating ESXi to use NVIDIA 384.99 driver VIBs I could not get a 384.84 driver to work in a RHEL 7.4 VM with vGPU (Tesla M60) presented to it.
However the 384.99 version (“NVIDIA Accelerated Graphics Driver for Linux-x86_64 384.99”) included in the Tesla driver download did work.
The annoying thing is that the public downloads page only shows 384.81 drivers. GRR!
More detail on my previous comment:
We have Tesla M60 graphics cards, which report as GM204GL (Maxwell) chips.
I did this on freshly installed fedora 27 ( I have 1080 ti gpu)
sudo dnf install nvidia-settings kernel-devel dkms-nvidia vulkan.i686 nvidia-driver-libs.i686
and then reboot: The system gets stuck for ever.
Thanks for the great repo, I rely on it at home!
Could you please confirm if these drivers support the NVIDIA Tesla server graphics cards. They’re used for VM desktop graphics acceleration.
Thanks!
Do all these drivers and features work with a plain install of Fedora 27 as of Dec 4 2017? I’m interested in using 4 monitors and doing GPU programming.
It seems that maybe wayland is NOT supported directly (meaning additional links and instructions must be followed). Since wayland is the default on F27 this is an important issue. I personally don’t want to follow other links which may or may not be up to date and work or not work and be easily uninstalled or not. I appreciate the work done on this driver, but I believe it is crucial to document what exactly the driver will work with. 🙂
Hey guys,
On a fresh fedora 27 xfce, I tried installing this drivers. Laptop is an ASUS k556u laptop (nvidia 940mx and intel HD graphics 620)
after reboot, i see the fedora logo loading and then black screen.
I am able to drop to shell using ctr+alt+f2
i dont see any errors are at Xorg logs. No errors at /var/log/messages either.
on .xfce4-sessions log i see “received save timeout client will be disconnected now”
startx will launch, as initx will as well, but they will all remain in a black screen.
Any ideas ho how to fix?
Hi Simone,
Ever since the upgrade:
Upgraded nvidia-driver-2:387.22-1.fc27.x86_64 @fedora-multimedia
Upgrade 2:387.34-1.fc27.x86_64 @fedora-multimedia
the Nvidia driver no longer loads, but instead falls back to nouveau even when nouveau is blacklisted.
I notice it looked like some scriptlet failed during that particular update but I am not sure if it is related.
Scriptlet output:
1
2 UPGRADE: Automatically re-enabling default systemd units: fedora-import-state.service fedora-readonly.service
3
4 ln: target ‘/boot/dtb’ is not a directory
5 cat: write error: Broken pipe
Not sure if something got corrupted.
Let me know what you think, and thanks again for the great repo.
-Tom
Sorry to bug you, Simone!
After the kernel update to 4.13.16-302.fc27.x86_64 this seemed to resolve itself. Appears unrelated to the driver and only manifested (for some reason) on 4.13.16-300.fc27.x86_64. Managed to repro the issue with that particular version on two machines no less!
Thanks again,
Tom
on fedora 27 i cant install it the gnome software way… nouveau still active after reboot. if i install it over commandline everything works fine.
For all those who have had problems with this driver and have tried the various suggestions in the thread without result. That was me. I spent hours trying to work it out.
In the end, the solution was simple. Edit /etc/gdm/custom.conf and uncomment the “WaylandEnable=false”. Save, reboot and away you go.
HTH.
Hi,
First of all, thanks for your effort.
Second, I’m the case when Secure Boot is desired to be preserved.
After installing the nvidia package, I
– locate the module (/lib/modules/…/extra/nvidia)
– unxz nvidia.ko.xz , sign it, xz it back
– modprobe it, reboot
– Details not showing that nvidia is working now, though lspci says nvidia is it is a kernel driver for 3d controller
problems:
– does not actually work – CS:GO hangs
– dnf upgrade –refresh apparently loses the signiture and nouvaue returns after it.
Can you please correct me in this steps?
Hi, I just tried to install nvidia drivers on a clean F27 system, and after the reboot the system becomes unusable due to gnome-shell hogging the CPU (load goes above 9.0). Even the login screen shows this behavior. Reverting back to nouveau makes system usable again. Any idea what’s going on? I have a GTX 750 Ti. Thanks!
Uh… I don’t know exactly what happened, but I decided to reinstall nvidia driver to get some additional info, and to my surprise it is working just fine now, no CPU hogs or such. Sorry for the noise, nothing to see here, move on 😉
I can’t install driver because package is not at same version :
nvidia-driver.x86_64 2:384.69-1.fc25 fedora-nvidia
nvidia-settings.x86_64 2:387.22-1.fc25 fedora-nvidia
dkms-nvidia.x86_64 2:387.22-1.fc25 fedora-nvidia
kmod-nvidia.x86_64 2:387.22-1.fc25 fedora-nvidia
akmod-nvidia.x86_64 2:387.22-1.fc25 fedora-nvidia
Can you fix it ?
I don’t know what you did, but the packages have explicit dependencies on each other version/release, so it’s not even possible that you get that result without forcing things.
The 387.22 packages are all already in the repository: https://negativo17.org/repos/nvidia/fedora-25/x86_64/
Hi there, I know that this is not your problem but I would like to install and manage my nvidia drivers through the negativo repo. But I have installed them with this guide through nvidia: https://www.if-not-true-then-false.com/2015/fedora-nvidia-guide/
Now, I don’t know how to cleanly uninstall all this mess and start off fresh. Any tips would be appreciated?
Look at the
uninstallparameter of the Nvidia installer.I added the repo and then installed the driver and graphics control panel from software center. But when i click on the control panel nothing happens. I mean it doesn’t open and how do i switch to nvidia drivers ?
What could be the issue ?
ARGH! I installed your driver on F26 (GTX 650 Ti) and had ABYSMAL graphics performance. Slow, stuttering, graphics artifacts etc. I’ve been looking for a solution for months, to finally be able to play games on Linux.
Everything was supposed to be fine: the Nvidia control panel was working, direct rendering was ‘on’, showed the proper graphic device, didn’t complain about the kernel module not being loaded.
But all games ran awfully slow, especially compared to the fact that they ran nicely in Windows!
So, I had the following installed:
akmod-nvidia
kmod-nvidia-…
nvidia-driver-libs
nvidia-settings.
You know what solved my problem after searching for weeks and finding no solution?
Installing the seemingly optional nvidia-modprobe package… now my system works great, games run wonderfully.
What does it do and if it’s optional, why does it improve performance so much?
I just updated my f26 machine to the 387.22 nvidia drivers, and they produce errors / soft+hard lockups / udev crashes on my system. Any idea what could cause that? Downgrading the drivers to 384.90 again resolves the issue.
Comparing logs between booting with old and new drivers, the only difference are those log entries concerning lockups and crashes: https://gist.github.com/decathorpe/a5a896fbea931ad1a7d2ef6d4aa42847
Hi! I’m using Fedora 27 beta and after installing this repo the nouveau driver is used instead of nvidia. I ran on Gnome, Gnome Classic and Gnome Xorg, but the same driver still loads. Here there are commands I run:
lspci | grep VGA
01:00.0 VGA compatible controller: NVIDIA Corporation GP106M [GeForce GTX 1060 Mobile 6GB] (rev a1)
uname -r
4.13.9-300.fc27.x86_64
dnf list installed nvidia
Installed packets
dkms-nvidia.x86_64 2:387.12-2.fc27 @fedora-nvidia
nvidia-driver.x86_64 2:387.12-1.fc27 @fedora-nvidia
nvidia-driver-libs.i686 2:387.12-1.fc27 @fedora-nvidia
nvidia-driver-libs.x86_64 2:387.12-1.fc27 @fedora-nvidia
nvidia-libXNVCtrl.x86_64 2:387.12-1.fc27 @fedora-nvidia
nvidia-settings.x86_64 2:387.12-1.fc27 @fedora-nvidia
lshw -numeric -C display
*-display
description: VGA compatible controller
product: GP106M [GeForce GTX 1060 Mobile 6GB] [10DE:1C60]
vendor: NVIDIA Corporation [10DE]
physical id: 0
bus info: pci@0000:01:00.0
version: a1
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress vga_controller bus_master cap_list rom
configuration: driver=nouveau latency=0
resources: irq:128 memory:db000000-dbffffff memory:90000000-9fffffff memory:a0000000-a1ffffff ioport:e000(size=128) memory:c0000-dffff
I heard about EAGLStreams repo from Nvidia that allows to run their driver on Wayland. Should it help? How safe is it?
Are you using Wayland for GDM? You need an EGLStream enabled Mutter, like: https://copr.fedorainfracloud.org/coprs/mati865/mutter-eglstream/
Sorry to reply late. Yes, I’m using it. Few days before there was update which caused that driver if logged to xorg mode was loaded. I installed the mutter exactly from the provided link but nouveau driver loads.
Also happening with me. That link does nothing with 3.13.12-300 f27 kernel.
I’ve tried all I could but only the last kernel (3.13.12-200) or earlier that I had in use with Fedora 26 works.
Secure boot is disabled. uninstall nvidia package, reinstall, reboot, eglstream, whatever.
Tested also with disablement of Wayland:
loginctl show-session 2 -p Type
Type=x11
lspci -nnk | grep -iA2 vga
Kernel driver in use: nouveau
Edit button: 4.13.
The link has caused it to fail on the older kernels as well. So awesome!
OK! So managed to get the older kernels working with the nvidia driver again (though as I type this 4.13.12-200 f26 is working a bit oddly. Figure that out later.) 4.13.12-300 still does not work and still shows nouveau.
lspci -nnk | grep -iA2 vga
Kernel driver in use: nvidia
loginctl show-session 1 -p Type
Type=wayland
It went something like this:
removed linked mutter repo and undid all that from link
reinstalled mutter
remove then installed negativo17.org driver
su -c ‘dnf -y –allowerasing install xorg-x11-drv-nvidia-libs.i686’
reboot into older kernel and nvidia driver was back
After more testing, have been unable to get nvidia drivers working at all now with wayland or xorg. Even removed gdm, mutter, wayland and all nvidia packages regardless of how I do it. Even with the linked mutter. Nothing at all.
Its interesting to note that nvidia-settings has error:
ERROR: Unable to find display on any available system
And adding generated xconfig causes boot to get stuck pre-login
No dnf command found on this page seems to fix it as well
So I’m now out of ideas. It just seems to be completely broken.
For reference, my solution was to install Nvidia proprietary driver without negativo17. Nouveau has a freeze bug for me so couldn’t exactly wait around for this to be fixed.
Fixed with https://copr.fedorainfracloud.org/coprs/mati865/mutter-eglstream/
It was a reply but something went wrong.
Suggestion:
Is it how doable to do GPU Switching for Optimus laptops? Ubuntu has made Dirty hack which allows switching between Intel/Nvidia. I suppose that “offloading” would be THE way to do it like in Windows, but far as I know that is not happening in Linux.
Would be super helpful on Laptop to decide between Performance vs PowerSave. Batter time with only intel can be like 7 hours, but on nividia its max 2 hours, but commonly just 1 hour. (just my Dell Laptop measures)
I have two Fedora 26 laptops. Both has Intel with Optimus. (Haswell + Kaby Lake and Quadro 2100K + GeForce 1050 Ti)
My experience with fresh installs is:
–> Wayland is working with Intel
–> Xorg is working with Nvidia
This is kinda nice… I can EASILY switch to Powersave Intel / Powerful Nvidia by just relogging.
I don’t know if this is the intended way it should work. I understood that Nvidia should now work with Wayland? Or is that coming from Fedora 27?
Wayland is not yet supported with Nvidia drivers. You can try to use one of these repositories:
https://copr.fedorainfracloud.org/coprs/mati865/mutter-eglstream/
https://copr.fedorainfracloud.org/coprs/mvicomoya/mutter-eglstream/
Thank you from clarification. I think I will wait still before I break my system. 🙂 Also few things does not work in Wayland, example Shutter which I use daily basis.
Can you tell the all ur steps of the install with kaby lake + 1050ti? Thanks
I’m using fresh installed Fedora 26 and I get the following msg when I’m trying :
dnf remove *nvidia*
Error:
Problem: The operation would result in removing the following protected packages: kernel-core
how can I fix that?
Can you paste the full output of the command?
That was the full output of the command but I can give more information about the kernel I’m using and graphics card:
dnf list installed nvidiaInstalled Packages
kernel-core.x86_64 4.11.8-300.fc26 @anaconda
kernel-core.x86_64 4.13.5-200.fc26 @updates
kernel-modules.x86_64 4.11.8-300.fc26 @anaconda
kernel-modules.x86_64 4.13.5-200.fc26 @updates
linux-firmware.noarch 20170828-77.gitb78acc9.fc26 @updates
uname -r
4.11.8-300.fc26.x86_64
lspci |grep -E “VGA|3D”
05:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 770] (rev a1)
any idea?
Same here.
I tried to use negativo drivers, but after reboot (GTX 1080) it gave me a black screen, then I tried to reinstall Fedora, but it failed (broke EFI partition) and I had to reinstall Windows in result.