Xavier Cloning

what could have caused writing system.img to stuck at 0% after N+5 successful events?

sudo ./flash.sh -r jetson-xavier mmcblk0p1

after I recreated it with the command below it works again:

sudo ./mksparse  -v --fillpattern=0 /data/image.raw system.img

Does it just halt and not do anthing? Is the system.img the raw version or the sparse version? What is the exact byte size of the file? On the host side, if you monitor “dmesg --follow”, does anything show up at that point?

it used to just halt without progress, but I deleted system.img and recreated it from the raw image with mksparse command shown in the post above and it works.

Have anyone used the tool?
“Testing shows that xfsdump and xfsrestore is much faster than rsync since it handles small files much better. I don’t have extra space to store the dumps but I was able to figure out how to pipe the xfsdump and restore via ssh. For anyone else that’s interested:
On source machine, run:”

xfsdump -J - /dev/mapper/[vg]-[brick] | ssh root@[destination fqdn]  xfsrestore -J - [/path/to/brick]

source: gcluster

Doesn’t that require the source file system to be XFS? You could build an XFS image with very little difficulty, but it isn’t default.

Thank you for pointing out!
It is clear that ext4 and xfs are different.

I have used XFS before, and it is really good. However, I just thought of another issue…the “/boot” directory must be ext4 since U-Boot requires this. That too would make an interesting project…separating “/boot” and “/”.

Back to original topic, we have fixed the cloning issue. Please add below patch to your flash.sh.

diff --git a/scripts/flash.sh b/scripts/flash.sh
index cb5e67a..987ae04 100755
--- a/scripts/flash.sh
+++ b/scripts/flash.sh
@@ -2114,7 +2114,7 @@
 	FLASHARGS+="--cfg  ${localcfgfile} ${BINSARGS} ";
 	FLASHARGS+=" --cmd \"";

In the R32.1 flash.sh (via SDK Manager 4.2 for both a TX2 and Xavier) I see this at two locations:


…lines 2238 and 2338. Only the line at 2238 matches that block. I don’t see this in the block from like 2114 through 2114+6.

Would it be correct on R32.1 flash.sh to update only the line 2238 content? I ask this because we’re apparently looking at different releases.

Hi linuxdev,

This patch is actually for Jetpack4.1. I would check where to add it on rel-32.1.

Could you extend what does the patch do, please?
How does it relates to cloning, but for the fact that flash.sh writes a sparse image from raw and writes is to eMMC? What issues does the flash.sh patch resolve?
How steps for cloning with patched flash.sh should look like for Jetpack 4.1, 4.2?

Per checked the script of rel-32.1. Just need to add this right after BCTARGS.

2238         FLASHARGS+="${BCTARGS} <b>${NV_ARGS}</b>";
2239         FLASHARGS+="--cfg  ${localcfgfile} ${BINSARGS} ";
2240         FLASHARGS+=" --cmd \"";

This is to add “–soft_fuses ” when creating BR_BCT which would make the clone work.

The patch works for us without any problems, thank you.

How can I produce a complete backup of a Xavier (including kernel, kernel_supplements…) and then flash it to another device?

We only support cloning APP partition now. Other partition is still under development.

It seems that the patch allows use of cloning feature for app partition without using raw-to-sparse image method available with dd.
Thank you for the explanation.


I didn’t remember what are needed when trying to dd system image on device.
Current method still generates two files: one is raw and the other one is sparse.

Stop the filesystem [ Xavier] and force it to read only access:

echo u > /proc/sysrq-trigger

CASE I: Transferring the image over ssh to host PC:

dd if=/dev/mmcblk0p1 | ssh user@hostpc dd of=/data/image.raw

Transferring the image over ssh from host PC to Jetson:

ssh user@server dd if=/data/image.raw | dd of=/dev/mmcblk0p1 status=progress

CASE II: Transferring the image over netcat to host PC:
Host PC:

netcat -l -p <port> > your_image_file


sudo dd if=/dev/mmcblk0p1 | netcat <ip_address> <port>

CASE III: preparation of distribution image

cd /home/nvidia/Downloads/Xavier/Linux_for_Tegra/bootloader/ && sudo ./mksparse -v --fillpattern=0 /data/image.raw system.img

and deployment of an image to another device via usb cable

cd /home/nvidia/Downloads/Xavier/Linux_for_Tegra/  && sudo ./flash.sh -r jetson-xavier mmcblk0p1

it seems that the flash.sh clone allows to read filesystem from Xavier from under the recovery mode, while the dd method rather uses booted Xavier’s Operational System to do the raw image.

Hi Andrey1984,
All three cases are for backup the all Xavier disk and then deploy it to another Xavier?
Which case you recommend to backup and deploy the img on another device?

Thank in advanced.

CASE III defines how from raw system.img.raw prepare system.img , and the latter will fit for deployment/distribution to other devices.
Cases I and II are identical in sense either of them will provide system.img.raw image. You may use whatever seems easier to you to create raw image that you will prepare and deploy by the commands listed in the CASE II.