TX2 Jetpack 3.2 Installation time-out loading drivers or libraries

Hi,
(Firstly this is my first time posting to a forum like this so thanks for your patience if i haven’t uploaded everything i need or I’m repeating a post, I did search).

TLDR: Past the flash stage - manually inputting the IP address, it begins ssh transferring at over 300kB/s then over the next 2 minutes the speed drops to 7kB/s and holds there with an estimated time for first .deb file of 22hrs+ then never finishes.

TX2, trying to set up for the first time, using Jetpack 3.2 with pretty much default everything - following the tutorial video essentially step-by-step.
Admittedly more than likely my problem is my old Dell dual booted Win10 + Ubuntu 16.04 that is the culprit however it seems ok in every other sense, also the router/switch from my internet provider while it’s new, it’s probably average! (like most internet infrastructure in Australia. ha).

• setup has seen every iteration (of ethernet or wifi connection) however the most success so far is ethernet cable Host ---> router <---tx2
• It failed about 8 times with "Determining IP address of target.." until I realised the flash didn't need to happen every time and could start from the uploading libraries stage. #winning :D
• The transfer starts promising at high speed then drops to worse than dial-up. Would you guess it's a problem with the SSH connection? An IT guru at work thinks it may be because SSH encrypts then decrypts and it could be a bottleneck?
• Would I be better off loading the essentials like cuDNN etc directly from the TX2 using its wifi to the internet? If so would someone please point me in the direction of how to do this?
• It's difficult to find a how-to-setup guide in a worst case scenario like this when Jetpack dies so close to the finish line.

Thanks for your time.
Am so keen to get into this.
cheers,
Rob

Hmmm…it shouldn’t take that long. Having the transfer start ok then slow that drastically is odd.

The dual boot with Ubuntu 16.04 is the best choice, it isn’t a problem. This should work quite well even on older hardware.

Between host PC and Jetson only wired ethernet is supported…WiFi here will be a problem. WiFi between host and the outside world should be fine.

It isn’t unusual for routers to have issues like this…I would try to reboot the router at least once before starting just to be sure.

Note that automatically determining address is a bit of a hack from part of the flash. If you don’t flash, and just update packages, then I’d expect to always enter the address manually unless you’ve set something up to deal with it.

SSH requires more work than unencrypted, but in practical terms a local gigabit network even on hardware 15 years old should be extremely fast. I doubt using ssh is the issue. There may be other features related to ssh which get in the way, but odds are low (more typically if you have an expensive managed network switch the switch might be set up to do something fancy which causes more harm than good).

JetPack will create a local repository directly on the Jetson somewhere in “/var”. Normally a repository used with apt-get implies talking across the internet…but it can talk to a local file system directory, and this is what the local repository is. JetPack creates the entire repository on the Jetson, and after that no network contact is required at all to query or add packages from this.

Try rebooting the router, and using only wired ethernet from Jetson to host.

Thanks so much linuxdev for the speedy response.
I’m still trying what you recommend here, it’s narrowing down to be a network problem I think, using another router/switch and new cables are my next steps. Just checking quickly if you don’t mind, the type of cat ethernet cable I should use if you were to setup the link between the TX2 and the Host with a physical cable and the link to the router as wifi from the host? ie. normal cat5 or with the lines swapped? I need to learn more about all this.
Thanks again, I’m sure we’ll get there eventually!

The wired ethernet ports are normally cat 5e or 6 cable. The Jetson itself must use this wired port for any package additions…flash itself uses only the micro-USB. WiFi will be a problem for extra packages, but if it is the host using WiFi to the internet, then this is ok because it isn’t the Jetson using its WiFi during setup.

Not all wired ethernet ports can auto-detect when a cross-over cable is needed…normally you don’t use a cross-over cable, very few sold are of this type. If you went directly from host PC to Jetson without an intervening switch or router, then you would either need a cross-over cable or your hardware would need to auto detect this. To emphasize, this only matters if two network cards directly connect without a router or switch between them.

If your router is wired, then typically rebooting it will clear cache. You might leave it off for perhaps 30 seconds.

Hi, thanks again for the help earlier, sadly it’s still going, ha. getting this TX2 has turned out to be a rather large waste of money for me so far.

After several different combinations of brand new cables etc, It eventually times out and says —

“Error: CUDA cannot be installed on device. This may be caused by other apt-get command running on device when installing CUDA. Please use apt-get command in a terminal to make sure following packages are installed correctly on device before continuing:
cuda-toolkit-9-0 libgompl libfreeimage-dev libopenmpi-dev openmpi-bin
After these packages are installed on device, press Enter key to continue”

This makes sense to me as it’s the freshly flashed Jetson and it’s trying to load up the list of packages.
And so, doing apt-get to install these packages on TX2 does not work, it has no idea with: “E: Invalid Operation cuda-toolkit-9-0”.

Do you know if NVIDIA provides a how-to or list of loading everything onto the board from the point it falls over? ie from the point it finishes flashing using the usb?
This is very disappointing :/.

Thanks,
Rob

About lock files and finding there may be be an apt-get ongoing…

Much of this is Ubuntu setup/behavior, and won’t differ much versus a desktop PC. Something to consider while working on it is that two Debian package operations cannot be run simultaneously, but sometimes when you log in via GUI it might start such a check on “update” status automatically. In that case you wouldn’t be able to use any package manager updates until it finishes. Sometimes the system will check for package updates upon boot completing even without login (depending on settings). A freshly installed Jetson will have lots of updates and any such update will take a lot of time in comparison to a system that was updated a week ago (hours versus seconds, depending on network connection).

To complicate this the lock may be assumed to exist due to a stale lock file rather than due to an active process. If the previous apt-get process terminated abnormally, then the stale lock file may be falsely indicating something using the system and locking others out when it shouldn’t (if “apt-get” is killed before it finishes then it never gets a chance to clean up the lock file). This is typical of all of the Linux distributions even though details may differ among them.

Lock files themselves might indicate a lock just by being present…or sometimes by having a PID in them (versus being empty)…or there might be a lower level lock mechanism used (e.g., flock). So unless you see a lock file with a PID in it you don’t know if something went wrong or not…if there is a PID in it, then you can wait for that process to end if it exists.

In the case of apt being locked…if you know for certain the lock is stale and there is no update or package operation going on, then you could just remove “/var/lib/apt/lock”. But be very very certain nothing is running from some automatic update mechanism on reboot. It would be bad if you you destroy a lock file and there really is some operation running (anything “apt” or “dpkg” in “ps aux” would cause a lock).

So the first question is whether the simple “sudo apt update” command complains it is locked.

Next, do you see file “/var/lib/apt/lock”. If so, after waiting several minutes, do you see anything other than the actual egrep from:

ps aux | egrep -i '(apt|dpkg)'

If the file exists, and no operation is showing, and you have waited several minutes…try removing “/var/lib/apt/lock”. Then run “sudo apt update” again and see if it responds. When it finishes try running package installs again. Remember that JetPack can be run at any time, you just need to uncheck all of the operations and then check only the packages you are interested in…start simple with just CUDA.

You may want to always start by seeing if the Jetson can run “sudo apt update”.

On a separate note flash and package addition are actually separate operations. Flash always completes and then the system reboots. JetPack then copies files over to the Jetson via ethernet. One of the biggest issues is if JetPack doesn’t know the address of the Jetson (in which case entering the address manually is required). The error you got implies ethernet worked but apt-get was busy from some prior operation.