Clone entire TX2

There is no “total disk” clone/flash using recovery mode (there used to be back in the days of the TK1). Life is now complicated by signing of partitions, and so there are still tools for preserving partitions, but those tools require a running system. If the process is not correct, then the Jetson won’t boot and will need to be flashed from scratch.

If you wish to clone all of the regular partitions you can use “dd”. You wouldn’t want to use dd to clone the rootfs while it is being used, but none of the other partitions have any issue with this. If you were booted to an SD card (and thus not using the rootfs on eMMC), then this would copy the entire eMMC:

sudo dd if=/dev/mmcblk0 of=clone.bin bs=512

Even if you use the rootfs and boot normally you could clone the other non-APP (non-rootfs) partitions one at a time, e.g.:

sudo dd if=/dev/mmcblk0p2 of=p2.bin bs=512

Restoring is a different matter. You shouldn’t mix releases of rootfs and different other partitions, but if you have booted system you could for example restore a non-rootfs partition like this example:

sudo dd if=p2.bin of=/dev/mmcblk0p2 bs=512

Now in theory, if you had booted a Jetson to an SD card to avoid using the rootfs from eMMC, and had cloned with “sudo dd if=/dev/mmcblk0 of=clone.bin bs=512”, then you could restore:

sudo dd if=clone.bin of=/dev/mmcblk0 bs=512

Any failure means you have to flash fresh since the system must boot before dd can be used.

I tried to use the tutorial from to perform cloning of Jetson TX2.

$ sudo ./ -r -k APP -G backup.img jetson-tx2 mmcblk0p1
$ sudo cp backup.img.raw bootloader/system.img
$ sudo ./ -r -k APP jetson-tx2 mmcblk0p1

Unfortunately, it didn’t produce the “whole” or “master” image, since it didn’t clone some part of the system, .ie device tree (/dev) and etc as stated by hburaksaruhan. So is there any option to copy the “whole” system of Jetson including its device tree etc as an image? Because when I tried your solution:

sudo dd if=/dev/mmcblk0 of=clone.bin bs=512

it still not copied the “whole” system. I would appreciate any ideas.

That article is for cloning the root filesystem image, not the entire disk. Consider as background that a PC motherboard would have a BIOS, and it is the BIOS which makes it possible for all of the different motherboards to use basically one uniform interface to install an operating system from. Embedded systems do not have a BIOS, and thus that content must be custom for every board. In the case of Jetsons, this is in the form of various partitions in addition to the rootfs. If you were to clone everything, then this is more or less like backing up not only the disk of a PC, but also the BIOS itself. Trying to flash with just the disk, when the BIOS is empty or for another board, will cause failures.

In the past those other partitions were not signed, and you could simply save those partitions through mechanisms such as “dd”. Because of signing you should expect to have to flash those partitions (even if you use a rootfs clone) using the designated tools. If the signature is not correct, then the boot partitions will be rejected.

So long as the release the clone is taken from is used to flash the clone you should be ok and it should work. As soon as you fail either the signing of partitions, or if the version of those other partitions were not from the same release as the rootfs, I would expect failure. There are minor patch releases where I would expect the same rootfs to work across, but those are the exceptions and not the common case.

Thank you for the explanation.

In that case, if I have two Jetson TX2, A and B. If I want to clone, I can only do that by cloning A and restore it to A using dd. But if I want to clone from A and restore it to B alias ghosting, it will be impossible since it has a different signed partition? Is this the correct explanation? Because, when I tried to dd clone from A restore it to B, I got this message:

EXT4-fs error (device mmcblk0p1): ext4_dx_csum_verify:448: inode #131775: comm gdm-session-wor: dir seems corrupt? Run e2fsck -D.
EXT4-fs error (device mmcblk0p1): dx_probe:743: inode #131775: comm gdm-session-wor: Directory index failed checksum
EXT4-fs error (device mmcblk0p1): ext4_iget:4591: inode #140795: comm 90gpg-agent: checksum invalid

