I have one Xavier which I’ve set up with our entire software stack, and would now like to duplicate that software configuration across multiple other Xaviers (mixture of OEM modules and dev kits). Setup from scratch would likely take a day or so per Xavier, so I’d like to avoid that option. From what I’ve read in other threads on this forum, it should be possible to dump the EMMC on one Xavier and flash it to another. Since the EMMC is only 32GB, I imagine this would be significantly faster than a from-scratch setup, and much less error prone.
Unfortunately, I’m not too familiar with the internals of JetPack, and how I would go about using / repurposing the tools it offers to clone the filesystem between Xaviers. I would appreciate if someone could post a short guide or link to a walkthrough.
I should also verify my assumption here - am I correct in assuming that the EMMC is the only persistent storage on the Xavier, and that duplicating it would perfectly clone the Xavier? If not, what other storage needs to be flashed?
EDIT: Links to relevant threads I’ve looked at:
https://devtalk.nvidia.com/default/topic/1047483/jetson-agx-xavier/how-to-dd-xavier-disk-how-to-boot-the-os-in-usb-disk-/post/5315746/#5315746
https://devtalk.nvidia.com/default/topic/1039548/xavier-cloning/
Based on the above threads, it looks like the recovery mode cloning tool is still in development. Is the current recommended approach for Xavier cloning to use the rootfs approach mentioned here: https://devtalk.nvidia.com/default/topic/1039548/jetson-agx-xavier/xavier-cloning/post/5284202/#5284202
You are correct, cloning is still in development. However, if you follow from the above URL on cloning, and can verify in one test that this works for you, then it should be ok for a production environment.
A word of caution though: Passwords will be cloned. If any custom network setup rule based on MAC address is made, then this too will be cloned. If any special static setup of network is made, then this will be cloned. MAC-based rules will fail since the new system has a different MAC address. Basically you should examine the “/etc/udev/rules.d/” to see if there is something specific to the MAC address used there for customizing.
If you ever accidentally flash without the “-r” argument to flash.sh, then you will lose your clone. Keep a safe copy.
Thanks linuxdev. I have a spare (blank) OEM module that I can try to use as a test, before wiping an existing system. To use the flash.sh script, does the system need to be bootable already (i.e. I’ve run jetpack once successfully), or can it simply be in recovery mode?
Also a good point about the passwords (and RSA keys and such) being cloned and MAC address based rules failing, will keep it in mind. Another thing that may become a problem for us is that we’re using an NVME SSD to expand the internal storage, and have the /home folder mounted there. The Xavier I’m cloning currently does not have an internal SSD so the /home partition is still on the EMMC, so it won’t be a problem right now, but it would be nice to have a good solution for this in the future as well. At the moment I think we could clone the SSD separately from the EMMC, but since the /etc/fstab file is cloned too, the wrong UUID would be present for the SSD, and it wouldn’t mount properly …
it is not that complicated, in my opinion,
if to take dd image from a running xavier and make it with mksparse to system.img and flash it to an empty OEM device with
sudo ./flash.sh -r jetson-xavier mmcblk0p1
that should work fine with automatically resolving MAC issues as that will rather be a deployment method that fits for distribution.
FYI, a Jetson can go into recovery mode for use with flash.sh even if the Jetson eMMC is completely empty. The info @Andrey1984 gave will work with any module. Recovery mode is mandatory and the Xavier becomes a custom USB device the driver package (running on host PC) understands (flash.sh is the driver package command line interface).
You might consider looking at use of a label for a home directory mount instead of UUID. On any Linux system you can run “lsblk -f” to see UUID and LABEL. For setting a label see “man e2label”.
Another possibility is to name the home directory mount device via the “/dev” special file name. Be careful though that if the drive will not always be present on that specific device to use the “nofail” option in fstab (otherwise boot will halt when it can’t find the device).