Using Jetpack from Arch Linux?

So I don’t really have an real linux machine, just a few RPis and a dual booted Mac running macOS and Arch. I don’t really want to triple boot with Ubuntu as well, so, due to the complete lack of resources with Arch, I wanted to ask if this would work.

Although JetPack requires Ubuntu due to specifically needing the Ubuntu package manager, just flash using the driver package plus sample rootfs works on any x86_64 Linux. So if the Mac has a VM which can run any Linux x86_64 you can make it work for flash. Just be warned that often there are more details to get a VM working correctly, e.g., sometimes USB setup, plus the actual underlying file system must be a native Linux type, e.g., ext4, and plenty of disk space is needed.

Theoretically you might be able to install Ubuntu to a USB flash drive and install from there:

If you try it, let us know if it works.

The following is borrowed from:

the original page does not seem to be accessible any more…

The first step is to download the last JetPack from the Nvidia website.
On a non Ubuntu system, running JetPack installer produces the following error :
$ bash
Error: JetPack must be run on Ubuntu platform. Please check your platform and retry.

Adding the –help flag to the command line provides additional flags:
bash –help The one we are looking for is the –noexec flag which unpack the JetPack files without executing installation scripts: bash –noexec

Installation tools and scripts are located into the _installer directory:
cd _installer ls
Chooser local.cfg.tmp
configure_host nv_info_broker run_command
flash_os PageAction
InstallUtil Poller sudo_daemon
JetPack_Uninstaller rc.local

The command which displays the list of available packages for the boards is called Chooser.
$ ./Chooser
However, if you run it, it may display an error like “missing libpng12 library.”
So, download the library (libpng12 on SourceForge), unpack and compile it, then:
export LD_LIBRARY_PATH+=:path_to_libpng12/lib

Now the Chooser command may work but you do not need to use it!
Indeed, it starts by checking Nvidia servers and produces a file call repository.json which contains all the links to the Nvidia packages.
$ cat repository.json | grep cuda-repo

“url”: “”,

Now you can do whatever you want with these links, for example to get the CUDA 8.0 package on your Jetson board:
$ wget

Then you can install it:
dpkg -i cuda-repo-l4t-8-0-local_8.0.34-1_arm64.deb apt update
apt search cuda apt install cuda-toolkit-8.0

After performing all of these steps, I wonder why Nvidia does not provide access to these packages anymore since it is supported on more platforms and does not require an additional computer to update the Jetson boards.

Just beware that the repositories list packages for both the host PC and the Jetson. If it is “amd64”, then that is for a host PC; if it is “arm64”, then it is for a TX1 or TX2; if it is armhf or arm32, then it is for a TK1.

Incidentally, there are a lot of interesting things which could be done if NVIDIA had an actual package server, but there may also be complications. One complication would be how any EULA or copyright notice is added. One benefit would be that the content in “/var” wouldn’t require having the entire repo there just for one package…"/var" would then contain only what was added.

Even if a regular package server were available you’d still need something like JetPack for flash by means of a host PC because embedded systems do not have a BIOS (or equivalent). Desktop PCs can self-install because of this uniform interface. This isn’t really practical for embedded systems, e.g., imagine if smart phones were all double in size just so you could install an o/s without a host. Your host PC acts as a temporary BIOS during flash…the driver package provides the interface instead of a BIOS.

Additional note: There is a single “.deb” file from JetPack download which is a “repo” file for CUDA. Installing this “.deb” file is what puts in the local repo within “/var”. Once this is in you can use standard apt-get install mechanisms…but the repo is in the Jetson instead of a remote server.