Jetpack 3.3 for Jetson TX2 installation error - stuck on Component Manager screen

I am trying to install jetpack 3.3 on my Jetson TX2.

On the host Linux machine, I downloaded and installed everything through the “Component Manager” screen. But then when it came time to flash the Jetson, I had a pop up box with this error:

“Return Code: 127 /bin/bash: xterm: command not found”

So I had to exit the jetpack installation GUI to install xterm.

After installing xterm I reopened the GUI, but now I cannot get past the “Component Manager” screen. When I click “Next” it gives me the option to accept all the licenses, and input my sudo password, but then it just goes back to the same “Component Manager” screen without giving an error or any other messages. I can then infinitely repeat this process by clicking on “Next”.

Can anyone help me troubleshoot why this is happening? It might be worth mentioning that the GUI does remember the previous files I installed and downloaded, so it doesnt try redownloading them.

I don’t know if it is missing “xterm” on the PC host or if it is missing on the Jetson, but likely it is missing on your host. What do you see if you run the command “which xterm”? If it isn’t there, then try:

sudo apt-get install xterm

The PC host was missing xterm and I did install it as I originally mentioned in my post “After installing xterm…”. So xterm is not the issue. The issue is that the installation GUI is stuck on this screen:

When I click “Next” it gives me the option to accept all the licenses, and input my sudo password, but then it just goes back to the same screen as in the screenshot without doing anything.

I tried producing a log in the terminal tab but its empty. Can anyone recommend how to resolve this or at least how one would go about troubleshooting this?

Is the host a VM?

It looks like it is set to flash, but flash has not yet started. Did it ask for the IP address (this would only occur after the flash stage)?

Does the Jetson show up in recovery mode with “lsusb -d 0955:7c18”?

You mentioned no log in the terminal tab, but the “terminal” is actually a console. If you click “next” while the terminal is selected, does anything show up? Did you originally start the app as a regular user (you can’t start it sudo or as root, so at one point it wants the password to the host’s user, and later it may want a password for the Jetson’s user)?

One of the first things to do is start out with a clean directory which is completely empty.

For Jetpack 3.3, I am getting this same behavior. Next just grays out momentarily and comes back with nothing happening. The license agreement page comes up the first time, then just a momentary graying out. Would be nice to know the error so I can fix it.

  • xterm is installed
  • jetson shouldn’t be necessary at this stage, it is predownload
  • clicking on the terminal before hitting next does nothing
  • I am a regular user with sudo rights
  • Directory is clean

For JetPack3.3 there might still be a need for various ssh related packages, but can you post a log of the flash? If you have a serial console, can you post the boot messages from the Jetson? For serial console see:


06-21 19:28:29.2 N: GoogleAnalytics disabled
06-21 19:28:30.0 E: fopen failed with file local.db, errno = 2
06-21 19:28:47.3 W: One invalid entry
06-21 19:29:13.3 N: Install com.nvidia.l4t.driver4os_64_tx2 28.2.1; Install com.nvidia.l4t.filesystem_64_tx2 28.2.1; Install com.nvidia.l4t.flash_64_tx2 28.2.1; Install com.nvidia.cuda.l4t_64_tx2 9.0; 
06-21 19:29:14.6 N: /jetpack/install//InstallUtil setup /jetpack/install/ 191
06-21 19:29:14.6 N: InstallUtil setup return code127

The log looks incomplete, but the fopen entry might be why. I don’t know what to make of that, but let’s simplify and directly flash without involving JetPack. After the flash attempt you should have a “Linux_for_Tegra/” subdirectory. Within that is a “rootfs/” subdirectory. To verify, is there content other than a README file in “rootfs/”? If so, then continue like this from the “Linux_for_Tegra/” directory with the Jetson in recovery mode and the micro-B USB cable connected:

  1. sudo ./
  2. sudo ./ jetson-tx2 mmcblk0p1 2>&1 | tee log_flash.txt
  3. Reboot the TX2 and see what happens.

If you hover your mouse over the quote icon in the upper right corner of one of your existing posts, then other icons will show up. The paper clip icon is for attaching files…attach the “log_flash.txt”.

I guess that db file doesn’t exist.

There is no Linux_for_Tegra folder under the install directory, just _installer and JetpackUninstaller. I think it is failing trying to download everything. I have internet connectivity. I am using a docker image of ubuntu 16.04, so it is more bare bones than normal. I have ssh and wget installed and can run apt-get update. I made a normal user with sudo rights.

FYI, I assume docker has a lot in common with a VM, and will have problems associated with it…perhaps even more than a VM. Missing packages would be among the issues. Internet is required to download the json master list of other files to download, and then to download files mentioned in the json.

In the install directory, what do you see from:

tree -L 3 -d

(if you don’t have “tree”, then “sudo apt-get install tree”)

I assume you are using the same JetPack3.3 the original post uses…if not, then add a note on the version you used. For example, JetPack3.3 or what superseded it, SDK Manager4.2.

Failure to download items in the repository json file (or even the json itself) would result in missing the Linux_for_Tegra directory. If all of the Linux_for_Tegra subdirectory is missing, then it implies JetPack (or SDKM) did not have internet access to various items.

FYI, it is correct to use a normal user to run JetPack, although that user must have sudo rights, and when JetPack (or SDKM) prompts for a password it must be able to gain root access. That sudo must also grant the ability to do things like add network interfaces (and if a host denies that, then you can’t use that environment). In one setup the TX2 gets its address from a router appliance, and then JetPack accesses via that address. In another setup the host PC becomes a DHCP server and provides the address to the TX2…in which case JetPack needs to be unrestricted in setting up as a DHCP server and seeing a DHCP request by the TX2.

Overall, I’m expecting some limitation of docker is going to be difficult to deal with and you’ll end up creating a dual boot instead of using docker.

Docker should have fewer issues with usb, I think as I am directly passing the device to it and it isn’t emulating anything. I have tried the VM route as well and the device disconnects during the flash and doesn’t reconnect and fails. If that happens I guess I will know. (I am currently having to run flashes from a separate computer than my main dev machine booting off USB as I don’t want to blow away that machine for ubuntu 16.04, nor do I want to be held at particular releases if I were running ubuntu. So, I’m trying to alleviate some of that pain by getting it working in Docker.)

It successfully downloads the manifest and shows the software available.

└── _installer
    ├── logs
    └── tmp

3 directories
  • I am using Jetpack 3.3-linux-x64_b39
  • I have internet in the image.
  • I have sudo rights in the image.
  • Network is shared with the host… I have tried both bridged and host mode
  • Container is running in privileged mode

The network privileges you specify like dhcp server… not sure, but I don’t think I should be hitting those issues before even attempting to contact the TX2. Not on a restrictive firewall. My live ubuntu image running on the other computer can download stuff.

I’m not sure how docker will work, but it needs full internet access. Something is still missing because it failed to download and unpack the driver package (this is the part which produces the flash and the Linux_for_Tegra subdirectory). I don’t know enough about docker to help you debug that, but if you can, get JetPack to download everything for flash and only for flash and see if you get a Linux_for_Tegra subdirectory.