The partitions you copied via dd were signed before flashing. The signature will be invalid on a different Jetson. This is why it fails. You can clone the rootfs and use that clone on another Jetson of the same model and release.

So the next question becomes one of whether you have customized the non-rootfs partitions? If not, then a normal flash using the clone will correctly place those other partitions. If it turns out that you have customizations in those other partitions, then you will need to replace the correct image in the flash software (an unsigned image), and then flash with both the alternate non-rootfs images and the rootfs image (which would sign the non-rootfs content during flash).

Is there a particular reason you need to clone the non-rootfs content?

Thank you again for the response.

I have two Jetson TX2s, A and B, with the same model and release. [bold]Both Jetsons[/bold] at the beginning has the capability of [bold]reading analog cameras[/bold] (which its device kernels are inside the /dev right?). Just in case something goes wrong, we want to have a clone of a Jetson with the same capability of reading analog camera. So, I tried to flash [bold]reset Jetson B[/bold] (using SDK Manager) and tried to [bold]clone from A[/bold], so both can have the same capability to read the analog cameras.

These are what I tried to perform cloning (from Host):

$ sudo ./ -r -k APP -G backup.img jetson-tx2 mmcblk0p1
$ sudo cp backup.img.raw bootloader/system.img
$ sudo ./ -r -k APP jetson-tx2 mmcblk0p1

But that one didn’t copy the /dev, instead only the APP rootfs.

So, I tried to perform DD (inside Jetson A):

$ sudo dd if=/dev/mmcblk0 of=clone.bin bs=512

And used this (inside Jetson B):

$ sudo dd if=clone.bin of=/dev/mmcblk0 bs=512

But, I got this message:

EXT4-fs error (device mmcblk0p1): ext4_dx_csum_verify:448: inode #131775: comm gdm-session-wor: dir seems corrupt? Run e2fsck -D.
EXT4-fs error (device mmcblk0p1): dx_probe:743: inode #131775: comm gdm-session-wor: Directory index failed checksum
EXT4-fs error (device mmcblk0p1): ext4_iget:4591: inode #140795: comm 90gpg-agent: checksum invalid

For now, I still haven’t met my goal yet. I’m still wondering [bold]what’s the correct procedure to perform clone[/bold], at least for the device kernel, and if possible the APP rootfs. And I have another question, so are these statements correct?

  1. DD could perform clone on Jetson TK1, but not on Jetson TX2, because Jetson TX2 has signed partition.
  2. There is no way to perform clone for the whole system (I mean all the partitions - not including BIOS, like the ones listed in sudo gdisk -l).

For now, I will try to use these:

$ sudo ./ -r -k kernel-dtb -G backup.img jetson-tx2 mmcblk0p28
$ sudo cp backup.img bootloader/system.img
$ sudo ./ -r -k kernel-dtb jetson-tx2 mmcblk0p28

The other thing that I will try is these:

$ sudo dd if=/dev/mmcblk0p28 of=clone28.bin bs=512
$ sudo dd if=clone28.bin of=/dev/mmcblk0p28 bs=512

Best regards,

  1. Correct, TK1 was not signed. Technically you could copy the signed partition of other releases, but the content would be useless for restoring to a different Jetson.

  2. Correct in the sense that there is no way to perform a useful clone of the non-rootfs partitions. Note though that all of those non-rootfs partitions are part of boot, and yet ignored after boot loads the Linux kernel. Although I phrased that those “other” partitions are used because of a lack of a BIOS, they are intermingled in function and none are specifically a “BIOS”. The “gdisk -l” could show binary partitions, but even PC boot uses more than individual partitions (a PC boot disk will have content not visible as a partition, and may use other partitions during boot, but partitions do not contain everything used for PC boot). Either way, other than customization of boot properties, the rootfs will contain the entire operating system. The only part which is “normally” modified by end users would be the kernel or device tree.

