# jetson-image: minimal Ubuntu images for NVIDIA Jetson boards

> jetson-image builds stripped down Ubuntu images for NVIDIA Jetson boards, because the official images are large and carry packages that are not needed. The build runs in podman with just and jq, produces a flashable jetson.img, and the project is released under AGPLv3.

**pythops/jetson-image** — 💾 Create minimalist, Ubuntu based images for the Nvidia jetson boards

- Repository: https://github.com/pythops/jetson-image
- Stars: 592 · Forks: 149
- Language: Shell
- License: not declared
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/pythops-jetson-image

## Why the stock Jetson image is too big

The motivation section is one sentence and it sets the goal precisely. The need for the minimalist images came from the official Jetson images being large in size and containing pre-installed packages that are not necessary, which results in the consumption of valuable disk space and memory. That is a specific kind of complaint, not a general one. Nobody builds a stripped image because the official one is ugly. They build it because the eMMC on a Jetson is small, because a lot of the pre-installed stack is irrelevant to a headless edge deployment, and because RAM on these boards is the scarcest resource you have. The README gives a number for what the project buys back, stating that for the Jetson Orin Nano with the new image only 220MB of RAM is used, which leaves plenty of RAM for your projects. That is the project's own measurement of its own image, and it is the number to check against your own board. The whole design follows from this premise. If your workload needs the vendor stack, use the vendor image, because a minimal image is only better when the things you removed were genuinely dead weight for you.

## Boards, Ubuntu releases and the L4T versions you can pair

The support matrix is given in two places in the README, one for boards and one for the software stack. The board list has Jetson Nano, Jetson Nano 2GB, Jetson Orin Nano, Jetson AGX Orin, AGX Xavier and Jetson Xavier NX, all ticked. The software side is a set of supported Ubuntu releases, 20.04, 22.04 and 24.04, and a set of L4T versions, 32.x, 35.x and 36.x. The L4T number is the important one, because L4T is the Jetson software stack version and it is what determines which bootloader and which driver set your image needs. The repository layout mirrors that matrix exactly, with a Containerfile for the rootfs per Ubuntu release, Containerfile.rootfs.20_04, 22_04 and 24_04, and a Containerfile for the image per L4T line, Containerfile.image.l4t32, l4t35 and l4t36. There is one restriction in the notes that will save you a wasted build, that only the Orin family boards can use Ubuntu 24.04. And there is a warning that not every Jetson board can be updated to the latest L4T version, with a link to the NVIDIA developer archive to check, which is the first thing to do before you pick a version for your board.

## The build host needs podman, just, jq and qemu-user-static

The build is described as fairly easy, and the prerequisites are four tools: podman, just, jq and qemu-user-static. Each one has a job, and it is worth knowing what they are doing before you install them. Podman runs the container builds, and the Containerfiles in the repository are the build recipes. Just is the command runner, and the Justfile at the root is the entry point for every phase of the build, the rootfs, the image and the flashing. jq does the JSON work, which is what the Containerfile build arguments and the metadata handling rely on. And qemu-user-static is what lets a container build emulate the Jetson architecture on an ordinary machine, which is the piece that makes the whole approach possible without Jetson hardware. The README notes that building the Jetson image has been tested only on Linux machines, so the build host itself is a constraint rather than a recommendation. The setup itself is a clone and a directory change.

```bash
git clone https://github.com/pythops/jetson-image
cd jetson-image
```

Because the toolchain is declarative, the build is reproducible in a way a hand assembled root filesystem is not. Every dependency and every step lives in the Containerfiles and the Justfile, which is also what makes the project forkable, since adding a package is an edit to a Containerfile rather than a change to a script you maintain.

## Step one: the rootfs, and the WiFi that has to be baked in first

The first phase creates the root filesystem, and it has an ordering constraint that is easy to get wrong. If you want the board to join a network on first boot, the WiFi configuration must be set up before the build command, so that it is properly baked into the image. The mechanism is a file per network named with the network name and the .psk suffix, placed in the config/iwd/networks directory, which is the layout used by the iwd network daemon.

```
[Security]
Passphrase=<WiFI Password>

[Settings]
AutoConnect=true
```

With that in place, the rootfs build is one command with the Ubuntu version as its argument, and it produces the root filesystem in a directory called rootfs.

```bash
just build-jetson-rootfs 24.04
```

The accepted values are 20.04, 22.04 and 24.04, with the note that only the Orin family boards can use 24.04. The README also tells you where to make the image your own, pointing at the Containerfile.rootfs.* files and telling you to modify them to add any tool or configuration you need in the final image. That is the intended extension point, and it is the right one, because anything you install into the rootfs at build time is part of the image rather than something you have to provision on every device afterwards.

## Step two: the flashable image and the Nvidia package list

The second phase turns that rootfs into a flashable image, and its command line carries four parameters, the board, the revision, the device and the L4T version.

```bash
$ just build-jetson-image -b jetson-orin-nano -d SD -l 36
```

