Xavier Cloning

Autonomous Machines Jetson & Embedded Systems Jetson AGX Xavier
41

OK,
So After i did CASE || :
On the Host

netcat -l -p <port> > testimage.raw

On the Jetson:

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

And now i have the file named “testimage.raw”

  1. Where i running the next command on the host or on the Jetson?
cd /home/nvidia/Downloads/Xavier/Linux_for_Tegra/bootloader/ && sudo ./mksparse -v --fillpattern=0 ~/testimage.raw system.img
  1. I need to connect the Jetson to the host and then to run this command (in recovery mode)?
cd /home/nvidia/Downloads/Xavier/Linux_for_Tegra/  && sudo ./flash.sh -r jetson-xavier mmcblk0p1

By the way when i connect the Jetson to the computer i see in “lsusb”
“Nvidia Xavier” It’s OK?

Thank you very much for your help!

42

Q1. Where i running the next command on the host or on the Jetson?
A: “on the host”
Q2. I need to connect the Jetson to the host and then to run this command (in recovery mode)?
A: “exactly”

43

Hi Andrey1984.
Thank you for your help.

It’s Work!
in the first time I didn’t

echo u > /proc/sysrq-trigger

after i did the command above everything work good!

44

.

45

@agforums: could you list steps to reproduce your issue, please?
You needed to write with flash.sh -r the resulting file [system.img] that you should have got from the raw file processing with the mksparse command execution.
However, if it is what you did you may try again verifying that you are using the -resulting-system.img-file-rather-than-the-default-one that literally means that you might need to substitute the default system.img at the default location at Host PC with the file that you got after applying the mksparse sequence.
Moreover,you may need to verify as well that you has got the -complete- image of the original source, as while it is quite intuitive when using dd-of-to-file that terminates on execution it may be less obvious when to stop the netcat process as it doesn’t terminate on completion
And the magic key to halt the disk system. Unless you use it - it won’t work and it could result in the issue as you described.

46

I am creating a sparseimage
1.

dd if=/dev/mmcblk0 of=/path/testimage.raw

and THEN mksparse

./mksparse -v --fillpattern=0 ~/testimage.raw system.img

and then flashing

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

Q: Is there a difference if I use /dev/mmcblk0p1 in the step 1 or just the whole /dev/mmcblk0?
Q2: how to explicitly specify path to system.img that will need to be flashed? is there any argument for it?
Thanks

47

The actual rootfs is just mmcblk0p1. You can use that directly with mksparse and flash. The rest of the partitions (if you were to clone the entire mmcblk0) are binary data and should not be part of the mksparse, nor part of the rootfs image. That said, you can use loopback to provide all of “mmcblk0” on a host PC, and then access “mmcblk0p1” as a partition of the loopback disk (or dd can go to the right offset of the image and extract individual partitions…but I wouldn’t recommend that). It is far easier and less error prone to use dd on every partition individually than it is to clone all of mmcblk0 and then separate out components.

If you have file on the host PC, “Linux_for_Tegra/bootloader/system.img”, then this will be used automatically for the rootfs partition. It doesn’t matter if that file is raw or sparse, it will still work. If you forget to use the “-r” option to flash.sh, then your image will end up being overwritten. This file becomes a bit-for-bit exact image placed into “mmcblk0p1”.

Note that if the size of the system.img is not the default size, then you might need to manually set the size via the “-S ” option.

As an example, if an image is 30064771072 bytes, then dividing this by 1024 three times shows this to be 28GiB (the raw image size excluding any mksparse):

sudo ./flash.sh -S 28GiB -r jetson-xavier mmcblk0p1
48

thank you for following up!

converting entire emmc image mmcblk0 to one partition image:

sudo losetup --partscan --find --show /home/nvidia/Downloads/full_image.raw

#sudo mount /dev/loop4p1 /mnt

dd if=/dev/loop4p1 of=/home/nvidia/system.img.raw

running mksparse on resulting single partition raw image:

/mksparse -v --fillpattern=0 ~/system.img.raw system.img

flashing

sudo ./flash.sh -S 28GiB -r jetson-xavier mmcblk0p1
49

so until now, clone system img for Xavier in recovery mode , is available or not ?
I have a device that cannot bootup normally now, but there is important file I need it

