An error when installing Cuda Toolkit on TX2

I encountered problems when I am installing CUDA 9.1 Toolkit on my TX2 and I don’t know if I made an installation error :

The install commands I made:

cd ~/Downloads &&
wget &&
sudo dpkg -i cuda-repo-ubuntu1604-9-1-local_9.1.85-1_amd64.deb &&
sudo apt-key add /var/cuda-repo-9-1-local/ &&
sudo apt-get update &&
sudo apt-get install cuda

The error message I have:

cuda-repo-ubuntu160 100%[===================>] 1.12G 371KB/s in 34m 16s

2018-06-26 10:14:57 (570 KB/s) - ‘cuda-repo-ubuntu1604-9-1-local_9.1.85-1_amd64’ saved [1200903100/1200903100]

[sudo] password for nvidia:
dpkg: error processing archive cuda-repo-ubuntu1604-9-1-local_9.1.85-1_amd64.deb (–install):
cannot access archive: No such file or directory
Errors were encountered while processing:

An error happens when unpacking the deb file. Anyone could help me please?

The message error was:

[sudo] password for nvidia:
dpkg: error processing archive cuda-repo-ubuntu1604-9-1-local_9.1.85-1_amd64 (–install):
package architecture (amd64) does not match system (arm64)
Errors were encountered while processing:

In my opinion, what you are trying to do is to install cuda somehow from Jetson. Moreover you are approaching different architecture [processor instruction set] package.
I would rather execute post-installation scripts from Jetpack for installing cuda from Host PC.

  1. run Jetpack
  2. select post install actions and make sure cuda installation will be processed
    That, hopefully will deliver selected packages to Jetson over network somehow.
    Otherwise you may approach
    But I would advise to use Jetpack method.
    More reference:

Thank you for answering Andrey1984, I will try that.

FYI, this is for the PC, not the Jetson:

Also, any wget URLs of packages which were previously under JetPack3.2 seem to have a bug now. The repository.json no longer gives a valid URL and needs to be fixed somewhere on the NVIDIA servers (it’s reverting to JetPack3.1 URLs and broken links…it seems the deprecation of 3.2 in favor of 3.2.1 has left the older package unusable).

If you use JetPack, then use 3.2.1 instead of 3.2. If you use a URL with wget from repository.json, then generate a new file from 3.2.1 prior to looking for the URL.

Yes, that’s what I noticed. In my case, when I am installing the JetPack3.2.1, it goes very well until the installation of Ubuntu. But, it’s after that it goes badly. All other components Cuda, TensorRT, OpenCV, Vision Modules, MMAPI, … are not installed. In fact, many .deb, .tar, … files are downloaded to the host machine (Ubuntu 14.04 virtual machine), but they are not installed on the TX2. Actually, I don’t know if it comes from the use of a virtual machine, the slowness of my internet line or because its weak throughput.

This is why I am looking for an alternative way to download and install these components independentlly of the interface used by the JetPack3.2.1. If there is a way to download these different components and install them independently, that would interest me a lot.

Thank you for your reply.

VM’s are known source of issues.
You should avoid using VM for flashing OS.

Yes, a VM would be a problem. Is it a VM? Lots of strange things happen with a VM.

I understand the desire to be able to flash or install packages without JetPack, but for the purposes of testing, are you using a native Ubuntu 16.04 host? If so, then there should be a log for JetPack. You could uncheck all of the flash steps, and manually enter the IP address, then post the log.

Regardless of whether JetPack is used or not, what happens if you log in via ssh from the host PC to the nvidia account and run:

sudo apt update

…if it fails, let it wait for perhaps 30 minutes, and then try again (mainly I want to see if it says it is in use already…and if so, what happens if you wait 30 minutes and try again without rebooting.

If it fails due to lock, see what you get from:

sudo lsof /var/lib/dpkg/lock

Should nothing be using the lock file it may be there is a stale lock from a previous failed dpkg operation. Note that you can watch this via:

sudo watch -n 1 lsof /var/lib/dpkg/lock

Any lock might appear and disappear quite quickly though, so changes basically mean staring at the watch command…but you can run this command while actually trying to update or add packages and it should at least momentarily lock, and then after finished lsof should show lock is no longer accessed.

That the VM would be the cause of my mishaps seems logical. Question of testing, I will try this morning what you propose me.

VMs will cause a lot of unhappiness :(

If I can find a solution, I will publish it through the forum for others that would be in my case.

Thanks guys


I am trying to install CUDA 10.2 and also I encountered the same error. Did you find any solution for your same issue.