Unable to install SDK components post flashing my Jetson TX2 module

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX2
21

Thank you for a very thorough reply. I can confirm no VM is involved. I have tried to install nvidia docker on this host, but it is currently not working due to mismatch between graphics card and versions of nvidia-docker runtime and drivers. I have little experience with Docker, but to my knowledge it should not be running.

What I find most baffling about this is that I can manually ssh from the host to Jetson. Is it not the same thing the SDK manager does?

On the host:
$ ping 192.168.55.100
PING 192.168.55.100 (192.168.55.100) 56(84) bytes of data.
64 bytes from 192.168.55.100: icmp_seq=1 ttl=64 time=0.064 ms
64 bytes from 192.168.55.100: icmp_seq=2 ttl=64 time=0.059 ms
64 bytes from 192.168.55.100: icmp_seq=3 ttl=64 time=0.063 ms
64 bytes from 192.168.55.100: icmp_seq=4 ttl=64 time=0.034 ms
64 bytes from 192.168.55.100: icmp_seq=5 ttl=64 time=0.062 ms
64 bytes from 192.168.55.100: icmp_seq=6 ttl=64 time=0.061 ms
^C
ā€” 192.168.55.100 ping statistics ā€”
6 packets transmitted, 6 received, 0% packet loss, time 5115ms
rtt min/avg/max/mdev = 0.034/0.057/0.064/0.011 ms
olav@olav-Ubuntu:~$ ping 192.168.55.1
PING 192.168.55.1 (192.168.55.1) 56(84) bytes of data.
64 bytes from 192.168.55.1: icmp_seq=1 ttl=64 time=1.32 ms
64 bytes from 192.168.55.1: icmp_seq=2 ttl=64 time=0.856 ms
64 bytes from 192.168.55.1: icmp_seq=3 ttl=64 time=1.21 ms
64 bytes from 192.168.55.1: icmp_seq=4 ttl=64 time=1.23 ms
64 bytes from 192.168.55.1: icmp_seq=5 ttl=64 time=0.990 ms
64 bytes from 192.168.55.1: icmp_seq=6 ttl=64 time=1.22 ms
^C
ā€” 192.168.55.1 ping statistics ā€”
6 packets transmitted, 6 received, 0% packet loss, time 5031ms
rtt min/avg/max/mdev = 0.856/1.139/1.321/0.166 ms

22

On Jetson
ping 192.168.55.1
PING 192.168.55.1 (192.168.55.1) 56(84) bytes of data.
64 bytes from 192.168.55.1: icmp_seq=1 ttl=64 time=0.084 ms
64 bytes from 192.168.55.1: icmp_seq=2 ttl=64 time=0.690 ms
64 bytes from 192.168.55.1: icmp_seq=3 ttl=64 time=0.130 ms
64 bytes from 192.168.55.1: icmp_seq=4 ttl=64 time=0.456 ms
64 bytes from 192.168.55.1: icmp_seq=5 ttl=64 time=0.890 ms
^C
ā€” 192.168.55.1 ping statistics ā€”
5 packets transmitted, 5 received, 0% packet loss, time 4038ms
rtt min/avg/max/mdev = 0.084/0.450/0.890/0.312 ms

ping 192.168.55.100
PING 192.168.55.100 (192.168.55.100) 56(84) bytes of data.
64 bytes from 192.168.55.100: icmp_seq=1 ttl=64 time=0.325 ms
64 bytes from 192.168.55.100: icmp_seq=2 ttl=64 time=1.04 ms
64 bytes from 192.168.55.100: icmp_seq=3 ttl=64 time=0.713 ms
64 bytes from 192.168.55.100: icmp_seq=4 ttl=64 time=0.553 ms
64 bytes from 192.168.55.100: icmp_seq=5 ttl=64 time=0.509 ms
64 bytes from 192.168.55.100: icmp_seq=6 ttl=64 time=0.529 ms
^C
ā€” 192.168.55.100 ping statistics ā€”
6 packets transmitted, 6 received, 0% packet loss, time 5034ms
rtt min/avg/max/mdev = 0.325/0.612/1.046/0.225 ms

