Regarding loopback, every hard drive has a device special file from which it is manipulated or mounted; a driver covering a physical hard drive is how those device special files are created. Any device special file with an API for accepting block device manipulation works with hard disk commands. Loopback is just a way to “fake” block devices based on non-disk blocks of data. A file on the file system is such a block of data, and covering it with loopback generates a device special file which the operating system cannot distinguish from a real disk. Your file can then be formatted, partitioned, mounted, read, navigated, written, fsck’d, so on.
During flash loopback covers an empty file of the exact size of your entire target Jetson root file system. The loopback device special file is formatted ext4, mounted, and then gets a recursive copy of the rootfs subdirectory (with perhaps some boot files depending on options during flash). It is this file which is transferred as an ordinary stream of file bytes onto the Jetson (which puts those bytes directly on the Jetson without any processing…the fact that those bytes together have an ext4 file system is how rootfs becomes an exact match to what the Jetson gets).
If you clone the root partition on Jetson, you get a file. If you flash that file back to Jetson with the “reuse” option (“-r”), then nothing changes…you backed up your Jetson with clone, you restored it with the clone which is an exact match. However, on your host, you could have loopback mounted that file, edited something like network address, a serial number, and host name, and then flashed it…and that would then be the image the Jetson has (only those loopback mounted edits would differ from what it had been).
Clone takes significant time but is worthwhile. It’s an incredible safety device in case of losing a Jetson. That image, while on the host, can also be updated via rsync or any other backup mechanism. When I’m interested in keeping an image I typically clone, followed by rsync if I update something like “apt-get upgrade” (I see if the upgrade works, and if it does, I rsync…which is faster than a full clone). After I’ve updated too much I generate a new/clean clone and start over.
In the original flash.sh there was no such thing as compressing the root partition image. The uncompressed “raw” image was created as “bootloader/system.img” in the Linux_for_Tegra subdirectory. Later on, to speed things up (15GB over USB2 is slow), flash began moving system.img to system.img.raw, and then instead populated system.img via system.img.raw compression. It isn’t really any complicated compression, it’s what’s called a sparse image, sort of a very simple way of sending fewer bytes. flash.sh, when it uses the “-r” reuse option does not modify or create a new system.img, nor system.img.raw. If you place the uncompressed clone in place of system.img it works perfectly.
Clones and edits to clones are a very good way to do things in mass production. Keep in mind that if a clone was intended for R24.2 but some of the original Jetson is R23.1 there might be issues from just restoring a root partition…something might not match. You could use a command line tool directly without the flash.sh script, and exactly that one partition would be flashed. If you use flash.sh with reuse option then the other files are also flashed and you shouldn’t run into that issue.
More explanation of cloning is here (this is for the JTK1, but mostly this applies):
[url]http://elinux.org/Jetson/Cloning[/url]
More specific information for the JTX1:
[url]https://devtalk.nvidia.com/default/topic/898999/jetson-tx1/tx1-r23-1-new-flash-structure-how-to-clone-/post/4784149/#4784149[/url]
[url]http://elinux.org/Jetson/TX1_Cloning[/url]
For loopback, see “man losetup”. There should be an example of its use in the man page, plus lots of online examples. Do keep in mind that although non-root can use loopback, only root can create a loopback device (“/dev/loop*” might already exist, or might require automatic increment if a new loop device needs to be created…automatic increment will inform non-root what device it is, but will not create it…root would automatically create such a device without special steps).
One can cover a file with loopback, or remove loopback cover of a file already covered. Be sure to not generate an infinite list of loopback files. Check “ls /dev/loop*” for “loop0, loop1, loop2…” to see how generation and removal work.
Incidentally, “ifconfig” for network shows device “lo”, which is a loopback device pretending to be an ethernet device so local networking succeeds even if there is no network card.