Jetpack 3.2 and 3.1 Post-Installation stuck

Autonomous Machines Jetson & Embedded Systems Jetson TX2
#1

Hi there :) I’m absolutely new to the whole Jetson world and am currently trying to install all the software on my Jetson TX2 through JetPack (not new to Linux though, not afraid of the terminal).

My host runs Ubuntu Gnome (16.04) and Host as well as Target are accessing the Internet through a switch which forwards them to the router. Flashing the OS works fine and the OS runs perfectly on the TX2 so that was a small success for me, but after that I had troubles getting the Post-Install to run. After restarting the Installer with only the Post-Install stuff selected, I was able to finally run it and was getting the first lines of output that everything worked fine. (SSH is set up correctly, I’ve tried to connect manually and that worked).

But now I’m facing the same problem with 3.1 as with 3.2, that I get the output below, but after that the installer seems to be stuck, I’ve let it run for about 30 mins by now and nothing happened.

What I did not put into the code, was XTerm asking me for my id_rsa password. I guess this could have speeded up solving the problem. See answer for details. 
nvidia@192.168.178.39's password:
Copying /home/user_name/Documents/JetPack/jetpack_download/cuda-repo-l4t-9-0-local_9.0.252-1_arm64.deb file to target...
nvidia@192.168.178.39's password:
cuda-repo-l4t-9-0-local_9.0.252-1_arm64.deb
        602,560,414   100%    66.55MB/s  0:00:08   (xfr#1, to-chk=0/1)
sent 602,707,635 bytes    received 35 bytes   52,409,362.62bytes/sec
total size in 602,560,414  speedup is 1.00

Also

df -H /usr

shows that there is around 93% of disk space remaining.

Thanks already for any help you provide! I’m sure this is easily fixable and I’m simply overlooking something.

#2

Hi muellertimomueller,

Please check your system requirements and follow the install guide:
http://docs.nvidia.com/jetpack-l4t/index.html#developertools/mobile/jetpack/l4t/3.2/jetpack_l4t_install.htm

#3

Hi carolyuu,

System Requirements are fine, (I’m assuming Ubuntu Gnome counts as Ubuntu ??) and I’ve followed the installation, doesn’t change anything :)

#4

I’ve tried it with a Ubuntu 14.04 Live USB, but that didn’t work at all. Failed (Errorcode 1) because it couldn’t install packages, which should be installable…

#5

Were you asked for a password? If not, then perhaps your host needs package “ssh-askpass”…if you do need this, then it might sit there stalled (or perhaps show an error…not sure).

#6

Using Gnome (16.04) I was asked for the password when connecting via SSH yes. Using the Live USB I didn’t even get to that point so that’s a no.

Is using Gnome fine ? Since it’s still basically Ubuntu I assumed so …

#7

Live USB is not capable of succeeding if it doesn’t use a native Linux file system. Usually the live distributions don’t use the normal ext4, so these will fail in odd ways. Gnome, KDE, command line…none of that matters.

#8

Mhh ok :) So this is not an issue with the host itself or the SSH connection then ? What other parts could go wrong ? :/

Edit: Also -> The installation of ssh-askpass did not fix the problem

#9

It seems as if I have found a fix. For my work I had an ssh key (id_rsa) and the JetPack Installer would always ask for the password of this one. Looking around on the internet, I found out that when JetPack enters the XTerm Window there shouldn’t be any passwort requests anymore, so I was wondering why that happened and if it had anything to do with my problem.

Creating a new id_rsa file (I guess simply removing it or renaming would also work) fixed the “password asking” problem. And it seems as if that also fixed the “being stuck” problem.

Right now, JetPack is installing all the modules and other post-installation stuff.
I hope this helps anyone searching for an answer on this problem.

(Also I’ve been using JetPack 3.2 for this install now)

#10

Something to be aware of with ssh is that if you have connected previously, then it marks the ID of the ssh on the remote machine, e.g., for “name@some_address”. When you flash a Jetson it deletes the original ssh keys of that machine and may generate new keys…your host could end up refusing to connect to this changed system since it appears as a “man in the middle” attach unless you ok this. If you don’t have a mechanism to ok this, then it won’t work. You’d have to remove the bad/old key.

FYI, I put my old “/etc/ssh/” and other ssh keys in my sample rootfs directory (I overwrite the sample) before generating a new image.