23

Network is 100% correct so far as the virtual USB ethernet goes. This is the connection SDKM should be using to perform package additions. If you can manually ssh in to 192.168.55.1 prior to running SDKM, and if SDKM uses the same login credentials, then SDKM should be succeeding.

You noted this earlier, which is ssh, but it is to the wired ethernet:

"ssh: connect to host 192.168.1.77 port 22: Connection refused"

192.168.1.77 is a different subnet (versus virtual wired ethernet over USB), and thus also a different route. However, this should make no difference to SDKM (SDKM is using the virtual wired ethernet and you already know you can login from the host to that with ssh). If we ignore SDKM for a moment, and just want to see about the ssh failure to this port, then weā€™d have to verify first that the network has a route, and second that ssh itself is not refusing connection.

In terms of route verification, if you are on your host, can you ā€œping 192.168.1.77ā€? Iā€™m guessing you can, and the reason is that the address would have never been assigned to the Jetson unless the DHCP from the router worked. Your host interface ā€œeno1ā€ is on the same subnet, and there is no overlapping route so this interface would be abel to talk to the 192.168.1.77 address unless there is a firewall issue.

Regarding this error, can I confirm this was from you manually trying to ssh to the TX2 and is not from the SDKM/JetPack?

"ssh: connect to host 192.168.1.77 port 22: Connection refused"

If you can ping ā€œ192.168.1.77ā€ from the host PC, then you might add a log of the following (if you highlight with the ā€œcode blockā€ icon in the upper rightā€¦looks like the ā€œ</>ā€ā€¦then itā€™ll add scrollbars and preserve formatting and wonā€™t truncate as soon):

ssh -vvv <i>name</i>@192.168.1.77

(substitute ā€œnameā€ for whatever the account name is)

24

I believe infowx9tw had the 192.168.1.77 adress. I have disconnected the wired ethernet from the TX2 so the only physical route to it is through the USB. I cannot ping nor ssh 192.168.1.77. I can connect the ethernet cable to the TX2 and see if I get a connection then. Would that be useful?

25

You should be able to enter any address where you can ssh in. You might have to manually name a working address if it picks another. In theory you can use either the 192.168.1.77 or the 192.168.55.1 if they both allow ssh.

Can you ping 192.168.1.77 with wired connected? Iā€™m still trying to find out which parts will talk to each other (beyond wired virtual USB ethernet). Historically the TX2 package install stage has been via the wired ethernet (for you 192.168.1.77), but later releases (specifically the JetPack/SDKM4.2 you are using) started using the USB virtual ethernet (192.168.55.1) as a substitute so both flash and package addition could be done over the same USB cable without extra networking. Disconnecting the wired would only help if virtual ethernet over USB had been failing due to route issues, but there is no such issue (as proven by your ability to ssh to that address). Knowing why the 192.168.1.77 fails might offer clues to network and firewall setup. So connecting the wired ethernet would indeed be a useful test. Some files can be edited as well, and if the regular wired works but virtual does not, then you could switch to that wired actual ethernet (and avoid virtual USB ethernet).

Can you ping 192.168.1.77? Can you ssh to the same account (login name) you used ssh to for 192.168.55.1 and reach 192.168.1.77?

26

When I connect the ethernet cable to the TX2 it gets IP 192.168.1.102. I can both ping and ssh to 192.168.1.102. It fails both ping and ssh to 192.168.1.77 it does not exist in my network.

27

Yes, DHCP can reassign the address if the lease expires. So just substitute and use 192.168.1.102 in place of 192.168.1.77. Having the address change would be a good reason for the network not working :P

