The post install instructions say to run make on the sample files. This completed with no errors. Then when I run deviceQuery it FAILS with “no CUDA-capable device is detected”. The 8.0 toolkit seems to install nvidia-367 driver. I saw in another post a method to check recommended drivers on Ubuntu as follows:
$ sudo ubuntu-drivers devices
== /sys/devices/pci0000:00/0000:00:03.0/0000:4b:00.0 ==
vendor : NVIDIA Corporation
modalias : pci:v000010DEd00001B00sv000010DEsd0000119Abc03sc00i00
driver : nvidia-367 - third-party free
driver : nvidia-375 - third-party free recommended
driver : nvidia-370 - third-party free
driver : xserver-xorg-video-nouveau - distro free builtin
Then you can install using sudo apt-get install nvidia-375
This will remove nvidia-367 and some other related packages. When it finishes deviceQuery will PASS properly. I am not clear whether it is the newer driver or just installing the driver again after the normal install instructions that make everything work.
So my questions follow
Why it did not work from following the instructions?
Would it have worked if I chose nvidia-367 and just reinstalled it instead of nvidia-375
Since nvidia-375 removed a bunch of packages and not all were replaced, am I in any danger of something not working correctly?
As a side note, I got to this same point (“no cuda capable device found”) on a previous deb install and gave up the deb package method in favor of a runfile install. That choice was a disaster that resulted in an infinite login loop that cost me about a day and a half to find a fix for. I will make a separate post on that.
Mixing and matching different install methods will likely result in a mess. My recommendation would be to always (and exclusively) use the runfile installer method.
Sorry, I don’t know how to clean up the mess that likely resulted from the multiple installation attempts.
While I am sure that I made some mistakes mixing and matching during install, I am curious as to why you strongly recommend the runfile approach over deb package? Is there a fundamental difference? Thanks for your response.
I have since successfully installed using deb package. I will create a separate post on the problems I had with the runfile install which made me not want to attempt runfile again. It was a disaster for me that resulted in an infinite login loop. Again, likely because I did some things wrong.
Why am I recommending the runfile installer? Because in my experience it works 100% of the time (across literally hundreds of installs), something that cannot be said for packaged installers. Since mixing runfile and package installers is a recipe for disaster, the corollary is to use the runfile installer exclusively.
Other people’s experience may differ. In particular, I have never used Ubuntu, and I have no intention of using it if it can be avoided. I observe that 95% of all CUDA problems on Linux seem to be on Ubuntu. This may have something to do with the people who use Ubuntu, and partially attributable to its high market share, but I would mostly blame the OS itself. Again, other people may have a different assessment.
You can get either a r367 or an r375 driver to work correctly on Ubuntu 14.04 and CUDA 8. I have personally installed both.
In each case, I carefully followed the instructions in the linux install guide and it worked. I don’t know what went wrong in your case exactly, there is not enough information to diagnose it. However, I do know that previous system history matters, and in general the install guide instructions more or less assume a clean OS install as a starting point. It requires a considerable amount of info to diagnose a broken install.
I mentioned reinstall the OS for this reason. Not because it is mandatory but it establishes a communicable known starting point to someone else on the other end of the forum thread, and my focus was to point out the necessity to not install the OpenGL libs for a runfile install that is going on a system where X is running and the X display is not hosted by an NVIDIA GPU. My focus in the other thread was not to diagnose a broken install.