cloning tx2 root to nvme drive, part 3

Since 32gb in the emmc is not enough room for the things I’m trying, I would like to clone the root partition onto the nvme drive. I’d like the emmc root to remain untouched, except for the extlinux.conf file.

Hardware setup 1, nvme drive resides on the TX2:
a) “cp” is not an adequate solution as it fails some symlinks and etc.
b) “dd” should work fine but am concerned about a recursion problem since I’m copying from the root and the nvme drive resides under root.

Hardware setup 2, nvme on host to be replaced back ono the TX2 once copying is complete:
a) from host: unsure how to “dd” from external host (TX2) to internal drive (nvme.)
b) rsync from host or TX2 should work but I can’t determine the exact syntax to use.

And, I don’t have an understanding of how all those tiny partitions on the TX2 are needed during times other than boot, if at all. I don’t know they are there and when they are needed.

I don’t understand the TX2 cloning thread, https://devtalk.nvidia.com/default/topic/1000105/jetson-tx2/tx2-cloning/?offset=8#5172270, since I don’t know what the “APP” partition is or how it’s used, as it is specific only to the TX2 world.

Lastly, none of these workarounds allow a full system backup image for when things go horribly wrong and you want to restore to the last known “good” point. And when I do programming, things do go horribly wrong, especially on an unfamiliar embedded system like the TX2. :) On all my other Linux hosts, “redo” is perfect for image backups (it’s based on dd and copies the system image to the nas box in my usage.) For the RPi’s, I run only on the SD cards and they are easy to image copy; same for the beaglebone blacks.

Guidance, please?

This question/reply is a partial duplicate, see:
[url]https://devtalk.nvidia.com/default/topic/1014421/jetson-tx2/using-dev-nvme-drive-or-sdcard-as-root-partition-or-even-sata-drive-/post/5172505/#5172505[/url]

The key to using dd is that the drive should not be mounted. dd itself operates on device special files, and has no knowledge of underlying file system, so it copies device blocks, not files (which in turn means it does a perfect job regardless of what operating system formats are used, and even encrypted file systems are copied without error).

The flash.sh program refers to partitions in a number of ways, one example being an offset and length span. Each partition uses a label as well, the “APP” partition is just a shortcut label for the root partition. The “APP” partition is rootfs on all of the Tegra devices flashed using this application. Any application which can see GPT labels can see “APP”, e.g., under gdisk you can print (“p” command) partition info and “APP” appears next to the first partition.

Backup is best with clone, as you can tell flash.sh to “reuse” (via “-r”) an existing system.img, and simply substitute the clone directly in place. Info on the missing flash.sh “-G” parameter is given in that other URL. Loopback mounting the clone on PC host allows the clone to be updated with ordinary rsync methods from a remote Jetson if the Jetson is running.