I search the forum and this is the closest one to me:
“it turns out i had a quota limitation on my work dir and i think this caused is (although i worked in folder without this limitation). after using a different server to flash from all passed well”
I have enough space in my root drive. Does he mentioning RAM size in my host machine? I have 32 GB in my host machine.
What did I miss?
Runtime environment:
Host computer OS: Ubuntu 18.04
Nvidia hardware: Orin AGX 32 GB
SDK Manager version JetPack 5.0.2 (rev.2)
@DaveYYY, Thanks for updated document and suggestion of removing one parameter in command line. I modified the file to 0x808, and tried these two commands (separately):
I realized “r” option reusing the “system.img” (may be still the one I copied in “bootloader” folder).
To make sure the IMG file I want to use, so I did again with: sudo ./flash.sh --no-flash --no-systemming jetson-agx-orin-devkit mmcblk0p1
and then sudo ./flash.sh -k APP --image /home/ccho/Downloads/d-004.img jetson-agx-orin-devkit mmcblk0p1
Are you sure all these devices have exactly the same disk size?
Maybe they are of different SKUs and are using different eMMC chips, which makes the cloned image incompatible.
@DaveYYY Thanks for continous support. I compared the host computer OS and Jetpack version. The Ubuntu 22 OS used on the Image file generation, so I am using Ubuntu 22 OS. Now I am having this error
:
Can you please run sudo fdisk -l on the device where the image is generated, and where the image is restored? I believe they are of different size because we have multiple sources of the eMMC chip.
Anyway, you should use the backup/restore tool located in Linux_for_Tegra/tools/backup_restore instead. flash.sh clones the image with dd, and everything including the partition table is copied 1:1, whereas the backup/restore tool will format all partitions again, and use tar to extract the image, so disk size should not matter under such usecases.
Regarding, sudo fdisk -l at the host computer, it looks like not showing connected Orin device.
We tried to back and restore, but we failed in the both machines (002, 003). Here are errors (different in each board)
004 → 002
Error message: “vrestore_partitions.sh: Use the default nvpartitionmap.txt as the index file.
partx: specified range <1:0> does not make sense”
002 labeled: Model: P3737, 699-13737-0000-500 B. I also believe it is 32 GB.
004 (backup) → 003 (restore)
Error message: “nvrestore_partitions.sh: You are trying to flash images from a board model that does not
match the current board you’re flashing onto.” (entire terminal output is at “error_restore_d_003.txt” for reference)
003 labeled Model: P3737, 699-13737-0000-500 D. I believe that she is 32 GB.
When I see the TXT file (“nvpartitonmap.txt”) from 004, it looks like D-004 looks like “board_spec,3701-500-0000-K.0-1-1-jetson-agx-orin-devkit-”
As you mentioned, hardware are actually different (3737 D, B vs. 3701 K)
@DaveYYY
Thanks for clarification. To run fdiskat dev board, I have to flush clean them (currently not able to log in because cloning hanging).
Yes, the post on January 23 was by using the backup/restore tool at “Linux_for_Tegra/tools/backup_restore” folder. I enclosed entire Terminal output of unit 003 of the command line: error_restore_d_003.txt (70.1 KB)
Regarding the backup/restore tool, do you mean, I could clone the board using the tool, even there is size difference between them?
# This block will check to make sure the model of the target board matches the
# model of the board the images came from.
for value in $(grep -v -e '(^ *$|^#)' < "${FILE_NAME}"); do
declare -a FIELDS
for part in {1..6}; do
FIELDS[part]=$(echo "$value" | awk -F, -v part=${part} '{print $part}')
done
if [ "${FIELDS[1]}" = 'board_spec' ]; then
set_board_spec
if [[ "${FIELDS[2]}" == "${BOARD_SPEC}" ]]; then
BOARD_MATCH=true
fi
fi
done
if [ ${BOARD_MATCH} = false ]; then
echo "${SCRIPT_NAME}: You are trying to flash images from a board model that does not"
echo "match the current board you're flashing onto."
exit 1
fi
Comment out this section in Linux_for_Tegra/tools/backup_restore/nvrestore_partitions.sh and try again. It’s not guaranteed to work but you may give it a try.
