failed to copy file to TX2 when flashing TX2

Hi Expert,
I met some network issue when flashing TX2 using jetpack 3.3. After jetpack finish flashing TX2 and continue to install cuda in TX2, i got below error message.

error message

Connection reset by 192.168.1.xx port 22
lost connection
Copying /home/tester/jetpack3.3/jetpack_download/cuda-repo-l4t-9-0-local_9.0.252-1_arm64.deb file to target…
Connection reset by 192.168.1.xx port 22
rsync: connection unexpectedly closed(0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.1] nvidia

  1. I’m sure TX2 and host PC are in the same network
  2. It’s strange that one interface in TX2 has two IP addresses

Any help would be appreciated. Thanks!

BTW, I remember there should be only one user “nvidia” after flashing TX2, but now there are both “nvidia” and “ubuntu” users, is this by design?

“ubuntu” is the standard Ubuntu login, “nvidia” is also standard on some of the earlier releases. You might find on newer releases that none of those accounts exist until after a first boot login setup (though JetPack3.3 always used both “ubuntu” and “nvidia” logins).

You might also find that the micro-B USB has a virtual ethernet device address, and JetPack/SDK Manager will try to use that (192.168.55.1 on the Jetson side, and 192.168.55.100 on the host connecting to the micro-B port of the Jetson).

On the Jetson and host, what are the outputs from commands “ifconfig” and “route”?

Btw, if you do have the “standard” Ubuntu login, and are on an unprotected network, then you should change the password of “ubuntu” and “nvidia” very quickly after flash.

Thanks. May I know what’s the purpose of virtual ethernet? Are they used to copy cuda-repo-XXX into target TX2? what’s relationship between virtual ethernet and TX2 in-hand network? I remembered in earlier jetson3.3, there is no virtual ethernet and data is transftered by micro-B USB line.

JetPack3.3 didn’t actually use the virtual ethernet, but one purpose early on was to demonstrate how to custom program a “USB gadget” to appear and make the OTG port behave as a device. The earliest example is using a micro-B USB cable routed to the host PC while running and making a “pretend” disk partition…the host PC will see the micro-B USB as providing an external USB hard drive, and this can be mounted and the README file on it read (not a lot else can be done with this since it is a read-only example).

Later on (JetPack/SDK Manager 4.x+) this was used as the wired ethernet for file copy after a flash as a replacement to having a second connection/cable beyond the USB. Basically the later releases added a DHCP server to this virtual ethernet which newer JetPack/SDK Manager release new about without effort (in theory). In all versions of flash software the system is flashed through the micro-B USB in recovery mode, and extra package additions do not occur until the flashed Jetson is fully booted after the flash (which means no longer in recovery mode). There was a one-time script which attempted to tell JetPack what the new IP address is on the regular wired ethernet, but this is not always easy to make work correctly (requiring the user to manually find the IP address of the Jetson and provide it to JetPack). Then packages are added over ssh/scp.

So far as the flash software is concerned, virtual wired ethernet is indistinguishable from regular wired ethernet, and since no external router is required, this should be easier to make work without dealing with routers and second cables (the micro-B USB is already plugged in for flash). JetPack3.3 does not copy over this unless you’ve provided the virtual ethernet address as the Jetson’s address. Note that the dedicated wired ethernet is faster, and probably your host PC already has correct access to the involved network; with the virtual ethernet you may need to tell your host it is ok to use this before the virtual address becomes active/visible.

There are cases in the newer releases where people have had problems getting their host PC to accept and activate the virtual ethernet, followed by workarounds to go back to the regular wired ethernet.