JetPack 3.2 — L4T R28.2 Developer Preview for Jetson TX2

We’re pleased to announce that a developer preview release of JetPack 3.2 is now available for Jetson TX2!

Highlights include support for TensorFlow models in TensorRT 3.0, up to 15% perf/W improvement for DL applications, out-of-the-box kernel support for Docker, and support for Ubuntu 16.04 on your host PC (Ubuntu 14.04 on your host PC will also work, except cross-development packages for OpenCV and VisionWorks will be unavailable on that host PC). The preview is only for TX2. For more info, please view the full Release Notes.

JetPack 3.2 components:

  • L4T R28.2
  • CUDA 9.0
  • cuDNN 7.0.5 RC
  • TensorRT 3.0 RC2
  • OpenCV 3.3.1
  • VisionWorks 1.6

Release Notes…
Download JetPack…
Software Overview…
28.2 Release Page…
Archive Page…

Failure described below, but FYI, JetPack 3.1 works from this host (it’s a native install laptop Ubuntu 14.04). Deleting and restarting JetPack 3.2 pre-release does not change anything. Also, this laptop has complete internet access over wired ethernet…it has no port restrictions and no proxy complications. On other Jetson installs there is no issue with ssh access, and ssh askpass is installed.

I’m using JetPack3.2 pre-release for install of L4T and some packages (no host install) and getting an infinite timeout/wait after I click on Next in the screen where packages are picked. There is no activity on the disk after a very short time (fatrace and "sudo watch du -h -s "). The entire content of the JetPack3.2 directory never exceeds 142MB.

Sorry, this is a bit long, I’m describing the process of finding out that perhaps repository.json is not valid despite not having any “smoking gun” evidence this is the case.

I discovered (even with “NV_DEVTOOLS_FORBID_MULTIPLE_DOWNLOAD_THREADS=1 ./”) there is a duplicate process of this example shown below (from looking at htop in tree view, abbreviating due to the long line, showing on multiple lines for clarity…this represents what JetPack called):

<location>/_installer/Chooser \
 -d tx2_64bit \
 -s <location> \
 -c <location>/jetpack_download/repository.json \
 -p 4671 \
 -t /tmp/tmp4671aaaaaa \
 <location>/jetpack_download \

There is one process exactly as noted above, and this has two child processes which are also exact duplicates (one parent process, two child processes, all the exact same command line). This looks like recursive calls to itself using exactly the same arguments. Even with “strace -f” it shows this is just waiting forever and never proceeding (the next menu never shows up…I’ve let it run overnight…strace goes quiet indicating something is blocking). fatrace shows there is no file access being attempted during this wait. strace shows waiting on a resource and strace output never shows more activity. The terminal has no activity and does not ask for passwords…it never gets that far. No polling is shown, just pure blocking and waiting.

If I kill the last child process from the above (kill -9…kill -15 has no effect), then the original process still has one child exactly like this, and install looks like it proceeds (the menus start allowing me to continue)…except nothing installs or downloads…all it does is let me click the Next menu button. Serial console never shows activity, the original install remains without harm, and the JetPack directory and subdirectory content does not change.

The file selectcomp.txt never appears. Perhaps nothing can proceed because the package selection list file does not exist? What does JetPack do if selectcomp.txt is named on command line, but the file does not exist?

So I simplified. I cut this down to just downloading “File System and OS” plus “Drivers”, with no flash, and no other packages…it still halts and does nothing…strace waits…the directory never gets any file access.

Under JetPack 3.2 pre-release, what is selectcomp.txt dependent on in order for it to be created (and should it be created in the user’s home directory instead of the JetPack directory)? This laptop does not have an NVIDIA graphics card, and is “puny” by many standards…dual 64-bit atom and 2GB of RAM. There is no reason to download any host packages to this laptop, but it seems to be a valid flash host for all other cases.

In repository.json I see all download URLs for all packages are missing the “” prefix except for some png icons (see “grep http repository.json”)…I see one png icon downloaded. If all URLs are invalid, would this cause selectcomp.txt to also not show up? Would JetPack know if a URL were invalid, or would it simply wait forever?

