I am having problems installing the Jetson SDK Components onto my Xavier. I am using SDK Manager 0.9.14.4954, and had to manually download all the installation files as describe here: .mtd files corrupted, please help nvidia - Jetson Nano - NVIDIA Developer Forums
When I try to install the Target Components, only the NVIDIA Conatiner Runtime installs successfully. All other components fail.
I have exported the logs if you need them.
Hi wlevans,
Please help to provide log files for investigating.
Default path of logs are ~/.nvsdkm/logs/ and ~/.nvsdkm/sdkm.log
Thanks
Thanks kayccc,
I’ve zipped up the log files and will attached them.
logs.zip (517 KB)
My Xavier Rogue board is not installing the target components from the SDK Manager. If I try to run it while the board is plugged in and Ubuntu is logged in, I get the following terminal output:
17:00:57 DEBUG : running command < [ `lsusb | grep -c "0955:"` -ne 1 ] >
17:00:57 INFO : command finished successfully
17:00:57 DEBUG : running command < [ `lsusb | grep -c "0955:"` -gt 1 ] >
17:00:57 ERROR : command terminated with error
17:00:57 ERROR : Could not detect Nvidia Jetson device connected to USB. *To validate if the device is in connected correctly, run 'lsusb' command on your host, and look for "0955:7019" (NVIDIA Corp).
17:01:09 DEBUG : running command < [ `lsusb | grep -c "0955:"` -ne 1 ] >
17:01:09 INFO : command finished successfully
17:01:09 DEBUG : running command < [ `lsusb | grep -c "0955:"` -gt 1 ] >
17:01:09 ERROR : command terminated with error
17:01:09 ERROR : Could not detect Nvidia Jetson device connected to USB. *To validate if the device is in connected correctly, run 'lsusb' command on your host, and look for "0955:7019" (NVIDIA Corp).
There are no Nvidia devices visible if I run ‘lsusb’.
Is there anything I need to do to get the Xavier Rogue board visible over USB? Or is there another way to get CUDA onto the system? I have all of the .deb files that the SDK manager downloaded, but I’m not sure what to do with them.
I also don’t see a “L4T-README” folder if I plug my Xavier into my computer – is there anything I need to do to make sure that connection is active?
I also tried running /opt/nvidia/l4t-usb-device-mode/nv-l4t-usb-device-mode.sh as suggested from this post ([url]https://devtalk.nvidia.com/default/topic/1048749/jetson-tx2/sdk-manager-flashes-new-jetpack-4-2-correctly-but-then-cannot-install-sdk-components/post/5323228/#5323228[/url]
), and I got the result:
No known UDC device found
If I check /sys/class/udc, I don’t see anything in that folder. Is there anything I need to do to set those up?
Hi wlevans,
This should be fixed now. Please try downloading the SDKM and report back any issues.
Hi porch.amelia,
Please try with other USB cable to see if issue still the same.
kayccc,
I already have sdkmanager_0.9.14-4954_amd64.deb installed. Was it updated without changing the revision number?
I am still getting the same errors.
Any other solutions?
Hi wlevans,
Issue should be fixed, please try again.
Thanks
I’ve upgraded to the newest sdkmanager, but I am still getting the same errors.
Hi
I’m having the same kind of issue and I cannot seem to get this to work.
I’m running SDK manager 0.9.14.4964 and Ubuntu 18.04 on the host machine. Jetson is connected to a keyboard and a monitor.
I can flash the Jetson and everything seems ok until I try to install the SDK components on the Jetson.
After completing the Ubuntu systems configuration wizard and setting user name and password I can ping and log into the Jetson via ssh from the host machine on 192.168.55.1. I can also see the usb-ethernet enabled in the networks settings.
But, once I have entered the username and password in the SDK manager dialog and Clicked install, the dialog very quickly flashes an error: wrong username or password, after which it stops responding (I have tried several times and I’m sure the right user and pw is entered). I cannot go back or cancel. The dialog is up and seems to be trying to connect …
Any suggestions on what’s wrong ??
Thanks
@stenius: After the fail, does the ssh to 192.168.55.1 still work for login?
yes.
Since ssh works, let’s see what the network setup looks like on the host PC. Add the output from the host for these commands:
ifconfig
route
Also, from the host, let’s see if sudo to root changes things. Try logging in when your regular user is able to ssh to 192.168.55.1 via this instead:
sudo -s
ssh <whatever account name>@192.168.55.1
# ...do whatever, e.g., "ls"...
exit
exit
What this does is switch you to a root shell prior to ssh. The saved ssh information will consider this a new connection if root has never accessed that ssh address before and ask you to verify if you trust the connection. If this fails, then the saved credentials will need to be changed. I’m considering it possible networking is good, but SDKM running sudo at some stage could be using different credentials than the user you use for ssh. Each user has their own credentials and each user accessing the ssh needs to be tested separately.
Dear linuxdev thanks for your help!
Here are the output from the suggested actions.
ifconfig
enp0s25: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether d8:9d:67:99:fd:f4 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 17 memory 0xd4700000-d4720000
enp0s20u3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.55.100 netmask 255.255.255.0 broadcast 192.168.55.255
inet6 fe80::1d0:2636:7fdd:95dc prefixlen 64 scopeid 0x20
ether 56:68:fa:7e:59:11 txqueuelen 1000 (Ethernet)
RX packets 115 bytes 12394 (12.3 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 44 bytes 8986 (8.9 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp0s20u3i5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether 76:dd:69:89:ea:6a txqueuelen 1000 (Ethernet)
RX packets 110 bytes 12476 (12.4 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 266 bytes 21989 (21.9 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 266 bytes 21989 (21.9 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlo1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.214 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::f4b0:f5dc:5aa6:c5d2 prefixlen 64 scopeid 0x20
ether 84:3a:4b:3d:ba:6c txqueuelen 1000 (Ethernet)
RX packets 9403 bytes 12085841 (12.0 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4216 bytes 429617 (429.6 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default api.premiumzone 0.0.0.0 UG 600 0 0 wlo1
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 enp0s20u3
192.168.1.0 0.0.0.0 255.255.255.0 U 600 0 0 wlo1
192.168.55.0 0.0.0.0 255.255.255.0 U 100 0 0 enp0s20u3
sudo -s
… :~# ssh user@192.168.55.1
The authenticity of host ‘192.168.55.1 (192.168.55.1)’ can’t be established.
ECDSA key fingerprint is SHA256:Z3cC1bktw7eKn/QUygJt+ur2pB8UqQUqYCVJLZyqkm4.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘192.168.55.1’ (ECDSA) to the list of known hosts.
user@192.168.55.1’s password:
Welcome to Ubuntu 18.04.2 LTS (GNU/Linux 4.9.140-tegra aarch64)
This system has been minimized by removing packages and content that are
not required on a system that users do not log into.
To restore this content, you can run the ‘unminimize’ command.
0 packages can be updated.
0 updates are security updates.
Last login: Mon Oct 14 09:00:43 2019 from 192.168.55.100
To run a command as administrator (user “root”), use “sudo ”.
See “man sudo_root” for details.
user@192.168.55.1:~$ ls
Desktop Documents Downloads examples.desktop Music Pictures Public Templates Videos
user@192.168.55.1:~$ exit
logout
Connection to 192.168.55.1 closed.
root@… :~# exit
exit
… :~$
That content says the Jetson side is working, and communications between Jetson and host is working. What I see which is probably the issue is that it looks like the host PC does not have communications to the outside world. The host PC must be able to download a manifest and then files based on the manifest in order to put those onto the Jetson. Is the host PC able to “ping nvidia.com”? Is the host PC able to web browse nvidia.com?
Yes, I can both ping and web browse nvidia.com. I fact the last post with the content from the host was done from the host PC.
Other than the USB interface to the Jetson, only wlo1 has an address assigned. The regular wired network card is not a possible candidate for that traffic, and so I’m going to guess wlo1 is due to some sort of WiFi access.
Is there any kind of firewall or other software which might be blocking SDK Manager? Different ports might be used, but having ssh work and other issues still happen is quite odd.