Hello everyone! I want to make an image from Jetson Nano, which boots from USB(128 GB), but not all the space is busy. I want this image to be as small as it can be. I’ve already tried make an image with help of Clonezilla, but the image is still too big (around 50GB). Maybe you know an app or smth like this.
I will be very grateful for any help.
I don’t have answer for this, may other developers help to share experiences. Thanks
Don’t know if I can help, but describe whatever working image you have on your USB now which you want to derive this from. If booted from that image, then post the output of “df -H -T”.
hi, to be honest, I don’t understand what parameters of system you want to see
whatever working image you have on your USB
but here is output from df -H -T:
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda1 ext4 125G 55G 64G 46% /
none devtmpfs 1,9G 0 1,9G 0% /dev
tmpfs tmpfs 2,1G 54k 2,1G 1% /dev/shm
tmpfs tmpfs 2,1G 31M 2,1G 2% /run
tmpfs tmpfs 5,3M 4,1k 5,3M 1% /run/lock
tmpfs tmpfs 2,1G 0 2,1G 0% /sys/fs/cgroup
tmpfs tmpfs 415M 17k 415M 1% /run/user/120
tmpfs tmpfs 415M 0 415M 0% /run/user/1000
Speaking about list of programs I want to be in this image:
- customly build OBS with two plugins (gstreamer and obs-ndi)
- pyCA capture agent for opencast
and here is the version of OS (uname -a)
Linux jetson-desktop 4.9.253-tegra #1 SMP PREEMPT Mon Jul 26 12:13:06 PDT 2021 aarch64 aarch64 aarch64 GNU/Linux
P.S. I booted jetson from usb following this instruction if this matters
P.P.S thank you in advance <3
You can just add that to an actual running Jetson, and then clone this to create your image. The image would be the exact size of the partition itself. Not sure what “busy” means, but whatever you’ve done to add or remove content prior to the clone would exist in the clone exactly as it does in the original running Jetson.
If that clone is too large (you’d need to be able to keep a single file on the host PC which is 125GB in size since that is the partition size), then you could instead replace the flash directories file content in “Linux_for_Tegra/rootfs/” with an rsync copy of just files, and other than some “rootfs/boot/” content (including perhaps kernel, depends on flash options), the result would be a new flash (without “reusing” the image) using that content.
By “busy” i meant “occupied”, sorry for misunderstanding. What do you mean by “flash directories” and “flash options”?
Is it about editing default L4T SD card image or something else?
If so, why use rsync specifically?
It is useful to describe how flash (installing the operating system from scratch while in recovery mode and erasing prior content) is performed…
NVIDIA basically keeps a reference Ubuntu operating system completely without NVIDIA’s files. This content, a complete Ubuntu operating system, in the host PC at “Linux_for_Tegra/rootfs/” of the flash software. During flash NVIDIA then adds its own hardware drivers (this only occurs once, there is no need to repeat this) and content (technically it is the end user adding this content via the click of a button, which is useful for licensing reasons). Aside from content in “Linux_for_Tegra/rootfs/boot/”, this content becomes an exact match to the image flashed to the Jetson.
Options passed to the flash software are used to determine some special case requirements of the carrier board (device tree mostly) and kernel (different kernel options might be appropriate for different platforms, and Jetsons are not the only hardware the flash software supports). The appropriate files (such as kernel Image) are copied into “Linux_for_Tegra/rootfs/boot/” prior to building the flash image (this content is updated every single flash).
During flash, with “rootfs/boot/” now updated based on options passed to the flash software, a file is created with the exact size of the rootfs/APP partition to be populated by flash. That empty file is covered with loopback so that it can be treated as a partition on a disk, and is formatted with an ext4 file system. That file system is then populated with the current exact match of “Linux_for_Tegra/rootfs/”. This becomes file “Linux_for_Tegra/bootloader/system.img.raw”. This raw file is used to create a “sparse” file (same content, but much smaller…it isn’t compression but it used for file size reasons) at “Linux_for_Tegra/bootloader/system.img” (flashing either raw or sparse file has the same result, but sparse file flash is faster).
You end up with a system flashed which is an exact replica of “rootfs/”. Once the flash software is installed only the “rootfs/boot/” content might change, and if it turns out you flash the same hardware each time, then other than the timestamp even “rootfs/boot/” will remain constant among all flashes. Tell the flash software to alternate between flashing an Xavier and TX2 and that is the “flash option” which can change “rootfs/boot/” in small ways.
If you were to replace “Linux_for_Tegra/rootfs/” with a clone of a running system, then all flashes would create a new system.img which is nearly an exact match of “rootfs/”, and the only change would likely be the timestamp on the kernel Image and perhaps device tree.
It is possible mount a clone on “Linux_for_Tegra/rootfs/” and only temporarily use that clone. If you were mount something like a clone on a spare SD card to “rootfs/”, then the original content on the host PC at that location would be temporarily replaced by that SD card. A umount of the SD would restore the original content. Similarly, a clone’s raw image can be loopback mounted on “rootfs/” and temporarily used in place of the stock/default flash content.
If you were to tell the flash software to “reuse” the system.img, and that replacement is from a clone, then you’d get the same result. However, there is a subtle difference you might be interested in versus using that clone to replace “rootfs/”: The size of system.img from a clone demands the partition size on the Jetson be exactly the partition size of the clone; but, generating a new image from the clone being used as an overlay to “rootfs/” means you can change the partition size (so long as the partition fits the eMMC and has enough space).
On command line, if flashing an eMMC model of a Jetson (it doesn’t make sense to talk about any of this if it is an SD card model…make sure that if this is an SD card model to make that clear), then one might perform a default flash like this with the Nano being in recovery mode:
sudo ./flash.sh jetson-nano-emmc mmcblk0p1
Optionally, if you wanted the default rootfs/APP partition to be 16GiB in size, you could explicitly change the size of the system.img to this via:
sudo ./flash.sh -S 16GiB jetson-nano-emmc mmcblk0p1
1 Like
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.