LC-X3 Flashing Guide (Jetson AGX Orin / JetPack 7.2.1)

Use catdogai/lzc-x3:jetpack-7.2.1 to flash an NVMe system on an LC-X3 / Jetson AGX Orin with a T912 v1.2 carrier board. The image includes the Jetson Linux R39.2.1 BSP, vendor adaptations, flashing dependencies, a custom T234 partition XML, and preinstalled lzc-jetson-orin-flash 0.2.6. Once the container starts, you can run the flashing command.

JetPack 7.2.1 corresponds to Jetson Linux R39.2.1. For version details, see the NVIDIA JetPack Downloads page. For USB flashing parameters, see the R39.2.1 Quick Start and Flashing Support. The target system is based on Ubuntu 24.04. Other carrier boards require a matching vendor BSP.

Data will be erased

The full flashing command in this guide includes --erase-all, which erases the device's storage. Back up your system, models, containers, and application data first. For the first flash, install only the target NVMe drive and disconnect other data drives. Subsequent provisioning, reset, and storage expansion operations also write to disk; verify the drive names and their purpose before proceeding.

1. Prepare for Flashing

• A native x86_64 Linux host, preferably Ubuntu 22.04, with Docker installed and permission to run privileged containers. The image architecture is linux/amd64, while the device rootfs inside it is ARM64.
• At least 80 GB of free host disk space is recommended for the image, the container's writable layer, and the generated 32 GiB system image. Temporary files are also created during generation.
• An LC-X3 with a target NVMe drive of at least 128 GB installed and a stable power supply connected.
• A USB Type-C cable that supports data transfer, connecting the host to the LC-X3's Recovery port. Connect it directly to the host if possible.
• A monitor and keyboard, or a serial console, for the first boot and troubleshooting LVM initialization.

The container relies on the host's USB, network, and kernel, so this procedure is intended for native Linux. Connect only one device for your first flash. The host's lsblk output lists host drives; it cannot identify the Jetson's internal NVMe drive while the device is in Recovery mode.

2. Enter Force Recovery Mode

When the device is powered on, hold RECOVERY, briefly press and release RESET, then release RECOVERY. The buttons are inside the enclosure; remove the bottom cover if necessary. When the device is powered off, hold RECOVERY, press POWER, then release RECOVERY.

If the device can still enter UEFI, you can also press Esc at the NVIDIA logo during startup and look for Device Manager → NVIDIA Configuration → Boot Configuration → Boot Into Recovery. Enable it, save, and reboot. Menus vary by firmware version; use USB detection to confirm that the device is in Recovery mode.

Check on the flashing host:

lsusb -d 0955:

Common AGX Orin Recovery USB IDs are 0955:7023 and, for some modules, 0955:7223. The device name usually contains NVIDIA or APX. For the corresponding module numbers, see the official Quick Start. If no device is detected, check the cable, port, power supply, and button sequence first.

USB Force Recovery and LZC Orin APP recovery, described later, are different environments. The latter is the recovery system on the SSD.

3. Start the Flashing Container

After obtaining the supplied offline archive lzc-x3-jetpack-7.2.1.tar.zst, import it on the flashing host (requires zstd):

set -o pipefail
zstd -dc lzc-x3-jetpack-7.2.1.tar.zst | docker load

Once the image is published to a registry, you can also obtain it with docker pull catdogai/lzc-x3:jetpack-7.2.1. After importing or pulling the image, start the container:

mkdir -p ~/lc-x3-flash/workspace
cd ~/lc-x3-flash

docker run -it --rm \
  --privileged \
  --network host \
  -v /dev/bus/usb:/dev/bus/usb \
  -v /dev:/dev \
  -v "${PWD}/workspace:/workspace" \
  catdogai/lzc-x3:jetpack-7.2.1 \
  bash

If you do not have Docker permissions, prefix the Docker commands with sudo. --privileged and the device mounts let the tool access the Recovery USB device and its device nodes after re-enumeration. --network host is used for initrd flashing communication.

The container starts in /Linux_for_Tegra by default. NVIDIA binaries, vendor adaptations, the default user, and the Orin deb package are already prepared. There is no need to rerun apply_binaries.sh or twsetup/install.sh, or install flashing dependencies online.

Check inside the container:

cd /Linux_for_Tegra
lsusb -d 0955:
cat rootfs/etc/nv_tegra_release
ls -l ../flash_l4t_t234_nvme.xml ../lzc-jetson-orin-flash_arm64.deb
chroot rootfs dpkg-query -W lzc-jetson-orin-flash

You should see R39.2, REVISION 2.1, and Orin package version 0.2.6. The original deb package is kept in /usr/local/share/jetson-orin-flash/; /lzc-jetson-orin-flash_arm64.deb is a fixed link to it.

Save logs

/workspace is mapped to the host directory, while /Linux_for_Tegra resides in the container's writable layer. --rm deletes the container and any generated flashing artifacts when it exits. Save any logs or files you want to keep in /workspace.

4. Flash the NVMe Drive

Run the following command inside the container, in /Linux_for_Tegra:

sudo ./tools/kernel_flash/l4t_initrd_flash.sh \
  --external-device nvme0n1p1 \
  -c ../flash_l4t_t234_nvme.xml \
  --erase-all jetson-agx-orin-devkit external

