The system.img.raw file is uncompressed and used to create the system.img sparse file. You’d need the flash system to use the sparse/compressed file, the system.img.raw would work for the rootfs partition on eMMC. But this isn’t what you want.
See this for an expansion on the topic of partitions and cloning (and restore):
[url]http://elinux.org/Jetson/Cloning[/url]
There are many partitions other than the rootfs. Those partitions must work together at boot. What you want is to flash and set up your Jetson as you desire, and then clone “all” (the complete eMMC image) instead of just “app” (rootfs). The “all” clone is what you want.
It’s purely academic, but note that when you clone “all” you can use dd (if you know partition boundaries) to extract the equivalent of “app” from “all”…or to extract any partition. “all” is a contiguous single file spanning all partitions (mmcblk0 instead of mmcblk0p1). FYI, all of the partition boundaries are aligned at 4k offsets (e.g., run gdisk, and “l” to list partitions…offsets are listed by sector, and sector size is noted as 2048 bytes…all start sectors are divisible by 4096, all “end - start + 1” sectors are divisible by 4096). Since the flash app produces 4k-aligned images and assembles them onto the Jetson rather than as a single image you can’t just flash the images to chips one at a time without a possibility of error…cloning removes the error of sort order possibility, but technically, you could use dd and NULL-padding to create a single image from individual images (flash.sh pads some images on their tail with NULL prior to flashing the image).
Something I’ve never tested but which you might want to be aware of is that if you go into gdisk on a JTK1 and list all partitions you’ll note that the first partition does not start at the first sector. This implies that cloning everything requires cloning more than just partitions…it requires the metadata describing the GPT partitions, and this occurs at the start of the disk. I think cloning “all” clones this too, but I’ve never specifically tested. Measuring the exact size of clone “all” and comparing to the sum of the partition sizes should reveal the “all” image as being 94207 sectors larger (the first sector for a partition is 94207+1 at start…though I may be off by 1 sector on how I’m counting). If it turns out clone of “all” does not include metadata, then you might want to use “dd” to preserve those first 94207 sectors and prepend to the “all” clone…but I don’t think that would be necessary.