I have a problem while updating to Jetpack 3.2.1
The flash of the TX2 worked without problem, but afterwards the installation of the packages (cuda /tensorrt/opencv etc) doe not work.
Thats happening:
I start jetpack again and choose install only packages.
It ask me for the ip and the user + pw (10.42.0.51 - nvidia nvida)
But when I continue, a new terminal opens and ask me for the pw again!
If I type again nvidia into the terminal, it tells me it wants to copy cuda-repo…
Then it asks again for the nvidia pw twice.
When I type in the password twice again, it will start to copy the file.
After coping, nothing happens anymore.
I can connect via ssh to the board, so the connection is no problem.
The file is copied I can find it on the board.
But somehow the script does not get the information and is stuck.
Got anybody an idea how to fix this?
Can I install the packages by myself on the tx2?
Can someone point out the name of the script that is executed by the installer? Maybe I can do the execution from the host by myself?
I got the installer to continue a bit:
I created a ssh key to login on the tx2. Now the installer doesnt has to use the password anymore and continues after the copy.
But the installation doesnt succeed, because apt-get on the tx2 cannot authenticate the cuda-* packages.
I fixed it by adding --alow-unauthenticated to the script and executed by myself on the tx2.
Afterwards, the other packages seem to install as expected (still running).
But I am still worried about the cuda packages - why are they not authenticated?
My problem is twofold, so there are two things you could discuss with the responsible programmer:
How can the installation of the ssh key fail? Could the installation script check for this and report accordingly?
In which case reports apt-get the “cannot authenticated”-error? Even though the script installs the corresponding key first, which seems to be successful.
Hard for me to provide more details, because after finishing successful (after my changes) the script deleted all install routines on my board.
I will try with the second board tomorrow, maybe I can provide more details then.
Any time the host keys or destination keys change from a previous session ssh might reject a connection as a “man in the middle” attack. When you flash you erase things and reinstall. If the original “~/.ssh/” is preserved on the Jetson, and the “/etc/ssh/” content is preserved on the Jetson, then your host won’t reject it. Same in reverse for the Jetson…if either end rejects, then it is rejected.
If the permissions of any ssh file intended to be readable only by the user allows too much to be read by others, then these are rejected. A simple copy of keys without preserving correct permissions would be an example of this.
I’m not sure what keys or methods are used to preserve from prior install for JetPack, but it seems to be aware of this.
If your host PC ran out of space during a flash it may have truncated the Jetson’s rootfs image. You wouldn’t know this until you check remaining disk space on the host after a flash or do some detailed examinations.
If you manually flashed and did not correctly unpack the sample rootfs with sudo, or if you ran apply_binaries.sh without sudo, then some critical permissions would be incorrect. The one which comes to mind is that the Jetson’s “/usr/bin/sudo” command would not be set correctly and everything sudo would fail (sudo is rejected if it isn’t set with correct permissions).
You should see what happens if you try to manually ssh to “nvidia@” from the host.
My host has around 100GB free space, so I think space was not the issue.
Could the way of connection create this confusion for the ssh key?
I connected the Jetson to the Host via USB for flashing, but the installation afterwards needs a network connection. I used WLAN for this, so maybe the ssh is somehow only for the eth0 connection?
But if this is the case, I wonder why? After installing a ssh key manual on Host and Jetson, connection via WLAN work fine and (as explained before) installation could continue.
I used for flashing and the installation afterwards:
You should see what happens if you try to manually ssh to "nvidia@<whatever the IP is of the Jetson>" from the host
I did this before installing my own ssh key: It wanted the password and worked fine otherwise.
After installing keys, it worked without password, as expected.
@linuxdev Do you have an idea what the reason for the “cannot authenticated”-error can be?
When the Jetson sees an incoming ssh connection it looks at the IP address and various fingerprints of the host. If the IP address is different, then you might find the connection rejected (if it is a first time connect it’ll ask if you trust the connection and want to allow it). WiFi for package install isn’t supported, so there isn’t much of a list of all of the reasons it might fail…but ssh seeing the WiFi as a different address from something previously is indeed a possible cause. Manually testing ssh connect is one way to verify (make sure your command line testing uses the same IP which JetPack uses…if you have both wired and WiFi they might differ).
Also note that all of the network address setup which occurs during a flash assumes wired. Wired is simple, it only needs DHCP and no manual intervention…WiFi takes more setup and makes manual intervention necessary so JetPack doesn’t use WiFi unless you’ve manually rigged something in WiFi setup.
Note that if you don’t mind the Jetson freshly asking again if you want to allow a connection (by forgetting all previous knowledge of all known hosts) you can delete the “~/.ssh/known_hosts” file. There are more official ways to delete individual entries in that file, but if you aren’t doing anything special you can just delete a line which starts with the host name you want to forget about (the entries are individual single lines identifying one incoming account/host fingerprint…but they are very long lines which line wrap…each line is an independent memorization of a known host).
I can’t say for sure about the “not authenticated”, but it is a possibility this is a change in known hosts issue. Make sure manual command line ssh works. Anything related to WiFi must be done manually and has no guarantee since it isn’t supported (it might work if you take the steps needed). This might include dealing with a change in keys, or it might not matter (I have not specifically tested since I avoid WiFi).