I’ve got the exact same issue with JetPack 3.2, my host machine is running Ubuntu 16.04. No problems with JetPack 3.1.

The URLs should be automatically prefixed at runtime by JetPack with the “compDirectory” entry near the top of repository.json, this is so the full URL need not be repeated in each sub-component (making it easier to change the master repo location):

"compDirectory": "",

Do you have any logs from JetPack under jetpack_downloads/ or under _installer/logs/, or failing that a screenshot of the error?
Is your repository.json corrupted or look valid (under jetpack_downloads/)? Does the behavior persist or intermittent?

In my case I have http.txt, but this isn’t really a log, it’s just one of the web page contents.

For me I never get to the actual download stage because the “next” button is grayed out…the button cannot be selected (it remains gray) without selecting to install to host as well (and on this host with integrated Intel graphics this is a “bad idea”…it has been a while, but I think I had to go to text mode and remove the non-Intel video after that). I will probably try to revisit this in a few days and see if I can see something more detailed.

I was unable to get JetPack for 3.2 pre-release to work. Other people have reported it fails unless the 3.1 release was also used…my 3.1 is in a different directory. It looks like perhaps something 3.1 puts in place might make 3.2 pre-release work, but I don’t know what it is.

In my case when I check packages which exclude anything in the host the buttons (at the point where the actual downloads should begin) are all grayed out and inert…I can’t actually start the download. I ended up using the URL and suffix from repository.json to do a command line flash.

In my case the log is more or less empty…it never gets to start. I have tried with and without the “automatically resolve dependency conflicts”. Here is an example where host CUDA toolkit is not installed and I cannot hit any buttons (in JetPack3.1 I can)…

Dear officer,

is there any news for the next generation of Jetson? will it release this year? Many thanks.

Hi lilcolinn, we aren’t able to officially confirm details or further information at this time, for public information see coverage from Jensen’s presenations:

Can I install CUDA 9.0 (deb file taken from the TX2) manually on top of the TX1 R28.1?

While you can’t officially comment, from the Spectre advisory I know it can’t be much longer for the official TX1 R28.2 release, so if this is a bad idea please say so.


In theory you may be able to take the deb bits from TX2 and install them to TX1, however you are correct in that R28.2 is nearing production release (for both TX1/TX2), so at this point it may not be worth your extra time & effort to do so.

Question on 3.2 content… Will the argus library in the multimedia api be a full, rather than beta, release? If not, is there a planned date for argus 1.0 release?

The version of Argus in 3.2 will be similar to the version in the 3.2 Developer Preview release. Argus 0.96 isn’t beta persay and rather fully-featured, Argus 1.0 is waiting for functional safety.

For anyone experiencing this issue make sure that

pkexec bash

works for you in the console.
Dear NVIDIA engineers, please add a check for pkexec command result in InstallUtil.

I seem to have solved this problem, for my install at least.

Firstly, I set the nvidia user (actually the whole %sudo group) to have sudo with NOPASSWD. I’m not sure if that was necessary.

Then, the thing that actually fixed it for me was when I checked /var/log/auth.log on the target, it showed:

Authentication refused: bad ownership or modes for directory /home/nvidia/.ssh

It looks like something set the permissions on that folder to Group Writable. So:

chmod og-rwx /home/nvidia/.ssh

and the installer is now happily installing and compiling.

Now that’s done I’ll wind back the changes to sudoers.

The installer is a little too clever for its own good: it blithely sets

-o PubkeyAuthentication=no

and tries to crowbar in its own ssh keys, even when the developer has already made damn well sure the keys are set up correctly. As the file is a binary, it’s not a script that can be hacked, unfortunately.

EDIT: Incidentally, when I was stuck earlier in the process with it paused at the IP / User / Password dialog box, it appeared to be an ssh job that’d hung, again thanks to pubkey shenanigans. Instead, I just kill -9’ed the hanging ssh and let it proceed. As I’d set up the public key access properly, the actual install progressed fine (once I’d fixed the permissions as above)

I hope that’s of help to someone.