However, now you need to try the SDK components. Does default install of components now work? If not, then take a look at file ā€œ~/.nvsdkm/sdkml3_jetpack_l4t_42.jsonā€. Save a backup, then search for and replace all occurrences of ā€œ192.168.55.1ā€ with the actual address of the wired ethernet (if it doesnā€™t change, then itā€™ll be ā€œ192.168.1.102ā€).

28

I changed the IP address in the SDKmanager and went through the file and changed any remaining places. The result is the same. The SDK manager comes back with incorrect username or password.

29

Iā€™m wondering if maybe this is just a bad error message and it says the same thing no matter the cause of an ssh failure is. Since you can ssh manually it should be working, Iā€™m a bit perplexed. Can we verify that after the address change you can still manually ssh to that account at either 192.168.55.1 or the other 192.168.1.x address?

What Iā€™m going to suggest is that you do a full flash with monitor and keyboard attached to the TX2. Do a clean removal of everything in the host sideā€™s ā€œ~/nvidia/ā€ directory and the ā€œ~/.nvsdkm/ā€ directory to start fresh. Put the TX2 in recovery mode, connect the cable, and then run SDKM. Simply tell JetPack/SDKM to flash and not install any packages (purposely make extra package install a new step). When flash completes and youā€™ve added the account/pass, run ifconfig and donā€™t reboot the TX2. See if your host can ping both the 192.168.55.1 address and whatever the other 192.168.1.x address turns out to be. Then confirm you can log in with ssh to that account on either/both of those addresses. If you can, then without the TX2 rebooting, restart SDKM and tell it you want to install components to the TX2, and to not flash, nor install to host. See if this still happens.

If ping does not work this needs to be fixed first (and is probably a router issue). If ssh fails, then it might just be your host keys not being set up after the TX2 changes. If you can ssh in, then on that ssh session monitor ā€œdmesg --followā€ during the attempt to install the extra packages. Use a second ssh login and monitor ā€œsudo tail -f /var/log/auth.logā€ prior to starting the package install. Any ssh failure attempt should be logged from the TX2 side. If we are just seeing a bad message, then this should provide information on whatā€™s really going on. Weā€™ll know if a login attempt actually reached the TX2, or if the failure was a lack of route.

2 Likes
30

I can confirm I can still ssh both to the 192.168.55.1 and 192.168.55.1 address.

I have been thinking if I should deinstall / reinstall the SKM. Do you think there is any point in that?

31

I did follow your instructions. (Did not reinstall the SKM) It was a big success. The SDK got install without any problem. Thenk you very much for your help.

32

Glad it worked. Sometimes something in the download holds back progress, and so the recommendation to remove some of the previous SDKM content. As long as there was no download issue it wouldnā€™t matterā€¦and with trial by fire, it worked.

33

For my problem is I can ping to Jetson TX2 from host ubuntu 18.04 as ping 192.168.55.1
but I cannot ssh from host to Jetson TX2 as
ssh 192.168.55.1, result is connection refused.
so how can I do?

34

That is quite odd. Connection refused implies that the network could reach the host, but the host is not running the ssh daemon. By default the daemon should always run. Had the host PC been blocking the route via a firewall, then I would expect ā€œno route to hostā€ instead of ā€œconnection refusedā€.

If you are locally logged in to the Jetson, and if your login account name is ā€œubuntuā€ (adjust for your actual login name), then can you succeed with this:
ssh ubuntu@localhost
(if connection refused, then the ssh daemon is not running; if you can log in via that, then there is probably a network issue, e.g., using the wrong IP address and actually reaching a different computer)

35

should I must be stop firewall all PCs?
Noted: my Jetson cannot boot os but can go to recovery mode

36

Firewalls only matter if they stop ssh. A typical PC with Ubuntu would allow someone on the PC to attempt an outbound ssh connection, and only prevent the reverse direction. Possibly that could help to disable the firewall, but mostly not unless it is preventing traffic to the Jetson. As mentioned though, the message indicates no firewall issue was in the way and that instead the system your ssh contacted was not running ssh as a daemon (incoming service). It is unlikely any firewall change would matter.

