I am trying to install sdk components to the jetson tx2. I am using the SDKmanager tool. I first flashed the tx2 with jetpack 3.3 successfully. However, when it tries to install the sdk compoents such as the AI, cuda etc, the program asks for the ip address of the jetson along with the user name and password. I enter the information, but it still says that it was the incorrect login or password. I am able to ssh into the jetson with the same user name and password.
I don’t understand why the sdkManager seems to think its the wrong userName or password?
JetPack3.3 wasn’t actually under SDK Manager…it was at JetPack4.x SDKM came into play. You might be seeing a reference to the login at the NVIDIA server and not the login to the Jetson. On the other hand, make sure that you are using the correct login name (typically “nvidia”) on the Jetson, and make sure you can ssh to the Jetson with the same IP address which JetPack is using. Make sure you can ssh with your regular account on the PC which runs the software install, and also make sure you can “sudo ssh …” as well.
If you have a screenshot of the step prior to the fail (where it shows login credentials you are being asked about) it might help.
Thanks linuxdev. I got it working. SDK Manager has an option for previous jetpack versions including 3.3. Anyhow the problem was my host ethernet IP. I had to manually set it to 192.168.55.100 in order for it to be able to connect to the tx2 board.
If you run command “ifconfig”, then you should see if the USB port has that address. If not, then security probably just denied allowing a random USB network adapter to have access, and you’d simply tell it to allow it.
If you monitor “dmesg --follow”, and watch what shows up as you plug in the USB adapter, it will show you a MAC address. If you know the MAC address you can use either the basic system tools to tell it to allow that adapter, or you can use “nm-connection-editor” (with sudo) to enable this (you’d pick the adapter listed via the MAC address). If you don’t have nm-connection-editor, then “sudo apt-get install network-manager-gnome” (only needed if you don’t use the tools already installed…same story, activate the NIC via the MAC from whichever tool you use).
Thanks for the reply! My current issue is: I can ping and ssh to 192.168.55.1, but SDK manager says my username and password are incorrect. I tried a lot of times and it still doesn’t work… Any pointers?
In that case it would have nothing to do with networking. Was the end connection point (the Jetson) just flashed? If so, then it has no login name or pass until you complete the first boot setup. If it used to work, and suddenly stopped, then I might expect malware if the Jetson was exposed to the internet without changing default passwords (systems used to arrive with default name/pass until more recent releases, but that is now illegal in California and so first boot setup was put in rather than default name/pass).
It is a Jetson TX2, and it is NOT just flashed. I have been using the TX2 for a while with my username and password, and I am trying to install CUDA on it.
It’s my own username and password, so I don’t think it could be due to malware.
It keeps showing this error, and I am 100% sure the username and password is correct (I used them to ssh to 192.168.55.1) )
When logged in to the Jetson itself, does your password work for these? sudo ls sudo -s
If those work, then you have the correct password and the same password should work for ssh logins. From the host PC you would use "ssh 192.168.55.1 to reach the Jetson. The “192.168.55.100” is the PC itself, and if you were using ssh to the PC, then I could see the likelihood that your name/pass is different on the PC, and thus it would be refused. If you were already logged in to the Jetson, and wanting to ssh to the PC, then you would use “ssh 192.168.55.100” to reach the PC.
There are a number of possible ssh failures, but the failure of password is very specific, and implies ssh is both allowed and functioning, but the account name/pass are wrong.
Both sudo ls and sudo -s works, it uses the same password as I used to ssh amrl_user@192.168.55.1, which works well for ssh.
I was not using ssh to my host machine (also Ubuntu 18.04). It looks everything works just fine, expect the SDK manager fails to connect to the Jetson.
SDKM has multiple places where it authenticates with a password. The first is connecting to the NVIDIA servers…should be the same name/pass you use for the forums. The second is that during flash the Jetson must be in recovery mode with the micro-B USB cable connected, but this isn’t really authentication so much as it is detecting recovery mode. The third is that after flash completes the Jetson will reboot, and only after the first boot setup for name/pass is completed, then SDKM will install extra components (such as CUDA) via ssh. Newer releases also have apt methods for installing those optional components, but for trouble under SDKM, this would be simple ssh login.
Because of:
…we know that SDKM should also work well if we are speaking of the login from SDKM to a fully booted non-recovery mode Jetson. Assuming “ping 192.168.55.1” works from the host PC while this error is occurring, then I wonder if perhaps the error is really about SDKM not logging in to the NVIDIA servers.
FYI, if you have wired ethernet as well, and if for example your Jetson’s IP address to wired were something like “192.168.1.2”, then you could tell JetPack to also use “192.168.1.2” for the login. The address “192.168.55.1” just happens to be the default, but using the USB virtual NIC is not mandatory.
Can you elaborate on whether, during the time this problem occurs, if the host PC can ping 192.168.55.1, and if from the host PC command line you can successfully “ssh amrl_user@192.168.55.1”?
Yes, I can ping 192.168.55.1, and I can also ssh amrl_user@192.168.55.1, both these work just fine. Also, I have setup the Jetson to be 192.168.14.9 on the WiFi, I am able to ping 192.168.14.9 and ssh amrl_user@192.168.14.9, both these work just fine too. I was also able to log in to SDKM with my NVIDIA username and password
But, in the SDKM, in step 03, when “SDK Manager is about to install SDK components on your Jetson TX2”, I tried both 192.168.55.1 and 192.168.14.9, and username amrl_user and the correct password, it keeps connecting and fails after a while, and reconnects, fails, and so on.
WiFi is not recommended as it tends to drop in and out during some steps. So I’d stick with the 192.168.55.1 address.
Having the login work and then drop out is a different issue than refusing login. Basically it says ssh is valid, but some condition is getting in the way, e.g., perhaps it is a network failure, but if you log in manually with ssh during this step, and the manual ssh login does not also drop out, then I’d say it isn’t a network failure (at least not a total failure).
Is there anything unusual about your host PC? For example, is it a VM? VMs tend to have this issue, but most of the time only during flash, and more rarely during addition of extra software (which is the stage yours is failing at).
Ok, I will stick with 192.168.55.1 with the USB cable.
I meant I was able to login the SDK Manager software with my NVIDIA account, but not connect to the Jetson on Step 03 with my Jetson username and password. I believe SSH is valid, but the username and password are incorrect. I am attaching the Terminal output in the SDKM window:
2:34:47 INFO: Connection to 192.168.55.1 22 port [tcp/ssh] succeeded!
22:34:47 INFO: command finished successfully
22:34:47 INFO: Connection to the device via SSH is avaliable.
22:34:47 INFO: Start to check if right credentials…
22:34:47 DEBUG: running command < true >
22:34:47 INFO: command finished successfully
22:34:47 DEBUG: running command < ssh -F /dev/null -o PubkeyAuthentication=no -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o ConnectTimeout=5 amrl_user@192.168.55.1 echo hello >
22:34:47 INFO: Warning: Permanently added ‘192.168.55.1’ (ECDSA) to the list of known hosts.
22:36:47 INFO: Password:
22:36:47 INFO: Connection closed by 192.168.55.1 port 22
22:36:47 DEBUG: command terminated with error
22:36:47 ERROR: Incorrect username or password. Please try again.
22:36:53 INFO: All done!
Also, there is nothing unusually about my host machine. It’s a Dell XPS with Ubuntu 18.04 installed. I am not using a VM.
The trouble is that JetPack3.x is rather old and the SDKM instructions might not apply. If you can use a newer release, then I suggest that. Is there a reason you need the older release?
If this is JetPack3.x, then it is too old to use the “apt-get” mechanism. I am suspicious that if you use other methods, then this may come back to bite. However, JetPack downloads to the host PC prior to copying to the Jetson, and then using ssh to run the correct dpkg commands for installing the files. I am a bit rusty on the older JetPack3.x, but on 4.x the downloads go to: ~/Downloads/nvidia/sdkm_downloads/
SDKM is basically JetPack with some extra network and package functionality. I am guessing the directory name differs, but there would be some sort of “nvidia” or “Jetson” or “jetpack” directory with this content. You could run command “sudo updatedb”, which takes some time, and then run “locate -i jetpack_download” and it might show it. The “.deb” files can be copied to the Jetson (e.g., via scp or a thumb drive) and installed with “sudo dpkg -i packagName.deb”. Because the order of install matters, and it is difficult to figure that out manually, you could name multiple packages in a single command line. You would always install any “repo” file first, and then the basic CUDA file.
Almost forgot: The files going to the Jetson will have “arm64” in their name, not “amd64”. There are some “noarch” packages which work on either PC or Jetson.
You can also (after the previously mentioned “sudo updatedb”) look for “repository.json”. This file lists a base URL for downloading the “.deb” files, and you could use wget to download individual .deb’s. Then the same story, copy to Jetson, and use sudo dpkg -i .... to install on the Jetson.
Thanks linuxdev! It was actually me who posted the other link.
The reason why it did not work is because the target ssh password prompt is changed to "Password: " instead of the original "username@ip_address Password: ", so the SDKM got confused which password to input. I changed the password prompt on the target back to the default "username@ip_address Password: " and it started to work!
