JetPack 3.2 hangs on "Install on Target"


When trying to “Install on Target” from the JetPack installer, the installation hangs. The jetpack_debug.log shows:

ssh-add /home/host_username/.ssh/id_rsa 0<&-
scp -F /dev/null -o PubkeyAuthentication=no -o ConnectTimeout=30 -o StrictHostKeyChecking=no /home/host_username/.ssh/ ubuntu@<ipaddress>:/home/ubuntu/
ssh -F /dev/null -o PubkeyAuthentication=no -o ConnectTimeout=30 ubuntu@<ipaddress>

ssh Auto-login from host to target works. The .ssh/authorized_keys appears to be setup properly.

I’ve tried this on a dedicated Ubuntu 16.04 machine (not a VM).

Any idea how to fix this? Or is there a manual installation of target tools that I can follow? Is copying the *arm64.deb files from jetpack_download to the target and installing sufficient? In the end, I’m trying to find and use argus and tegra_multimedia_api on the jetson.

Automatic IP address setup only works after a flash, so watch the console in case it is asking for a password. Also be sure your host has package “ssh-askpass” installed (“sudo apt-get install ssh-askpass”). You might also try deleting any current JetPack folder and running it fresh. Be sure to uncheck flash if you are not flashing…then you will know for sure that you will be prompted for a password.

Copying the “.deb” files to the Jetson will work, but it can be frustrating if you don’t know the install order.

I checked that ssh-askpass was installed, and tried to install from a fresh version of JetPack. It still hangs on installing on the target.

I found that after installing the *.deb files I also had to apt install a bunch of packages by hand to get the multimedia api to compile (which is good enough for now).

cuda-cudart-9-0 (9.0.252-1)
cuda-cudart-dev-9-0 (9.0.252-1)
cuda-driver-dev-9-0 (9.0.252-1)
cuda-license-9-0 (9.0.252-1)
cuda-npp-9-0 (9.0.252-1)
cuda-npp-dev-9-0 (9.0.252-1)
gstreamer1.0-libav (1.8.3-1ubuntu0.2)
gstreamer1.0-plugins-bad-videoparsers (1.8.3-1ubuntu0.2)
libavfilter-ffmpeg5 (7:2.8.14-0ubuntu0.16.04.1)
libgstreamer-plugins-bad1.0-0 (1.8.3-1ubuntu0.2)
libgstreamer-plugins-base1.0-dev (1.8.3-1ubuntu0.2)
libgstreamer1.0-dev (1.8.3-1~ubuntu0.1)
libopencv-core2.4v5 (
libopencv-imgproc2.4v5 (
libvisionworks (
libvisionworks-dev (
libvisionworks-samples (
libvisionworks-sfm (0.90.3)
libvisionworks-sfm-dev (0.90.3)
libvisionworks-tracking (0.88.1)
libvisionworks-tracking-dev (0.88.1)
cuda-command-line-tools-9-0 (9.0.252-1)
cuda-core-9-0 (9.0.252-1)
cuda-cublas-9-0 (9.0.252-1)
cuda-cublas-dev-9-0 (9.0.252-1)
cuda-cufft-9-0 (9.0.252-1)
cuda-cufft-dev-9-0 (9.0.252-1)
cuda-curand-9-0 (9.0.252-1)
cuda-curand-dev-9-0 (9.0.252-1)
cuda-cusolver-9-0 (9.0.252-1)
cuda-cusolver-dev-9-0 (9.0.252-1)
cuda-cusparse-9-0 (9.0.252-1)
cuda-cusparse-dev-9-0 (9.0.252-1)
cuda-documentation-9-0 (9.0.252-1)
cuda-gdb-src-9-0 (9.0.252-1)
cuda-libraries-9-0 (9.0.252-1)
cuda-libraries-dev-9-0 (9.0.252-1)
cuda-minimal-build-9-0 (9.0.252-1)
cuda-misc-headers-9-0 (9.0.252-1)
cuda-nvgraph-9-0 (9.0.252-1)
cuda-nvgraph-dev-9-0 (9.0.252-1)
cuda-nvml-dev-9-0 (9.0.252-1)
cuda-nvrtc-9-0 (9.0.252-1)
cuda-nvrtc-dev-9-0 (9.0.252-1)
cuda-samples-9-0 (9.0.252-1)
cuda-toolkit-9-0 (9.0.252-1)
libnvinfer-dev (4.0.4-1+cuda9.0)
libnvinfer-samples (4.0.4-1+cuda9.0)
libnvinfer4 (4.0.4-1+cuda9.0)

I tend to have a lot of devel packages installed, so I do not see many of the dependency failures. On the other hand, I have seen this in the past where install can crash and burn when there is an unmet dependency needed for compile…yet it doesn’t tell you what dependency it is. Manually compiling individual examples is about the only way I know to check what is really missing.

is there a manual installation of target tools that I can follow?
it appears that you may benefit from utilizing
./ jetson-tx2 mmcblk0p1
reference: [page 6]

If you mean extra package installation after flash is complete, then you won’t find that information since it was intended only from JetPack (but I’m not sure if that’s what you are asking).

One trick is to save the logs from a JetPack install and install individual packages later on the next flash following the order in the log.

The other trick is that if you name a large number of packages at the same time (versus one at a time), then there will be some sorting by the package manager itself.