If kernel and device tree are combined into the flash software (the “driver package”) on the PC, then any flash will contain those updates. If you also replace the system.img with a clone of the rootfs, then you will correctly flash all of these modifications to the next Jetson you flash. The process will properly sign partitions. If you didn’t modify the kernel or device tree, then you will get 100% cloning by simply telling the flash to reuse the rootfs which you provided from the clone (caveat: the JetPack/SDKM release should match the release which was used on the system you cloned).


Beware that you cannot clone (at least in a useful way) the non-rootfs partitions. This is the job of the “driver package” (which JetPack/SDK Manager downloads and is a front end to). While flashing the rootfs from the correct version of JetPack/SDKM/L4T those other partitions will be correctly added (the rootfs can be from a clone).

So far as the rootfs goes you definitely don’t want to clone all files since not all files are actual files. Many files, including those in “/dev”, “/sys”, and “/proc”, do not exist on the disk/eMMC. Those files are actually drivers in RAM programmed to have a file interface.

As an example, consider if a naive file backup program were to create a file named “/backup/dev/random”, and tried to back up by coping all content inside of the real “/dev/random” to “/backup/dev/random”. The file will produce data until the end of time. Similar for “/dev/zero”. Backing up files requires a special tool, e.g., “rsync”, which understands files versus pseudo-files.

Note that if you dd a corrupt copy of a partition, then you will get a corrupt copy. If you use dd on a filesystem while it is changing and being used, then most likely you will get a corrupt (or at least incorrect) clone. If temp files or anything else changes on the filesystem while you use dd to copy it, expect errors. The clone process gets around this (if the filesystem is not corrupt) by not using the rootfs in recovery mode (there is a mini-operating system with minimal function while in recovery mode, and that operating system does not depend on eMMC).

The process of flashing provides a fresh install of all of those non-rootfs partitions. So long as you use the same release you can consider this a restore to the same version you had originally. Boot content modifications, such as a changed kernel and device tree, would need to be considered separately.

This process you mentioned is correct if you want the pristine non-rootfs partitions along with a clone of the original rootfs (warning, I amended this since rootfs is mmcblk0p1…I failed to read this closely enough):

$ sudo ./ -r <s>-k kernel-dtb</s><b>-k APP</b> -G backup.img jetson-tx2 <s>mmcblk0p28</s>mmcblk0<b>p1</b>
$ sudo cp backup.img bootloader/system.img
$ sudo ./ -r <s>-k kernel-dtb</s> jetson-tx2 <s>mmcblk0p28</s>mmcblk0<b>p1</b>

EDIT: The kernel-dtb can be flashed as originally named, but won’t be cloned in that manner since it is signed. One would add the unsigned dtb to the right place in the “Linux_for_Tegra/” tree of the driver package on the host PC prior to flash, or you would flash the modified (not cloned) device tree as you first mentioned. The point is that you can flash the dtb using the tools, but you cannot clone in a useful way with those tools. Only the rootfs can be cloned in a useful way since it is not signed. If you want more information on device trees though, just ask.

Note: Clone will also produce “backup.img.raw”. This too could be used in place of “bootloader/system.img”. The result will be the same, except that the “backup.img.raw” is much larger and is very useful for examining, modifying, so on (the smaller file is of use because it flashes faster and takes less disk space on the host PC…when it expands the two are an exact match).

Note: You can fsck.ext4 the loopback mounted backup.img.raw. The “backup.img” can only be used for flash. You can create a new “backup.img” from the “backup.img.raw” using the “bootloader/mksparse” program (with NULL byte fill pattern, the default of mksparse).

Hi, linuxdev. Thank you again for the great and detailed explanation.

Best regards,

Btw, I did just make some edits to #27. The part with “…if you want the pristine non-rootfs partitions…” I edited since I was only thinking of rootfs and not kernel-dtb at the time I did the copy/paste. The gist is that you can add a modified kernel-dtb the way you mentioned, but cannot necessarily use a cloned copy of kernel-dtb on a different Jetson since it is signed. FYI, “system.img” is always the rootfs and can only be replaced by a clone of a rootfs, never a clone from a kernel-dtb.