First, beware that if you do anything which doesn’t allow boot, and you don’t have physical access for the recovery button, then it is pretty much “game over” and you’ll have to physically recover the Jetson.
For whichever partition you might update with dd, the release version of L4T must match. If you update a rootfs, then the release used for the rootfs must match the release used for all of the other partitions, and vice versa.
In more recent releases (past R28.1) the device tree must first be signed. See:
I do not know if the same signature works on all Jetsons. Would someone from NVIDIA be able to state whether a device tree signed via the above URL’s information allows dd copy to any TX2 which is using the same L4T release version? Is any part of that signing tied to a specific TX2?
Does your situation make it possible for another computer to provide serial console access? If it does, then you have more choices on kernel update with safety. For example, if you have an SD card slot, then you can put a rescue system in this, and then have this boot only if serial console is used to select the alternate entry. This would still be dependent upon the “/boot” directory of the eMMC, but it would give you a chance to fully boot without mounting eMMC; this, in turn, would allow you to dd copy a new rootfs in place. This isn’t entirely useful though since you need to use the same release.
On the other hand, if you are booted to an SD card, then you could copy an entire dd image of the eMMC directly to the eMMC of the given system. Instead of a partition at a time, you’d dd the entire mmcblk0.
There are things to look out for when doing a dd image copy of either the rootfs (mmcblk0p1) or the entire eMMC (mmcblk0). For example, if the MAC address of the ethernet were put in a udev entry for naming an ethernet, then it would not work on the next Jetson because the MAC address would differ. You might want to provide different passwords, and a dd of the password/shadow/group files would clone those and not use the original passwords.
Keep in mind that a rootfs can also be updated with rsync like any normal backup/restore operation. Having another computer available for this will do the job. Having an SD card for this will do the job, but since you don’t have physical access, then you could consider iSCSI mount of a remote system (this is not a simple thing to set up…I would normally suggest that route for higher performance over NFS, but it isn’t without a learning curve).
From the above, can you narrow in on what might be the direction you are interested in? For example, is a rescue SD card out of the question? Do you have more than one local TX2 to test creating a signed device tree to dd to both and validate that they can use the same device tree?