I know you can use the L4T flash.sh script to read the tx2 emmc and create a .img file that can be restored. Is there a way you can read/copy the rootfs from the remote machine to the host directory? Let’s say I want to add a bunch of software packages manually on my tx2 and then copy it back to the host so that it is all available for the next time I want to flash another device.
The copy via flash.sh is called a “clone”. When you clone you get both a smaller file with suffix “.img”, and a larger version of the same file with a “.img.raw” suffix. That larger version can be loopback mounted on the host and then mounted somewhere for access just like a regular partition. Once you have that, then you can use any standard backup mechanism. I tend to use rsync on this.
For example, if you have “backup.img.raw”, then:
sudo mount -o loop /where/ever/it/is/backup.img.raw" /mnt
# Do whatever you intend...then:
sudo umount /mnt
There are lots of examples of using rsync, and once the loopback clone is mounted the instructions won’t differ no matter which type of hardware is involved. As an example, with “–dry-run” to pretend without actually doing anything:
# You will use sudo for these...
rsync <b>--dry-run</b> -avcrltxAP --info=progress2,stats2 --numeric-ids --exclude '.gvfs' --exclude 'lost+found' <i><many source directories...> <single destination></i>
# With example source and destination over ssh with loopback mounted on host "/mnt":
rsync <b>-e ssh</b> <b>--dry-run</b> -avcrltxAP --info=progress2,stats2 --numeric-ids --exclude '.gvfs' --exclude 'lost+found' nvidia@ip_of_jetson:/home/nvidia /mnt/home/nvidia
# Note: I use a lot of variations on rsync over ssh, and I tend to use the exclude part just
# because I run into it so much. Numeric ID copy is a must or ownership will change if the same
# user and group ID do not match between host and Jetson. This is just one of many examples.
# Please test before committing to use against a valuable backup image.
A really nice way of doing this is if you have ssh keys set up so passwords are not needed.
Incidentally, flash.sh cannot copy part of a partition. Thus rsync or other backup tools.
Can you explain why you need to run the rsync after you get your clone of the filesystem? If I use flash.sh to clone the entire flash, and I acquire the system.img.raw and the system.img, I have validated I can mount the system.img.raw to a directory and view the rootfs of the TX2. Why then would I need to rsync to that same location?
rsync is in case you have modified the Jetson and want to update the clone. An example is after an “apt update” and “apt-get upgrade” being tested as successful. “rsync” is faster than a full clone (this demonstrates the clone itself can be updated). Also, some people will use something other than a loopback mountable clone. Typically you won’t use rsync if you just want a clone, but over time you may find it is useful to use a combination. You would not use rsync right away after a clone, and perhaps never.
Thank you. That was very helpful.