JetPack Issues with the Jetson TX1

I am trying to flash my Jetson TX1 using JetPack 3.0, but I am having issues. Here is a list of everything I’ve done and the problems I’ve run into:

  • Run JetPack normally (after running chmod +x)
    There was not enough memory on the host computer.

  • Run JetPack from a 64GB flashdrive (granted only about 25GB are free)
    This involved remounting the usb port on the host computer, but once I got that working, JetPack ran. I got to the point where the XTerm pops up and tells you to put the Jetson TX1 in force recovery mode, which I did (yes, lsusb does indicated that the board is connected). There is an error because the command to run sudo_daemon tried to use the flag -installer=fake_installer_pid. The program crashed, directing me to check the flash log file. This log file indicates that jetpackfifo could not be opened because it didn’t exist.

  • When the XTerm asks for my sudo password, copy the file jetpackfifo_req and rename the copy to jetpackfifo (clearing out the contents of the file as well)
    This got to roughly the same spot as my last attempt, but the XTerm was just stuck trying to run a cp command. Using ps -a multiple times, I was able to determine that it was trying (and failing) to run the same command over and over, as the process for that command had a different time for each call of ps -a.

At this point I dug around some of the log files. In */_installer/tmp/log I found several lines indicating that various fifos could not be created (“operation not permitted”). I figured this was the source of my problems.

  • Give every file related to JetPack all possible permissions (-rwxrwxrwx)
    Nothing changed from my last attempt. After some research I determined that the issue might have to due with the fact that the original call to ./JetPack-…run was not run with sudo.

  • Use the command “sudo ./JetPack-…run” (I didn’t actually use …s)
    Very quickly the terminal read “Uncompressing JetPack 100% Extraction Failed”. This seems very odd since it worked just fine without the “sudo” part. One thread on this forum indicated that space may be an issue, but this all happens before I even reach the Components Manager, and I’m running on a flashdrive with about 25GB of free space.

This is as far as I’ve gotten. In case you were wondering, the host is running Ubuntu 14.04. I would be happy to give you any other specifications, outputs, or log files. Just let me know what you need. For now, I’m going to continue rooting around in the log files and .sh files (don’t worry, I won’t change anything) to see if I can figure anything else out. Any help is greatly appreciated.

Just a note on flash drives…they work, but normally these are by default formatted as VFAT, which will cause a failure. They must be formatted as a native Linux partition type, e.g., ext4. You wouldn’t see a failure during the flash, but the Jetson would behave oddly and sudo would not work. There are file permissions not supported under other operating systems, and there are also file types which other operating systems do not support…hence their file system formatting may do something odd or unexpected if you try to create permissions or certain file types on a non-Linux file system. Perhaps the fifo problems were a side-effect of this. You can use “df -H -T” to see file system types and free space.

Note that loopback devices are used during flash. There is a stage where a file of about 15GB in size is created with no content. Then this file is loopback mounted and formatted…at this stage if loopback has an issue then you can expect problems creating that file system on loopback, but this does not occur until after decompressing JetPack (there was a decompress error). FYI, I would expect 25GB to be sufficient if using command line and working only with flash, but JetPack may require significantly more space as it decompresses the local repository (this is unpacked on the host in preparation for the choice to copy over to install on the Jetson).

First, make sure your flash drive is ext4. Second, if you have only 25GB, consider command line flashing instead of using JetPack. You can still run JetPack at a later date…once flash is done you can remove temporary files on the host to make room for the host to unpack local repos…if you don’t flash using jetPack, and just install packages, then those temporary files should never be created (this would save about 18GB).

What are the steps for flashing the board from the command line? And how much memory would this require? Specifically, I need OpenCV and CUDA.

Also, I know JetPack is only supported on Ubuntu 14.04, but if I’m flashing from the command line, can I do that on Ubuntu 16.04?

Only JetPack depends on Ubuntu 14.04 host version. Command line flash works from any x86_64 host, but lacks the extra package features and any network setup.

