I have completed all steps for installing my new Jetson TX2, but I am consistently getting this error message (I re-tried the installation many times).
The error message says:
“Read from socket failed: Connection reset by peer”, and from there fails to install cuda on the target.
- The dev board is properly connected to my router and is able to return ping.
- However, when I try to ping from it, I get a permission denied message.
- Trying to SSH to it from a remote computer, also fails.
This is very frustrating, as I really need start working and I am currently stcuk.
You can also run ssh with the “-v” option to get verbose notes of what ssh is doing and what might have failed. Beware that ssh routinely looks for all kinds of features which will fail simply because you are not using that feature, so this is expected…there would tend to be some “smoking gun” evidence though, e.g., saying that keys have changed.
Thanks for the help. The solution above is probably not related to my problem since my ssh key list is not empty and not zero sized.
BTW1: when I try to issue sudo commands I get:
“/usr/bin/sudo/ must be owned by uid 0 and have the setuid bit set”, which is weird to me.
BTW2: It seems that I have two users on the Jetson: “Nvidia” and “Ubuntu”, where “Nvidia” seems to be the default account.
When I issue ssh -v, I get the following:
erez@erez-H270-HD3:/media/downloads$ ssh -v 192.168.14.115
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.14.115 [192.168.14.115] port 22.
debug1: Connection established.
debug1: identity file /home/erez/.ssh/id_rsa type 1
debug1: identity file /home/erez/.ssh/id_rsa-cert type -1
debug1: identity file /home/erez/.ssh/id_dsa type -1
debug1: identity file /home/erez/.ssh/id_dsa-cert type -1
debug1: identity file /home/erez/.ssh/id_ecdsa type -1
debug1: identity file /home/erez/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/erez/.ssh/id_ed25519 type -1
debug1: identity file /home/erez/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu1
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu1 pat OpenSSH* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer
Any other ideas?
Here is a screenshot of the first time I encounter an error during the installation:
The flash or install was incorrect:
"/usr/bin/sudo/ must be owned by uid 0 and have the setuid bit set", which is weird to me.
File system permissions must be preserved exactly from the sample rootfs and from the apply_binaries.sh step (if JetPack is used it asks for password and does this; if command line flash is done, then sudo must be used at the right times). Note that there is no possibility of permissions being correctly preserved if the file system type on your Linux host is not a native Linux file system, e.g., NTFS or VFAT are Windows file systems and have no capability of understanding Linux permissions.
Without permissions being correct many file operations will be banned by the system.
If you are on your host in the location of your JetPack or flash driver software and run this command it will tell you how much disk space you have and the file system type (ext4 is the goal):
df -H -T .
NOTE: This is a problem which is not easily fixed. Re-flashing is the way to deal with it.
My host is a Ubuntu 14.04. I use JetPack, but I don’t recall a step where I am prompted to insert password during the installation with JetPack. What am I missing here?
Thanks a lot,
Is your Ubuntu running on a native file system type? Use “df -H -T” and check for the partition which holds JetPack (or cd to where JetPack unpacked and then run “df -H -T .”).
If you have some sort of permission issue there are many ways this can happen. One might be if you ran JetPack sudo then something may have unpacked with root ownership which your regular user couldn’t change…and then later running as the regular user would not work correctly. You may want to complete remove your JetPack directory, then start it over as your regular user. Your password should be prompted for at some point. Other than similar sudo-timing-of-use issues a non-Linux underlying file system would be about the only other way this could have happened.