by the way, is there any method that I can bakcup the important file when the system cannot bootup normally

50

It is easy to clone the rootfs in recovery mode, it just takes a lot of time and disk space on the host Linux PC. On the more current releases, if the Xavier is in recovery mode, and the USB-C cable is connected to the host PC, then from the “Linux_for_Tegra/” directory:

sudo ./flash.sh -r -k APP -G my_backup.img jetson-xavier mmcblk0p1

This would produce a “sparse” backup, “my_backup.img”, and a “raw” backup, “my_backup.img.raw”. Normally I just throw away the sparse image since it has no ability to be examined, viewed or edited, and use only the “raw” image. This raw image is loopback mountable. The raw image size alone will be around 30GB in size, the sparse image depends on how full the filesystem is, but on average it would be about a 2-3GB image right after an install.

Copying 30GB takes significant time.

51

Any News on that?

52

Thanks for the explanation.
So as far as I understand, this action clones the entire Xavier Image (including my own installations for example: a newer version of opencv in “/usr/local”)?
Or its just clones the Home directory and other Data I saved on the machine?

53

I am attempting to use this and I get the message:

###############################################################################

L4T BSP Information:

R32 , REVISION: 3.1

###############################################################################

Target Board Information:

Name: jetson-xavier, Board Family: t186ref, SoC: Tegra 194,

OpMode: production, Boot Authentication: NS,

###############################################################################
copying soft_fuses(/home/test/nvidia/nvidia_sdk/JetPack_4.3_Linux_P2888-0060/Linux_for_Tegra/bootloader/t186ref/BCT/tegra194-mb1-soft-fuses-l4t.cfg)… done.
./tegraflash.py --chip 0x19 --applet “/home/test/nvidia/nvidia_sdk/JetPack_4.3_Linux_P2888-0060/Linux_for_Tegra/bootloader/mb1_t194_prod.bin” --skipuid --soft_fuses tegra194-mb1-soft-fuses-l4t.cfg --bins “mb2_applet nvtboot_applet_t194.bin” --cmd “dump eeprom boardinfo cvm.bin;reboot recovery”
/usr/bin/env: ‘python’: No such file or directory
Reading board information failed.

Has this been answered in another post?

54

The disk (eMMC) has many partitions, and only one is the root file system (rootfs). Clone is only of the rootfs. “rootfs” does include “/home” in the default layout. Most of the CUDA related content is only in “/usr/local”, and a clone does include this if you are just using eMMC (a clone contains everything in “/” of the rootfs partition, and of course being a tree structure, this means all subdirectories of that particular disk).

A clone is a great backup tool if you keep the raw clone (a clone will produce both a “raw” backup.img.raw, and also a “sparse” backup.img…only the raw file can be examined and manipulated, but both can be used for flash…sparse is a faster flash at the cost of not being useful for any other purpose).

Booting an entire system from an external drive has many details to be careful with. Copying only “/usr/local/” content to the extra drive, and then mounting at “/usr/local/”, is very simple/quick and you can afford to make mistakes.

You can do something similar with “/home/”, just like “/usr/local/”, but then you mount the external hard drive partition to “/home” instead of “/usr/local”. You could split your hard disk into two partitions, and mount one on each.

Two separate partitions can be a bit inflexible, but you could instead use a volume manager to use all space on the external disk, and then mount a “/home” and a “/usr/local” volume (a logical partition) instead of discrete partitions. Volumes can be changed dynamically (though not while being used…you have to take special steps to safely manipulate volumes) to split up how they share space, and new partitions can even be created with spare space. Basically a volume manager marks the disk as a “pool of space” instead of marking specific layouts.

Anything volume manager is standard across most Linux distributions (unless you are booting to that…for “/home” and “/usr/local”, this is not being booted to). See any of these (lots of documentation available on the internet):
https://ubuntu.com/search?q=lvm
https://www.ostechnix.com/linux-basics-lvm-logical-volume-manager-tutorial/
https://www.howtoforge.com/linux_lvm
https://www.digitalocean.com/community/tutorials/an-introduction-to-lvm-concepts-terminology-and-operations

