Hi NVIDIA Team,
We are encountering a specific flashing error when attempting to apply a cloned image to new units of the same hardware model.
Problem Description:
- When flashing the same hardware model, some units succeed while others fail.
- The cloned image itself appears to be valid because it works on a portion of the machines.
- The “failed” units can be successfully flashed using the standard base image (non-cloned).
Error Log:
[ 5.7321 ] 54 reserved 129536 129919
[ 5.7321 ] 55 worm 129920 130303
[ 5.7321 ] 56 BCT-boot-chain_backup 130304 130431
[ 5.7321 ] 57 reserved_partition 130432 130559
[ 5.7321 ] 58 secondary_gpt_backup 130560 130687
[ 5.7321 ] 59 B_VER 130688 130815
[ 5.7322 ] 60 A_VER 130816 130943
[ 5.7322 ] End sector for APP, expected at: 122314718, actual: 0
[ 5.7322 ]
Error: Return value 4
Command tegraparser_v2 --storageinfo storage_info.bin --generategpt --pt flash.xml.bin
Failed flashing generic.
Commands Used:
- To Clone the Image:
sudo ./flash.sh -r -k APP -G backup_system.img jetson-agx-orin-cb_stt31jc mmcblk0p1
- To Flash the Cloned Image:
time sudo bash ./flash.sh -r -S 62024003584 jetson-agx-orin-cb_stt31jc mmcblk0p1
- To Flash the Base Image (Successful on all units):
time sudo ROOTFS_RETRY_COUNT_MAX=3 bash ./flash.sh jetson-agx-orin-cb_stt31jc mmcblk0p1
Any suggestions or insights would be greatly appreciated. Thanks!
*** Please note that this reply is generated by LLM automatically ***
The issue you’re encountering with flashing cloned images to new units of the same hardware model on the Jetson AGX Orin is intriguing. I’ll provide some insights and suggestions to help you troubleshoot and resolve the problem.
Understanding the issue
It’s essential to understand that the cloned image is valid and works on some machines, but not all. This suggests that the issue might not be with the image itself, but rather with the specific hardware or configuration of the failed units.
Possible causes
- Hardware variations: Although the units are of the same hardware model, there might be slight variations in the hardware configuration, such as different revisions of the board or components. These variations could cause the cloned image to fail on some units.
- EEPROM or Chip values: The EEPROM or Chip values on the failed units might be different from those on the units that successfully flashed. These values are used to identify the hardware and configure the system accordingly.
- Bootloader or UEFI configuration: The bootloader or UEFI configuration on the failed units might be different from those on the units that successfully flashed. This could prevent the cloned image from booting correctly.
Troubleshooting steps
- Verify the hardware configuration: Double-check the hardware configuration of the failed units to ensure they match the configuration of the units that successfully flashed.
- Check EEPROM or Chip values: Use the
BOARDID, BOARDSKU, FAB, BOARDREV, CHIP_SKU, RAMCODE, and FUSELEVEL environment variables to retrieve the EEPROM or Chip values from the failed units. Compare these values with those from the units that successfully flashed.
- Inspect the bootloader or UEFI configuration: Use tools like
flash.sh or nvboot to inspect the bootloader or UEFI configuration on the failed units. Compare the configuration with that on the units that successfully flashed.
- Try flashing with
--no-flash option: Use the --no-flash option with flash.sh to generate a flash image without actually flashing the device. This can help you determine if the issue is with the flashing process or the image itself.
Workaround
If the above steps don’t resolve the issue, you can try using the flash.sh command with the --no-flash option to generate a flash image, and then manually flash the device using the nvboot tool. This can help you bypass any issues with the cloning process.
Example command
$ sudo BOARDID=3701 BOARDSKU=0000 FAB=500 BOARDREV=500 CHIP_SKU=D0 RAMCODE=0 FUSELEVEL=fuselevel_production ./flash.sh --no-flash jetson-agx-orin-devkit mmcblk0p1
Replace the BOARDID, BOARDSKU, FAB, BOARDREV, CHIP_SKU, RAMCODE, and FUSELEVEL values with those retrieved from the failed units.
By following these steps and suggestions, you should be able to identify and resolve the issue with flashing cloned images to new units of the same hardware model on the Jetson AGX Orin.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
Hi,
We have observed a discrepancy in the total disk size between two different 64GB Jetson Orin modules:
- Module A: Disk /dev/mmcblk0: 59.22 GiB (124,190,720 sectors)
- Module B: Disk /dev/mmcblk0: 58.32 GiB (122,314,752 sectors)
We cloned a system.img from Module A, but we are encountering failures when attempting to flash it onto Module B. We suspect this is because the image from Module A is physically larger than the available capacity on Module B.
What is the recommended workflow to create a “golden image” that is compatible with both modules? Should we be explicitly shrinking the APP partition or modifying the partition configuration XML to account for the smallest possible sector count?
Any guidance would be appreciated.
Have you tried this method?
Linux_for_Tegra/tools/backup_restore/README_backup_restore.txt
Backup - restore tool for Jetson
README
************************************************************************
The NVIDIA Jetson Linux package provides a tool to create a backup image and restore
a Jetson device using the backup image.
Requirements:
- Automount of new external storage devices must be temporarily disabled during
backing up and restoring. On most distributions of Debian-based Linux, you can
do this using the following command:
$ systemctl stop udisks2.service
- Run this script to install the right dependencies:
$ sudo tools/l4t_flash_prerequisites.sh # For Debian-based Linux
- This tool requires the host to have "nfs-kernel-server" service running:
$ sudo service nfs-kernel-server start
Workflow 1: To create a backup image to host storage
Steps:
- Make sure you have only ONE Jetson device in recovery mode plugged in the host
- Run this command from the Linux_for_Tegra folder:
$ sudo ./tools/backup_restore/l4t_backup_restore.sh [ -e <devname> ] -b <board-name>
Where <board-name> is the same value as is used in the flash.sh command.
<devname> (optional) indicates the device to be backed up.
Use ":" to separate devices when you specify multiple devices.
For example, use "-e mmcblk0:nvme0n1" to back up both mmcblk0 and nvme0n1.
(See more details in the table of device names in the "Introduction"
topic of Jetson Linux Developer Guide).
- If this command completes successfully, a backup image is stored in
Linux_for_Tegra/tools/backup_restore/images.
Workflow 2: To restore a Jetson using a backup image
Thank you for your response. I will test this method once we receive the new batch of modules. If successful, we will keep this as our primary backup solution should no other direct fix be available.
We have identified that the root cause is a PCN for modules shipped after January 2025, which resulted in a change to the eMMC hardware and its reported capacity.
Our goal is to maintain a single “Golden Image” for all units. Maintaining two separate sets of cloned images based on hardware revision would significantly increase our long-term maintenance overhead for products already in the field
Is there a recommended way to force the system.img or the partition layout to be compatible with the smaller sector count by default, ensuring that a single image can be deployed across both pre-PCN and post-PCN hardware without failure?
Best regards
This could work. Create golden backup from Module B or from any module flashed with Module-B-sized layout.
Restore to Module B: exact fit.
Restore to Module A: works, with about 916 MiB unused.
Here’s a script that would need testing and perhaps corrections on A modules to expand APP partition to end of mmc.
#!/usr/bin/env bash
# Grows the APP (rootfs) partition to the end of the eMMC on Jetson AGX Orin.
# Usage: sudo EXPECTED_DISK=/dev/mmcblk0 ./grow-app.sh
set -euo pipefail
APP_LABEL="${APP_LABEL:-APP}"
EXPECTED_DISK="${EXPECTED_DISK:-/dev/mmcblk0}"
[ "$(id -u)" -eq 0 ] || { echo "Run as root: sudo $0"; exit 1; }
for cmd in sgdisk growpart partprobe resize2fs blkid lsblk blockdev; do
command -v "$cmd" &>/dev/null || { echo "Missing: $cmd"; exit 1; }
done
APP_PART="$(readlink -f "/dev/disk/by-partlabel/${APP_LABEL}")" \
|| { echo "Partition label '${APP_LABEL}' not found"; exit 1; }
DISK="/dev/$(lsblk -no PKNAME "$APP_PART" | head -1)"
[ "$DISK" = "$EXPECTED_DISK" ] \
|| { echo "APP is on $DISK, expected $EXPECTED_DISK — aborting"; exit 1; }
PARTNUM="$(lsblk -no PARTN "$APP_PART" | head -1)"
FSTYPE="$(blkid -s TYPE -o value "$APP_PART")"
[ "$FSTYPE" = "ext4" ] \
|| { echo "Expected ext4, got '$FSTYPE' — aborting"; exit 1; }
echo "APP: $APP_PART | disk: $DISK | part: $PARTNUM | fs: $FSTYPE"
lsblk -o NAME,SIZE,FSTYPE,PARTLABEL "$DISK"
read -r -p "Grow APP to end of $DISK? [yes/N] " ans
[[ "$ans" == "yes" ]] || { echo "Aborted."; exit 1; }
# Relocate backup GPT — mandatory when disk was expanded after provisioning
sgdisk -e "$DISK"
partprobe "$DISK" && sleep 2
growpart "$DISK" "$PARTNUM"
partprobe "$DISK" && sleep 2
resize2fs "$APP_PART"
echo "Done."
lsblk -o NAME,SIZE,FSTYPE,PARTLABEL,MOUNTPOINTS "$DISK"
Thank you for your help. I will carry out the experiments as soon as I receive the new batch of modules. Much appreciated