• nvme0n1p1 is the target partition on the Jetson, not a host drive.
• ../flash_l4t_t234_nvme.xml points to the custom LC-X3 XML at the image's root directory. It retains the R39.2.1 T234 boot partitions, fixes APP at 32 GiB, and adds DATA_PV (partition ID 16) for subsequent LVM setup.
• The image already sets jetson-agx-orin-devkit.conf's ROOTFSSIZE to 32GiB, so this command does not need an additional -S argument. If you use the original BSP yourself, you must also specify -S 32GiB and install the matching vendor adaptations and deb package.
• NVIDIA's original XML is at tools/kernel_flash/flash_l4t_t234_nvme.xml. Its partitions serve different purposes; keep the custom XML path above if you intend to use provision afterward.

The template retains the EXT_NUM_SECTORS placeholder. By default, the BSP generates partitions using a 57 GiB external disk geometry. During provisioning, DATA_PV is expanded to the actual end of the SSD. The minimum 128 GB requirement provides space for a block-level clone of APP. This layout uses a single, unencrypted rootfs.

Keep the power supply and USB cable connected during flashing. Wait for the tool to report success and the device to reboot. To save terminal output as well, run the same command in this form:

set -o pipefail
sudo ./tools/kernel_flash/l4t_initrd_flash.sh \
  --external-device nvme0n1p1 \
  -c ../flash_l4t_t234_nvme.xml \
  --erase-all jetson-agx-orin-devkit external \
  2>&1 | tee /workspace/lc-x3-flash.log

5. First Boot and LVM Initialization

Run the following commands on the LC-X3 system. The default username is nvidia and the password is nvidia; change the password after logging in. Log in using a monitor, or connect over SSH using the device's LAN address. If USB networking is ready, you can also try ssh nvidia@192.168.55.1.

First, wait for the vendor's twInit.service to finish initialization. The device may automatically reboot once:

systemctl status twInit.service --no-pager
ls /boot/twbsp
lsblk -o NAME,SIZE,FSTYPE,PARTLABEL,MOUNTPOINTS /dev/nvme0n1

You should see an approximately 32 GiB APP partition (p1) and DATA_PV (p16). /boot/twbsp should contain the vendor DTB and tegra234-p3737-0000-twboard-config.dtbo. If APP occupies almost the entire drive or DATA_PV is missing, recheck the flashing XML. Do not turn the current root partition directly into an LVM PV.

For the first provisioning operation, run from the writable APP system:

sudo lzc-orin provision --dry-run
sudo lzc-orin provision --yes

The first stage prepares the initramfs and boot entries, then reboots automatically. The second stage boots from read-only APP into a temporary provision target and automatically clones APP to ssd_vg/ssd_lv. On success, it reboots again directly into the writable LVM runtime. The second stage has no SSH access; you do not need to log in again to start the clone manually. You can monitor progress through a serial console.

After completion, verify:

sudo lzc-orin provision status
findmnt /
findmnt /factory
findmnt /boot
sudo lvs

/ should be /dev/mapper/ssd_vg-ssd_lv. APP is mounted read-only at /factory, and its /boot is bind-mounted read-only into the running system. If the device still boots from eMMC, select the NVMe boot entry in UEFI.

With a network connection, initialize JetPack, Docker, Compose, and the AI Pod services in the LVM runtime:

sudo lzc-orin all

The flashing image contains the base system and initialization tools. This step installs JetPack runtime software and Docker into the LVM runtime. The default Docker data directory is /ssd/docker. After the user is added to the Docker group, log out and log in again. Packages that provide APP's kernel, DTB, and initrd are placed on hold; do not upgrade the read-only /boot separately from the runtime.

6. Recovery, Storage Expansion, and Troubleshooting

If automatic cloning fails, the device will not reboot automatically. Check the errors through a serial console. If you need the regular recovery environment, reboot, manually select LZC Orin APP recovery in the L4TLauncher menu, and retry from read-only APP:

sudo lzc-orin maintenance --yes

This command clones the LV again. The regular APP recovery environment does not run it automatically.

For a factory reset, first enter LZC Orin APP recovery as well:

sudo lzc-orin reset --dry-run
sudo lzc-orin reset --yes

Reset deletes the LVM runtime data and preserves the APP recovery system. All LVM member drives must be connected. After completion, run sudo lzc-orin all again.

When adding a second, empty NVMe drive, first verify its model, serial number, and device name in the LVM runtime, then run:

lsblk -d -o NAME,SIZE,MODEL,SERIAL
sudo lzc-orin expand-lvm --disk /dev/nvme1n1 --dry-run
sudo lzc-orin expand-lvm --disk /dev/nvme1n1

A nonempty drive requires the explicit flags --force-wipe --yes, which delete its contents. After expansion, the root filesystem depends on all member drives; you cannot simply disconnect any member drive.

Symptom	What to check
The host cannot detect the Recovery USB device	Check the data cable, Recovery port, power supply, and buttons; run lsusb -d 0955: on both the host and in the container
The XML or flashing script is missing	Confirm that you are using catdogai/lzc-x3:jetpack-7.2.1 and that the current directory is /Linux_for_Tegra
Not enough space to generate the image	Check the disk containing the host's Docker data directory and the container's writable layer; reserve space for temporary images
Initial setup fails	Check the twInit.service logs, /boot/twbsp, and the vendor FDT/OVERLAYS boot configuration
SSH is unavailable after provision	The temporary provision target has no SSH; use a serial console to check progress and errors
The device reboots into eMMC	Check the NVMe boot order in UEFI
The LVM root cannot be found	Confirm that all PV members are connected, and check the initramfs and provision logs

Collect the following information on the device:

cat /proc/cmdline
findmnt /
sudo lzc-orin provision status
sudo journalctl -b -u twInit.service --no-pager
sudo journalctl -b -u lzc-orin-provision.service --no-pager