Jetpack hangs after flash [SOLVED]

I’m having some trouble installing the Jetpack on my new TX1. The first half of the installation goes fine, I’ve successfully flashed my Jetson, but the installation hangs when it tries to ssh into the TX1. I’m certain I have the right IP, and I confirmed this by using the terminal to SSH, but I don’t know how to proceed from here. Can anyone offer some tips on how to repair the installation, or how to copy and compile the sample files manually?

I figured it out. I feel kinda silly actually. The micro usb cable needs to be connected the entire time during the process. I had been removing it after flashing, thinking that everything would be done through SSH, but no the cable needs to stay in. So I reinstalled Ubuntu on the host and redid the whole process and it works. Thanks for the replies everyone.

Alex
This worked for me.

Run Jetpack again

Select “Custom” mode

Disable all the steps up to and including the flash of the TX1

Make sure you have the IP address and go with that.

I’m not sure why this happens but I suspect it has something to do with the USB port resetting after the flash.

Kevin

I’ve tried doing just that, enabling only the post-install steps. It still hangs after I type in the ip and login for the TX1.

Are you able to ssh manually both without and with sudo? Root and non-root may use different keys.

Hi all,

I appear to be having the same problem as Alex. I have a new tx1 and I’m running JetPack on Ubuntu 14.04. I am also able to flash the jetson and then the install hangs. I have also tried just the post-install steps without flashing and it hangs. It first copies over cuda-repo-*.deb and then hangs. From the host I am able to manually log into the jetson with ssh both with and without sudo. Is the cuda install script somewhere obvious that I can try to manually run the commands from the script to see what is happening?

Thanks,

Geoff

I am, and now that you mention it, I saw two keys when I looked at my known_hosts file. Are you supposed to get status text in the terminal you run the launcher from? All I see is “Decompressing Jetpack” or whatever it says and that’s it.

I do not have an Ubuntu host (I use Fedora, but even that has fried hardware at the moment and doesn’t work), so I can’t answer by direct test. However, any application which uses ssh and requires certain amounts of “feedback” for question/answer information has to be intentionally set up with the askpass option (described in the man page of ssh), else the feedback text is simply lost and no interaction occurs (the same as failure if a confirm or pass was required).

There must be a known_hosts entry for each user account and address of an ssh originator, and so using sudo tends to mean you are using root’s information to the remote connection, not ubuntu’s…but of course Ubuntu complicates this because there is no direct root account unless you unlock it (if unlocked the entry goes into /root/.ssh/known_hosts, but there is normally no /root). I suspect this results in two keys in the /home/ubuntu/known_hosts (one for not sudo, one for sudo), but I can’t confirm this. Any difference over time of any of these entries blocks ssh as a possible man-in-the-middle attack (including if a new flash install results in regenerating a key…the originator doesn’t know the key was legitimately regenerated).

I think I found a workaround. After the script finishes flashing the OS it was trying to make the directory /.ssh rather then ~/.ssh. So I added the folder /.ssh and made my user the owner of the directory. It now appears that it is installing everything else.

Typically the directory would be created via expanding environment variables:

mkdir "${HOME}/.ssh"

If sudo mixed it up, $HOME may not have had any value…or somewhere in the script $HOME was not correctly inherited.

Looks like JetPack wasn’t able to setup passwordless ssh connection. Because when everything works well, IP address/username/password only needs be provided once. Can you please check if the following files have write permission on your HOST machine?
~/.ssh/id_rsa
~/.ssh/known_hosts

Also ~/.ssh/id_rsa.pub file needs read permission.

If the above files have good read/write permission and you are still facing the same problem, can you please run following command in terminal and let me know the results?

<JetPack_dir>/_installer/PageAction jetpack_device_info set_info <Jetson_IP_address> ubuntu ubuntu

Please replace <Jetson_IP_address> with actual jetson device IP.

Hi,

same problem with getting stuck on TX1. I got around the login issue by setting up ssh without password manually

ssh-keygen
ssh-copy-id ubuntu@<Jetson_IP_address>

@EdwardZhou
Your command “./PageAction jetpack_device_info set_info <Jetson_IP_address> ubuntu ubuntu”
gave me this (after above ssh-setup and USB-cable plugged in):
2018/06/26 16:01:56 dialing:dial tcp 127.0.0.1:33335: getsockopt: connection refused

During installation I saw some error flags flashing by, but could not see which module

After compiling the test examples, i tried the oceanFFT

ubuntu@tegra-ubuntu:~/NVIDIA_CUDA-8.0_Samples/bin/aarch64/linux/release$ ./oceanFFT
NOTE: The CUDA Samples are not meant for performance measurements. Results may vary when GPU Boost is enabled.

[CUDA FFT Ocean Simulation]

Left mouse button - rotate
Middle mouse button - pan
Right mouse button - zoom
‘w’ key - toggle wireframe
[CUDA FFT Ocean Simulation]
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 155 (GLX)
Minor opcode of failed request: 24 (X_GLXCreateNewContext)
Value in failed request: 0x0
Serial number of failed request: 29
Current serial number in output stream: 30

As I have rerun the installer many times and i, will redo it from scratch with the latest version

Well, or i could have connected the monitor directly to the card and not “ssh -X”. That solved the issue