When you flashed to internal eMMC (mmcblk0p1) and cloned a loopback mountable partition, did the Jetson boot correctly?
A non-GUI flash is available for just flash and no other packages…try to use that without any JetPack GUI involvement when testing for flash quirks. I don’t know how your live distribution package manager will deal with things like addition of widget sets…the command line “pure flash” has no such requirements.
The clone command only works when reading eMMC, the SD card (mmcblk1p1) cannot be cloned (but you can plug the SD card into any computer and copy the partition with dd anyway). If you had a clone from any eMMC partition (mmcblk0p1) all NULL after a pure eMMC flash, then something was probably wrong…if the NULL byte clone was from SD card, then I’d expect it to fail and be NULL.
Flashing with mmcblk0p1 versus mmcblk1p1 changes things internally in the Jetson as to where it looks for data. This also changes which partitions are created on eMMC. I believe even with the SD card in, clone from a mmcblk1p1 may not be reliable; without the SD card you would definitely end up either with an error or all NULL. Expect clone of APP partition to be a reliable tool only when you flashed to mmcblk0p1 (eMMC). Moving a partition to SD card would cause the partition to disappear from any list of eMMC partitions. Configuring u-boot to use a new root partition via extlinux.conf edit is a very different story…this would leave the original eMMC root partition completely intact.
Using the non-GUI flash you can “re-use” a previously created system.img if you wish (however, I would not do this unless you can verify the raw image is loopback mountable). In the case of re-using an image ("-r" option to flash.sh), you might need to manually state the image size (like “-S 14GiB” for a raw image of size 15,032,385,536 bytes…something you cannot figure from a sparse image).