TX2 Cloning: What is really inside the image ?

Hi there !

Just a quick question. I need to store multiple versions of jetson’s Images.

I am using elinux’s tutorial: https://elinux.org/Jetson/TX2_Cloning

When I clone a jetson, It creates a huge 30-31Gb file. What does that file contains? Can I simply store this file in a hard drive and name it whatever and move it later to flash on another version ? or do I need other files that are present in the Linux_For_Tegra folder ?


The argument to the back up is mmcblk0p1 which means “the main Linux file system partition” but not everything on the disk.

To clone the entire disk, you’ll want to do a full dump of mmcblk0 using a tool like dd – it won’t be much bigger, but a little bigger, and contain everything on the disk.
Restoring such a backup may be difficult if the system doesn’t boot, though!
(To restore, you’d want to read the backed-up image, and write it back out the to full mmacblk0 device.)

Alright, last question and I’ll accept your answer, I promise

When I do a backup/restore using the standard way, with mmcblk0, what is not copied ? Is it anything important ? Or is everything part of / copied ? Moreover, can I safely backup images from one board, keep that 30Gb file and name it like v1 then do the same for another board, name it v2 and restore whichever version I want ?

Evidently OS is contained within the image.
I see nothing that prevents from creating images of mmcblk0 with dd.
mmcblk0 contains all partitions like mmcblk0p1 etc.
How to restore from the images created? That seems to be a separate question, though discussed at the forum, as far as I am concerned.
For example if a Jetson is booted from SSH/SATA emmc can be imported from image v1 via dd.
I would look for a way to import a custom image with flash.sh somehow.
Reference: https://elinux.org/Jetson/TX2_Cloning

With mmcblk0p1, everything under the / file system is copied, but not the separate boot loader (uboot) and other support partitions.

Yes, you should be able to restore whichever version you want.

If you want a smaller image, you can run something like this from the host:

ssh jetson 'find / -xdev -depth -print | cpio -o' | gzip > my-backup.cpio.gz

This will write a CPIO archive of the files, without all of the blank space on the system.

To restore, you’d basically unpack the image on top of an existing root. (That may leave some files existing that aren’t in the backup though – to remove them requires a little more scripting.)

You will see many partitions listed if you run “sudo gdisk -l /dev/mmcblk0”. The “APP” GPT label (mmcblk0p1) is the rootfs and will be almost the entire disk…the rest will contain a number of partitions supporting boot, e.g., device tree and U-Boot. Cloning gives you both a loopback mountable 30GB “.raw” partition copy, plus the (essentially) compressed non-raw sparse image.

The cloned image can be loopback mounted, files copied, edited, and restored with edits back into the APP partition. The sparse image is much faster to restore, but cannot be mounted or edited. I throw this one out and save a “bzip2 -9” compressed version of the raw image.

The clone is an exact bit-for-bit copy of the APP partition…this is exactly what you’d get with a dd copy of the partition if the partition is not mounted during the dd (this is the trick of backing up any rootfs…copying it while it is changing is problematic and typically done under a rescue disk boot…clone is essentially a rescue disk for some limited operations).

The rootfs may have some dependencies on boot environment. Thus the other smaller partitions from one release of L4TG may not mix with a given rootfs. If you cloned from an R28.1 Jetson, then you can be guaranteed to restore to an R28.1 Jetson will work. If you cloned from an R28.1 Jetson, then you can bet there will be unknown problems restoring into an R28.2 Jetson…those other partitions will no longer match as a unified release revision. This is not useless because you can still copy the loopback mounted clone’s non-boot information (say for “/home” or for “/usr/local”) into the “rootfs/” subdirectory and each flash will get those updates even with the newer revision.

another workaround could be to use rsync for making a backup and restore