The clone first builds system.img.raw. This is actually the only image you can loopback mount and observe or edit. From this system.img is created, where system.img is a “sparse” file. This can be used for flashing a rootfs, but it cannot be loopback mounted or observed. I delete system.img and save only system.img.raw (when not using system.img.raw I use “bzip2 -9” on it to compress…that takes some time, but I have many reference clones for every release of TK1 through TX2).
If the clone produced a truncated system.img.raw, then you know system.img has also failed and is not reusable (flash won’t tell you that, but booting from a failed rootfs image won’t provide a working system).
When you go to restore a system from a clone, then any file in the “bootloader/” directory, named “bootloader/system.img”, will flash regardless of whether it is a raw image or a sparse image. Raw images just take longer to flash since they are larger. The recovery mode Jetson understands how to deal with sparse versus raw images. Third party tools for sparse images do not work with this version of sparse files.
If you look at the exact size of the system.img.raw from clone, then you’ll know what the flash size was specified originally. When you flash to create a new image based on the “rootfs/” directory the “-S ” option basically works like this example:
# for MiB:
sudo ./flash.sh -S 14580MiB .... => 14580 * 1024 * 1024 == 15288238080 bytes mmcblk0p1
# or for GiB:
sudo ./flash.sh -S 14GiB .... => 14 * 1024 * 1024 * 1024 == 15032385536 bytes mmcblk0p1
Those were for the max MiB and GiB of a TX1 or TK1. This is the max for a TX2:
# for MiB:
sudo ./flash.sh -S 29318MiB .... => 29318 * 1024 * 1024 == 30742151168 bytes mmcblk0p1
# or for GiB:
sudo ./flash.sh -S 28GiB .... => 28 * 1024 * 1024 * 1024 == 30064771072 bytes mmcblk0p1
Thus flashing with “-S 14GiB” implies the system.img.raw clone will be exactly 15032385536 bytes. If you have a system.img.raw, and can divide it two times evenly by 1024, but not three times, then this was the “-S MiB” argument; if you can divide it evenly three times by 1024, then this was the original “-S GiB” argument. This is important because when you go to restore from a clone you would normally use the same size. Tools like gparted can resize loopback covered partitions if the loopback mounted partition has empty space. “gparted” does not know the difference between a loopback covered file system and an actual partition (note that I say “loopback covered” and do not say “loopback mounted”…you can’t edit mounted file systems). If you have a valid loopback mounted raw clone partition, then you can resize it for later use.
Note for what follows: If root uses “–find” as an argument to losetup, and no actual file is named to cover, it simply tells you the name of the next unused loop device. Then it creates the loop device. If non-root does this, then it still tells you the next loop device…but it doesn’t create it. I prefer to create first to avoid surprises like forgetting to detach…you could run out of loop devices if you forget to detach after creating and attaching. You can detach a loop device using “sudo losetup -d /dev/loop”. You can detach all unused loop devices via “sudo losetup -D”.
Note: Before using gparted or any tool to resize any partition, be very very sure you have read and understand what is needed to preserve the ext4 file system. Not all tools are safe to use with a file system. Those which are safe tend to have many ways to not be safe.
So lets say you have a 28GiB system.img.raw. If you were to find and create your first free loopback device like this, then you could use it to cover the raw file:
sudo losetup --find
# Assuming it says "/dev/loop0":
ls /dev/loop0
# ...should show loop0 exists.
sudo losetup --find --show ./system.img.raw
# Now loop0 covers system.img.raw
sudo gparted /dev/loop0
# make any size reductions...the change must be in units which produce an exact
# MiB or GiB size...if you originally had an MiB flash size, then any reduction
# in units of "1024 * 1024 == 1048576" bytes will work. When you go to flash, then
you would use a "-S <size>MiB" based on the new size. Same for "GiB", but units
of size reduction would be multiples of "1024 * 1024 * 1024 == 1073741824"
Just as an example, if the original system.img.raw had a lot of unused space, and if “-S 18GiB” is plenty of space to still have a running Jetson, then after the system.img.raw ext4 file system on loop0 is reduced to 19327352832 bytes (18 * 1024 * 1024 * 1024), this dd command should give you the file at that size which can be later named “system.img” and flashed with “-S 18GiB”:
sudo dd if=system.img.raw of=system-18GiB.img.raw bs=1 count=19327352832
A block size of 1 is not very efficient, so if we wanted to do the natural 512 byte block size (natural for ordinary old style hard drives), then we’d divide count by 512 and use a bs (“blocksize”) of 512 for the same end result (but faster copy of the 18GiB subset):
sudo dd if=system.img.raw of=system-18GiB.img.raw bs=512 count=37748736
The interesting part is that if you know this resize scheme you can also expand this 18GiB to a larger size (you’d need to first pad extra bytes onto the end of this file, e.g., with “truncate” since truncate can also expand).
The problem for you is that intermediate files will exceed your file system size. If you have the original system.img.raw as size 29318MiB, and loopback reduce it to 18GiB, then you could also use the “truncate” command to cut size without using dd to make a complete new file. You’d just need to make sure gparted puts all the unused space at the end instead of the beginning, and then use truncate to cut the size back. I’m not sure what intermediate file content size would be so I can’t say if this would also run out of space or not.
It may help to know that you cannot use anything but a native Linux file system type for the “rootfs/” subdirectory of flash. On the other hand, an already valid system.img.raw can be on any file system type…the file itself has self-contained ext4 formatting and where the file is stored does not matter. Your system.img.raw can be on NTFS, VFAT, or just about any file system type. If you are dual boot, then the file system where you work on system.img.raw can be on a Windows partition or Windows formatted SD card, USB drive, so on. If you don’t have room to experiment, and if you have only the clone, then it is kind of dangerous to experiment with it.