Flashing Jetson TX2 from Ubuntu 16.04 host machine

I am trying to flash Jetpack 3.0 to the Jetson TX2 and it seems that everything worked properly, until trying to install CUDA. The following are the last lines of the terminal before the flash froze.

Copying cuda-repo-l4t-8-0-local_8.0.64-1_arm64.deb file to target...
  1,270,096,932 100%   10.73MB/s    0:01:52 (xfr#1, to-chk=0/1)

sent 1,270,407,130 bytes  received 35 bytes  11,193,014.67 bytes/sec
total size is 1,270,096,932  speedup is 1.00
Selecting previously unselected package cuda-repo-l4t-8-0-local.
(Reading database ... 148984 files and directories currently installed.)
Preparing to unpack .../cuda-repo-l4t-8-0-local_8.0.64-1_arm64.deb ...
Unpacking cuda-repo-l4t-8-0-local (8.0.64-1) ...
Setting up cuda-repo-l4t-8-0-local (8.0.64-1) ...
Get:1 file:/var/cuda-repo-8-0-local  InRelease
Ign:1 file:/var/cuda-repo-8-0-local  InRelease
Get:2 file:/var/cuda-repo-8-0-local  Release [574 B]
Get:2 file:/var/cuda-repo-8-0-local  Release [574 B]
Get:6 file:/var/cuda-repo-8-0-local  Release.gpg [819 B]
Get:6 file:/var/cuda-repo-8-0-local  Release.gpg [819 B]
Get:7 file:/var/cuda-repo-8-0-local  Packages [9,568 B]
0% [Working]

It has been at this point for about 20 minutes, so it is safe to assume that the installation is frozen at some point. Is there a simple fix for this or should I boot the machine and see if everything else was installed?

Is it a problem that I have used Ubuntu 16.04 for flashing instead of the supported 14.04?


Is your host a native install (versus a VM)? VMs have a similar issue quite often. Also I’m assuming you are using wired networking…WiFi also has similar issues.

Correct, the host is a native install of Ubuntu 16.04.

The target (TX2) is connected via wired connection (through a network switch).

One thing I just noticed which is perhaps subtle…the package being unpacked is from the local repo: “/var/cuda-repo-8-0-local”. Networking might have been involved to start the command, but all data is already present on the eMMC. Networking already succeeded or else the local repo would not be there.

I’m not sure how to do it, but the log is referring to individual “.deb” packages on each line from “/var/cuda-repo-8-0-local/”. Unfortunately the log truncates, but if someone knows the order the “.deb” files are installed, then the file which is attempted right after the “Packages.gz” file is the one which stalls. I’m thinking perhaps you could just delete your JetPack and replace it with a new download if there is anything corrupted. Otherwise, someone who has a working install could say which package is used right after the Packages file and that particular package could be investigated.

I also just tried on Ubuntu 14.04 and it seems to run into the same problem.

I tried running dpkg --print-architecture and dpkg --print-foreign-architectures and have amd64 for the former and i386 for the latter.

Could it have something to do with the fact that I don’t have aarch64 available for dpkg? Or is this not a problem?

aarch64 is from the Jetson side. Having what you have on the host is normal and correct. The only reason you might have aarch64 on your host is if you have a cross-compile environment set up as a foreign architecture. I am assuming (perhaps this should be verified, but chances of being incorrect are tiny) that the actual package install being referred to is running on the Jetson and simply being observed by your software from the host.

It is a local CUDA install on the Jetson which is hanging. Knowing which package it hangs on would be immensely useful, but I’m not sure how to check that.

Hi eddieweill,

Is this still an issue on your machine?
Have you clarified where might be the cause?


It is currently still an issue. I am in the process of attempting the flash one more time.

I have attempted to flash using both Ubuntu 16.04 and 14.04, and both seem to run into the same issue. I then tried to flash a TX1 (with JetPack 2.3.1) and it seemed to work.

I don’t think it is a problem with my host machine since the TX1 was able to be flashed correctly; however, I will see if my final attempt at flashing the TX2 is successful.


After an unsuccessful flash with Ubuntu 16.04, I tried one final time with a machine with 14.04 and I still run into the same problem.

Why NVIDIA does not release binary package (e.g., cuda toolkit) for Jetson so as to install without host machine? It only make sense to involve host machine when we want to flash OS to jetson.

I think I have figured out the problem. It was not a problem with Jetpack at all. The IP address that was getting assigned to the TX2 was a local IP address and therefore was not able to communicate to the internet to download CUDA packages, etc.

Thanks for you help.