Recovery mode cannot be used for installing applications. This is only for flashing. The system must be fully booted for ssh to work, but many people mistakenly believe lack of a GUI is the same as ā€œnot runningā€. If you are stuck in the NVIDIA logo, then the system is not booted, but you should still try to ping the Jetsonā€™s address even if you donā€™t have videoā€¦it might be that the only issue is a missing correct video configuration, and this wonā€™t harm ssh access.

Barring ssh access, then I would suggest serial console access. A boot log from serial console can provide a lot of information you canā€™t get when logged in under Linux. See:
http://www.jetsonhacks.com/2015/12/01/serial-console-nvidia-jetson-tx1/

Right now the question Iā€™m particularly interested in is whether or not the IP address is actually that of the Jetson, or if it is to something else? If the system is booted, and then connection through the micro-B USB cable results in address 192.168.55.100 for the host PC and 192.168.55.1 for the Jetson, it implies the Jetson fully booted.

If you monitor ā€œdmesg --followā€ on the host PC, give the Jetson a couple of minutes to boot, and then connect the micro-B USB cable, what logs show up? There are a number of things which, if they show up, implies boot worked. If not, then it implies boot failed, and then we are back to the serial console boot log (I really want to emphasize that just because you donā€™t see a GUI display it does not mean the Jetson did not boot).

37

| linuxdev Top Contributor
January 30 |

  • | - |

Firewalls only matter if they stop ssh. A typical PC with Ubuntu would allow someone on the PC to attempt an outbound ssh connection, and only prevent the reverse direction. Possibly that could help to disable the firewall, but mostly not unless it is preventing traffic to the Jetson. As mentioned though, the message indicates no firewall issue was in the way and that instead the system your ssh contacted was not running ssh as a daemon (incoming service). It is unlikely any firewall change would matter.

Recovery mode cannot be used for installing applications. This is only for flashing. The system must be fully booted for ssh to work, but many people mistakenly believe lack of a GUI is the same as ā€œnot runningā€. If you are stuck in the NVIDIA logo, then the system is not booted, but you should still try to ping the Jetsonā€™s address even if you donā€™t have videoā€¦it might be that the only issue is a missing correct video configuration, and this wonā€™t harm ssh access.

Barring ssh access, then I would suggest serial console access. A boot log from serial console can provide a lot of information you canā€™t get when logged in under Linux. See:
http://www.jetsonhacks.com/2015/12/01/serial-console-nvidia-jetson-tx1/

Right now the question Iā€™m particularly interested in is whether or not the IP address is actually that of the Jetson, or if it is to something else? If the system is booted, and then connection through the micro-B USB cable results in address 192.168.55.100 for the host PC and 192.168.55.1 for the Jetson, it implies the Jetson fully booted.

If you monitor ā€œdmesg --followā€ on the host PC, give the Jetson a couple of minutes to boot, and then connect the micro-B USB cable, what logs show up? There are a number of things which, if they show up, implies boot worked. If not, then it implies boot failed, and then we are back to the serial console boot log (I really want to emphasize that just because you donā€™t see a GUI display it does not mean the Jetson did not boot).

Visit Topic or reply to this email to respond.

To unsubscribe from these emails, click here.

Here my problem on jetson tx2

IMG20210130013444.jpg
IMG20210130013444.jpg4000Ɨ3000 3.92 MB

38

I couldnā€™t say for sure if those messages mean anything. Certainly the urandom content can be ignored, and in some cases regulator warnings can be ignoredā€¦but I donā€™t know if those regulator warnings are for required hardware or if they are for optional hardware which is not present.

Does boot go no further, and thus stop login? If you can log in, what do you see from ā€œcat /proc/cmdlineā€? Also, what do you see from ā€œifconfigā€ and ā€œrouteā€?

39

It is stop login , it stuck at the warning screen.

40

It is the problem that I cannot login to jetson board check anything.