Flashing Jetpack in TX2 devkit without a router only Wifi

Hello,

I am looking to flash Jetpack from my Ubuntu 16.04 virtual box as host (in my 2012 MacBook Pro) to a new Nvidia Jetson TX2 devkit. The problem is – I don’t have access to any router, rather I only have access to WiFi.

In particular, I am stuck in the step where in asks for selecting a network layout. There is an option to create DHCP server from my host, but I don’t know how to proceed from here (given my specifications in the previous paragraph).

I would really appreciate if someone could help me in this, I owe you one.

Best
Debanga

Hi Debanga, flashing JetPack from within a virtual machine isn’t officially supported, and neither is WiFi. If you don’t have a router, there is an option in the JetPack GUI for connecting to the Jetson over a spare NIC port on the host. If you don’t have an Ethernet port on the host, it’s recommended to use a USB dongle or similar to provide it.

Attempting to connect the Jetson and host over WiFi during the JetPack procedure can cause strange errors later on with packages or files mysteriously not installed. Note that you are welcome to have your host connected to WiFi for JetPack to download the packages, just not for the networking connection between the host and Jetson.

Regarding the VM, it’s recommended to dual-boot Ubuntu 16.04 x86_64 if at all possible. If you try flashing from the VM enough times, you may get it to work, however you may also experience drop-outs during the USB flashing transfer as it’s a low-level time-sensitive protocol that VM’s don’t handle very well.

Keep in mind that Linux can act as a router if you use wired ethernet between the host and the Jetson. If you don’t even have a switch, then you could use a cross-over cable. If your host supports auto detect, then the Jetson does too, and then you won’t even need a cross-over…just a regular ethernet. Your host could connect to the internet via WiFi, it is the Jetson which cannot.

FYI, flashing itself only uses the micro-B USB…it is after the flash during package install where ethernet is used. You can flash now, and then run JetPack for extra packages at any future date. Simply ignore packages and use only the micro-B USB and flash (driver package plus sample rootfs are used for this…JetPack is a front end which will download these for you, but you don’t have to use JetPack for that).

Hi Guys, Thank your very much for your suggestions. The reason for my late reply is that I wanted to make sure I try all of the steps you suggested.

I decided to buy an Alienware 15 R3 laptop, installed a dual boot with Ubuntu 16.04. Still I don’t have access to router, so it is connected to wifi (say, W). The name of my ethernet port is say, E.
I successfully flashed my Jetson TX2 in Dev Kit. The key step is: when they ask for networking setup: (1) Select “Device accesses internet via host machine …”, then NEXT, (2) internet interface: E, and Target interface: W. Then just follow the usual steps. Currently, flashing is complete, but it is stuck at “Determining the IP address of target…”. I will update on what happens next!

Update 1: Now, I run the installer without the flash option (which was successful).

It now asks: IP, username (default is nvidia), password (default is nvidia)

Now, I had no idea what is the IP of Jetson. So, I followed:

https://askubuntu.com/questions/22835/how-to-network-two-ubuntu-computers-using-ethernet-without-a-router

Following the answer by nelaaro: I created two networks: host - 10.0.0.1, and Jetson - 10.0.0.2
Now, I put IP 10.0.0.2 as IP address of Jetson. Connected!

Update 2: Now, I faced the following:

Cannot install some packages, says apt-get in use. Says, install those and press ENTER.

CUDA is the most important for me. So my solution:
Connected Jetson to Wifi and installed the package:
sudo apt-get install <the CUDA .deb>
sudo apt-get install -f

Then I pressed Enter (I kept my Jetson connected to Wifi).
Compiling tons of samples now…
After 5 minutes… Failed at some points. Installation failed.

Update 3: While Jetson connected to WiFi, and to host through LAN
Now, I run the installer again from scratch without the flash option. IP, username, password all given as in Update 1.
It’s running, and installing the libraries on target.
SUCCESSFUL… Nvidia Samples running- tested CUDA FFT Ocean Simulation!!!

For those running into lock issues on package installs…

One subtle design issue on many Linux distributions (including both Ubuntu and Fedora) is that often the GUI login will include a check for updates in the little system tray icons in the tool bar (where it displays and with what program depends on your desktop and distribution). If a login to GUI does this, then during the check there will be a lock file generated with the package update tool. Until the process ends the lock file will remain in place and no other process will be allowed to touch package update.

If all goes well, then after a few minutes the lock file goes away and you can try again. If something goes wrong, then a stale lock file will be left in place (often fixed by reboot). One possibility for the file staying around is if networking fails and it gets stuck there (this requires both network and DNS being able to talk to the outside world). I suspect that either something will take a long time to time out, or a previous boot has left a stale lock file.

Does your Jetson have this file?

/var/lib/dpkg/lock

If this file exists, do you see a process listed with:

fuser /var/lib/dpkg/lock

If and only if there is no fuser output (and therefore nothing actually using dpkg) you can simply delete this file. Do not delete this file if anything is listed as using it.

If the lock file exists and something is using I recommend waiting to see if a timeout ends the process using this. This might take quite some time…I’m not sure how much…but perhaps several minutes or even an hour.

If this doesn’t do the trick, and something is using the lock file and you’ve decided waiting won’t work, then you can try telling the accessing process to gracefully shut down. The fuser command would have returned a process ID which “kill” can work with. Doing this wrong is probably not a high risk, but the risk is still not without merit if you kill the process violently as this is related to the database the package manager is working with. As an example, if you have a PID of 3547, then you can see processes like this:

ps aux | grep 3547

…output might be something like this:

root      3547  0.2  0.5  53152 47732 pts/9    S+   19:00   0:01 apt-get upgrade
root      5154  0.0  0.0   5548   568 pts/8    S+   19:06   0:00 grep -E --color=auto 3547

Killing this would be something like:

sudo kill -HUP 3547

This form of kill allows the application to try to shut down gracefully. This might take a few seconds (or more for disk operations like this), and it might not work at all. There is no harm in issuing this command a few times and waiting several seconds between tries. Once the process no longer shows up with “fuser /var/lib/dpkg/lock” you can rm the lock file.

If the process is stuck and you are willing to take a risk, then you can use:

sync
sleep 1
sudo kill -9 3547
# verify nothing using the lock:
fuser /var/lib/dpkg/lock
sudo rm /var/lib/dpkg/lock

Do you have this lock file? Avoid logging in to the GUI and check after reboot via ssh or serial console or even CTRL-ALT-F2 to get to a text console.