After we setup one Jetson TX2, installed a lot of extra libraries and did a lot of configrations, we don’t want to setup it one by one in production since that usually takes a lot of time.
Is there any way to copy/flash the configured Jetson TX2 system to a new Jetson TX2 board?
You can clone the Jetson you are interested in and use that for the image. Some procedures depend on release, and so without knowing more details some specifics cannot be answered. However, this will be basically correct for cloning on several recent releases:
https://devtalk.nvidia.com/default/topic/1000105/jetson-tx2/tx2-cloning/
On R32.1 (see “head -n 1 /etc/nv_tegra_release”) you probably need this patch to flash.sh:
https://devtalk.nvidia.com/default/topic/1048747/jetson-agx-xavier/cloning-xavier-with-jetpack-4-2/post/5322540/#5322540
If you’ve ever flashed a release, then flash.sh will be in the “Linux_for_Tegra/” directory. Always flash with the same release the clone is from.
Beware a clone can also copy some hardware specific files. Most of the time this won’t happen, and perhaps the biggest issues are:
If you clone you will get both a raw “backup.img.raw” file and a sparse “backup.img” file. I throw away the sparse file and use only the raw file. Either one, when placed in “Linux_for_Tegra/bootloader/system.img” will flash, but raw files take longer. Raw files can be turned into sparse files if you wish using the mksparse utility (fill pattern null bytes). Raw files can be loopback mounted, edited, examined, updated from an original to a host via rsync, so on.
The flash.sh option “-r” prevents a new “bootloader/system.img” from being produced. An existing image would be used if it is there. The clone can be used to replace system.img, but be sure to save a safe backup since doing things wrong could destroy the clone. This is a very large file and it will take time to copy it anywhere.
You could loopback mount the image, e.g., “sudo mount -o loop ./backup.img.raw /mnt” (puts on “/mnt”). If you were to mount the image on “Linux_for_Tegra/rootfs/”, then this would be used instead of the sample rootfs. You would need to be careful if not using command line since JetPack/SDK Manager might update the location with the sample rootfs…which would overwrite your clone. Using on “rootfs/” need to be read-write since “rootfs/boot/” content is overwritten. To that extent, if your “/boot” content is not custom, this wouldn’t be an issue, but if the kernel is custom, then this would overwrite your kernel. Then a new system.img would be generated based on your loopback mount to “rootfs/”. I suggest just using the “-r” option.
Hi, I have modified TX2’s terga_fan behavior in OS kernel. When I use flash.sh to flash the back.img to a new TX2 board, the kernel’s modification was gone, and other things were right. I don’t know why how it comes.
Could I mount the TX2 to a Linux computer, and use “dd if=… of=…” for system copy?
Some modifications may be through the device tree, and if so, a clone will miss this. If the modification in fan behavior did not involve device tree, then clone followed by restore with the clone should succeed.
Clone from recovery mode is a guaranteed way of getting the filesystem. In the case of dd from a running system you must guarantee the system is read-only on the hard disk (eMMC). If there was a failure, then probably it was the restore operation. One way this would happen is that if you’ve copied your clone to “bootloader/system.img” on the host PC prior to restoring, and then fail to use the “-r” option, then your image gets overwritten.
Device tree is actually in a partition and is not cloned. This is actually signed during flash, and so you put the unsigned version in the proper place prior to flash, and then you can tell it to flash only the device tree. I’m not sure to what extent dd would work since I don’t know what the requirements are for the signature. You will probably want to provide more information on what you actually modified.