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...
cuda-repo-l4t-8-0-local_8.0.64-1_arm64.deb
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
nvidia:
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) ...
OK
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.
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.
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.
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.
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.