See this URL for downloading driver and sample rootfs packages:

Flashing from command line is fairly simple. When you unpack the driver package it produces subdirectory “Linux_for_Tegra/”. From “Linux_for_Tegra” there is additional subdirectory “rootfs”. If you cd into rootfs you can unpack the sample rootfs there, then do a couple of more steps and you’ve flashed:

sudo tar xjf /where/ever/it/is/Tegra_Linux_Sample-Root-Filesystem_R24.2.1_aarch64.tbz2
cd ..
sudo ./
# Make sure Jetson is in recovery mode (e.g., lsusb sees it).
sudo ./ -S 14580MiB jetson-tx1 mmcblk0p1

…this takes significant time, then you are done. You might run “df -H” prior to starting and be sure you have about 25GB of free space.

When you say “lacks the extra package features and any network setup”, does that mean that I won’t be able to put OpenCV and CUDA on the Jetson TX1 with this method?

If so, how do I get OpenCV and CUDA on the device? What are the steps required for doing this?

You can’t put OpenCV or other packages on during flash. Even the JetPack front end does this after flash is done and reboot is complete. Technically though, if you had all of the files for OpenCV in place in the rootfs, then you would have OpenCV directly from the flash.

You can run JetPack after flash and use JetPack purely for package utilities. Just de-select flash.

There are some tricks which allow you to unpack the local repo JetPack would have put onto the Jetson and instead unpack those to a PC host even if it is not Ubuntu 14.04 (I do this on my Fedora). The repo can then be manually copied over to the Jetson and anything available under JetPack will be available on the Jetson after that. No matter what though, you need the flash.

Someone else originally figured this out here:

A summary for unpacking on a non-Ubuntu 14.04 host (e.g., works on Fedora):

bash ./ --noexec

Running “./Chooser” produces produces human-readable “repository.json”…URLs are in this.

The URL you are interested in is for the arm64.deb. I don’t know if this is still the most current, but somewhat recently this would have been relevant under JetPack 3:

If you copy a .deb over to the Jetson and use dpkg to install it, then there is a local repo added in “/var” which makes a large number of packages available which correspond to what JetPack would install. You install the .deb in order to make all others available from simple apt-get commands.

I think I’m really close. I got the board flashed and I found that repository.json file, picked out the arm64.deb files, put them on the Jetson, and used dpkg, but I’m not sure what apt-get commands to use and if it’s apt-get install I don’t know which packages to install.

Also, how will I know when OpenCV and CUDA are installed? Will there be a file/folder somewhere that indicates I’ve got them?

In general each Linux install (there are many flavors) has some sort of package tool. The package tool is designed to look at dependencies, so for example, if one package conflicts with another, it might refuse to install a conflict. Or the install might be refused if there is a missing dependency. The basic package tool has no understanding of how to solve dependency issues, that’s up to a front end. For Ubuntu the package tool is dpkg, and the front end which solves dependency issues is apt (or apt-get or a number of related apt tools).

When dependencies are being solved by the front end, repositories are consulted to find out what packages might be used to solve the dependency. Most of these are on official Ubuntu servers listed in “/etc/apt/sources.list” naming a web address. Once you’ve installed the relevant .deb file on your Jetson a new repository is added which can be used by apt to solve dependencies…only it is stored locally in a subdirectory of “/var” instead of on a remote server. You now have the ability to search for and install any of the packages JetPack would have made available.

For example, you could “apt search cuda” and probably find a number of packages. Just for a contrived example, suppose your search says there is package “cuda-cool-stuff”…you could then “sudo apt-get install cuda-cool-stuff”. You’re required to have some slight knowledge of what you want, search for an exact package, and then add the package with apt-get. Chances are that if the package is available on your desktop PC running Ubuntu, then the package will be the same name on the Jetson (architectures differ, but apt does not need to be told architecture, it already understands that).

I think all I need to do now is figure out exactly which packages I need for my specific project. Thank you so much for helping me out!