Hello,
I want to create my own jetpack with the installation I made(Like opencv, pytorch etc.). I have more than 30 Jetson nano and I need to install same things to all. I just want to install everything I need to 1 jetson and clone to others. Is there any way to do that?
Thanks
Hello @haydarcakmak7 ,
In your scenario, you should install JetPack os with the packages which you would like to have. After installing Jetpack with desired packages, you should backup the image to your host pc. Than, you can flash this image to your other jetson nano modules. You can find the required steps in the below link.
https://elinux.org/Jetson/Clone
Best regards.
hello haydarcakmak7,
you should overwrite the system.img as yours, and using the flash script to duplicate the image to other platforms.
note, please include -r options to skips building system.img; and reuse the existing one.
you may check developer guide, Flash Script Usage for reference,
thanks
Another option (or variation) on what has been mentioned: When the system generates “bootloader/system.img”, which is what gets flashed, it does so mainly via the content of “rootfs/”. There are some edits based on flash options whereby the content in “rootfs/boot/” is modified, but the rest of what is in “rootfs/” should remain constant. If you needed to add your own kernel and/or firmware which is a modification target, then you could for example change the appropriate source from which JetPack/SDKM copies, e.g., “Linux_for_Tegra/rootfs/boot/Image” is typically from “Linux_for_Tegra/kernel/Image”.
If you have a clone, then typically you’d place your clone at “bootloader/system.img”, followed by using the above mentioned “-r” option to “reuse” that image rather than generating it. However, if you were to loopback mount your raw clone (basically the clone.img.raw rather than the clone.img…both are created during a clone) at “Linux_for_Tegra/rootfs/”, then you could still generate new images, but those new images would be based on your clone with the kernel and perhaps device trees edited (which presumably you would have updated from the correct location).
The advantage of loopback mounting at “rootfs/” is that later on you can update the loopback mounted “rootfs/” via something like rsync if you want to. You could of course do this with the clone in place of system.img, but with the loopback in place in rootfs/ you wouldn’t need to worry about accidental lack of use of “-r”. Loosely speaking it is algebraically nearly the same to use the clone as “rootfs/” instead of directly as “bootloader/system.img” (along with the “-r” flash.sh option), but it is a useful illustration on how flash proceeds, and that you can use your clone either in its entirety, or else for everything except the “/boot” content.