Keep in mind that volume managers are not simple to resize (well, relative to just having partitions). You would need to learn things about this. In some cases actual partitions will be resizeable with tools like “gparted”.

Simpler tends to be better. Tools under “/usr/local” tend to be large, but will not necessarily change a lot. “/home” content can have projects and change a lot. Find out what you currently have for total content at each:

sudo du -h -s /home
sudo du -h -s /usr/local

Copying content from that onto an external drive would at minimum require that amount, and can free that much from the eMMC if you choose to do so. It is very important to know what it is you want to accomplish and what kind of flexibility you need.

1 Like
55

You are missing the correct python release:

Try again after the following on your host PC:

sudo apt update
sudo apt --fix-broken install
sudo apt-get install libgconf-2-4 libcanberra-gtk-module
sudo apt-get install python

Note that there was a transition on that release between python 2 and python 3. Just “python” will give the correct version.

1 Like
56

Thanks for the (very) detailed response.
I am using the command “sudo ./flash.sh -r -k APP -G my_backup.img jetson-xavier mmcblk0p1” (flush script contains the patch for Jetson OS rev 4.2). It seems to work OK…
My question is: since i’m adding “-k APP” to the command - does it means that I clone only Data or also installations I have made…kinda like “image” in windows ?

57

This clones only the root partition. That’s everything you can see with “ls” on the running system. This is the part which any operating system backs up (everything in “/” and every subdirectory of “/” for 100% of what is on eMMC). The rest is related to booting.

Note that having the other content won’t help, only rootfs really matters. During a flash the content to boot will always be present. I suppose there might be exceptions if you are custom programming the bootloader itself. Are you customizing the bootloader prior to the operating system loading, e.g., for custom hardware? If not, then the rootfs is all you need to worry about.

NOTE: Windows often has a hidden partition which you might consider similar to the other partitions. That partition is only used for boot or recovery. The “image” is typically what Windows would show as “C:\” and all content on that disk.

1 Like
58

Thanks a lot.
I’ve managed to clone and flush it and it seems to be fine. But when I wanted to flush it to a different Jetson (duplicate) - the flush was “Successful” but the Jetson was stuck in boot and couldn’t turn on OK

59

What release is on the original system which is a clone source (see “head -n 1 /etc/nv_tegra_release”)? This release will match a particular JetPack/SDKM release, and that release must be used when flashing to the second system.

To see a list of L4T releases which might be visible in the “head -n 1 /etc/nv_tegra_release” result, go here (you probably have to go there, log in, and click the link again):
https://developer.nvidia.com/linux-tegra

To see a list of JetPack/SDKM releases, and to know which L4T release is used with that JetPack/SDKM, go here:
https://developer.nvidia.com/embedded/jetpack-archive

Was the tool used to flash the clone onto the second Xavier the same version as the one creating that first system (mixing releases will likely cause failures)?

Note that creating the clone file itself (extracting a clone from a Jetson) does not much care about release version since it is only a bit-for-bit exact copy of the rootfs. It is only during the operation of putting the clone onto a Jetson where release version matters. I’d like to verify these match.

There are some cases (which I doubt would prevent boot) where a clone might need another edit before use. An example would be that some people have customized networking through the identification of an ethernet port’s MAC address, and if the address is different on the new Jetson, then that ethernet rule would fail. This is just an example, and I don’t know of anything which would actually prevent boot in simple cases.

One possibility I can think of is that sometimes and updated device tree or kernel which created an original install (such as a board support package for a third party carrier board vendor) would need to be matched before flashing a clone onto another Jetson since some of that content may end up in non-rootfs partitions.

One other thought: If your rootfs was a default size in both cases, then rootfs can simply be cloned and flashed without any adjustment. In a case where the rootfs clone is a non-default size, then it might imply a need to add a flash parameter to specify the correct size. Is your rootfs partition size in any way custom?

1 Like
60

The source (kernel) image contained a camera driver (LI-AR0231) I have installed . could that be the reason that the cloned Xavier didn’t boot up after the clone? Its kernel did not contain that installation…

If that is the reason then what is the purpose of the whole process? don’d they have a better way to clone?
What if I use ddrescue for the whole mmcblk0p1 partition? would that work?