The README says to run the command with -h for more information, and the example builds for the Orin Nano with an SD card device and L4T 36. Where the Nvidia libraries come from is the part worth reading. The tip explains that if you want specific Nvidia packages present in the common section of the vendor repository, for instance libcudnn8, you edit the file l4t_packages.txt in the root directory and list each package name on a separate line. So the deep learning stack is not baked in by default, and adding it is a one line change per package rather than a rebuild of the whole image recipe. That is the right default for a minimal image, and it is also the knob you will turn first if your project is, as most Jetson projects are, a deep learning workload. The result of this phase is a file named jetson.img saved in the current directory.

## Flashing, first boot, and the credentials you will need

Flashing is the third phase, and the README is direct about the mechanism.

```bash
$ sudo just flash-jetson-image <jetson image file> <device>
```

The device argument is the name of the sdcard or usb device as your system identifies it, for example /dev/sda for a card recognised that way. The author's own note is that there are numerous tools out there for flashing images to an sd card and that they stick with dd, since it is simple and does the job, which tells you the flash target is a raw image write and not a vendor specific tool. The fourth phase is the first boot, and the login credentials are in the README, with the username jetson and the password jetson, and the note that the ssh server is running by default and listening on port 22. Two practical points follow. The default credentials are public knowledge, so anything that reaches the network after first boot should have them changed. And the NVIDIA libraries are installed afterwards with apt when you need them, for example libcudnn8 and the matching development package.

```bash
$ sudo apt install -y libcudnn8 libcudnn8-dev ...
```

That ordering, minimal image first and the vendor stack added later over the network, is the workflow the project is built around, and it is worth being honest that it trades a one time build step for a per device provisioning step if your fleet is large.

## The companion tools, and what the licence says

Two companion tools from the same author are recommended on a fresh board. impala is described as a TUI for managing WiFi, which matters on a minimal image because the WiFi configuration is baked in at build time and any change to the network later has to be made from the console, and tegratop is a comprehensive TUI monitoring tool for NVIDIA Jetson boards, which is the tool you want for the memory and thermal figures that a minimal image changes. Both are separate repositories, so the image itself is the part this project owns.

On licensing, the README states AGPLv3, and the repository carries a CHANGELOG.md, a patches directory, a scripts directory and a config directory alongside the Containerfiles and the Justfile. The copyleft obligation is the part to think about, because AGPLv3 reaches beyond distribution of the source to network use, and a build system whose output is a device image that talks to a network service is a case where that can matter. GitHub could not classify the repository licence, so the file itself is the authority rather than the badge. The last push was on 2026-06-19 and the repository publishes no GitHub releases, so there is no tagged version to pin and the CHANGELOG is where you read what changed. For a project that rebuilds a whole root filesystem, that is the sensible arrangement, since the build is described by the files in the repository rather than by a packaged artefact.

## Conclusion

Adopt jetson-image if you are putting a Jetson on a network and the stock image wastes the eMMC and the RAM you need for your own workload, and if you are comfortable building images in a container on a Linux host. It does not fit a team that wants a supported NVIDIA image with the usual vendor support and JetPack tooling, and it does not fit a Windows or macOS build machine, since the README says the build has been tested only on Linux. Before you start, check that your board and L4T version pair is one NVIDIA supports, bake the WiFi credentials in before the rootfs build rather than after, and read the licensing terms, because the README states AGPLv3 while GitHub cannot classify the repository licence.

## FAQ

### Why would I build a minimal Jetson image instead of using the official one?

The README states the motivation: the official Jetson images are large and contain pre-installed packages that are not necessary, which consumes valuable disk space and memory. For a Jetson Orin Nano with this image, the project reports only 220MB of RAM in use, leaving the rest for your own workloads.

### Which Jetson boards and software versions does jetson-image support?

The supported boards are Jetson Nano, Jetson Nano 2GB, Jetson Orin Nano, Jetson AGX Orin, AGX Xavier and Jetson Xavier NX. The supported Ubuntu releases are 20.04, 22.04 and 24.04, with only the Orin family able to use 24.04, and the supported L4T versions are 32.x, 35.x and 36.x.

### What do I need on my machine to build the image?

Four tools, podman, just, jq and qemu-user-static, and the README notes that building has been tested only on Linux machines. You clone the repository, configure the WiFi file if needed, then run the just recipes for the rootfs, the image and the flash.

### How do I add WiFi credentials to the image?

Create a file named after the network with the .psk suffix in the config/iwd/networks directory, containing the passphrase under a Security heading and AutoConnect=true under Settings, and do this before the rootfs build so the settings are baked into the image.

### How do I add NVIDIA libraries such as cuDNN to the image?

The README points at the l4t_packages.txt file in the root directory, where you list each Nvidia package name on a separate line, for example libcudnn8, and the packages are taken from the common section of the Nvidia Jetson repository. Alternatively they can be installed on the device later with apt.

## Sources

- [Issues](https://github.com/pythops/jetson-image/issues)
- [pythops/jetson-image on GitHub](https://github.com/pythops/jetson-image)
- [README](https://github.com/pythops/jetson-image/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pythops-jetson-image