I have an x86 VM that can talk to the Jetson (I was able to flash the Grinch kernel) so I am not able to use the Jetpack for cloning as advised here Jetson/Cloning - eLinux.org
I was wondering if anyone had a straightforward method for copying a given Jetson filesystem via USB, and flashing a stock Jetson with the same image from command line.
Thanks for any input.
If you have flashed it once you’ll have a loopback mountable image of the file system which can be combined with the “-r” reuse option to flash.sh. This is the easiest way to do it. Have you ever flashed the Jetson? If so, which version (changes details depending on version)? Do you still have bootloader/system.img file?
Thanks for your reply.
Yes, I flashed the 19.3.0 Grinch kernel. Yes I have the system.img file in ~/grinch/Linux_for_Tegra/bootloader
My goal is to read a Jetson with Grinch, plus lots of other software and configurations to my host computer (VM) and subsequently flash 6 other Jetson boards so that they are identical to the original one.
If you have a method for this, please share.
The flash.sh script, if run with no arguments, shows a list of options (most of which you’ll never use). The “-r” option says to re-use the system.img without updating it…this means your system.img can be used to clone multiple times so long as it is a match for what you have. system.img itself was created by the flash script by first copying rootfs in and then updating it for boot loader. This image ends up as a bit-for-bit exact copy of what is burned into Jetson during flash.
Since you have R19.x you are in luck…I’m figuring out the details for use on R21.x, but R21.x changed the mechanics when it moved system.img to system.img.raw and created system.img as a sparse file from the raw file. Under R19.x you even have the option to loopback mount system.img and use something like rsync to update the system.img to be an exact copy even after Jetson has been updated. To do this you must not change any of the boot loader file options for fastboot versus u-boot on any flash…clone like this works provided you do not change boot loader.
If you have directory “/mnt/L4T/” you can for example mount system.img like this:
mount -t ext4 -o loop /some/path/to/system.img /mnt/L4T
Modify it as you see fit, then umount /mnt/L4T. Place the system.img in the bootloader subdir of the flash files, and flash with “-r”. Consider making an unmodified copy of system.img such as cp to system-unmodified.img, copying system-unmodified.img in turn to some new name like system-modified.img, and finally before flash a copy system-modified.img back to system.img (takes a lot of space…about 15 GB for each img file). This allows you to experiment with multiple failed versions and not destroy the basis for the backup…it’ll be available no matter what happens.
According to your example, are you suggesting after mounting system.img to /mnt/L4T, to modify the files in /mnt/L4T and umount it and then reflashing using ./flash.sh -r ? If so, this would assume modification on the VM host (where /mnt/L4T would reside) and not copying from a modified Jetson board. Am I missing something?
Thanks
It is correct that I’m suggesting this as one of the options…modifying it would be through rsync over the network from a live Jetson if and only if you wanted to update the Jetson and clone the updated Jetson instead of just what was initially flashed. This loopback image is a clone of what will go into the Jetson…it is also a clone that can be modified before re-using. An example would be to use the original Jetson which was flashed and running apt-get to get the deb packages updated…then using rsync to update the image…and finally keeping that image as a master and flashing as many Jetson’s as you want with the deb packages being updated as a match to the original.
You can just use “-r” and clone exactly from an unmodified image which has not been modified.
The point here is that whatever is on that image is cloned, and that the image is a real ext4 partition which can be modified the same way as any other ext4 partition. Using that image with “-r” is the magic step.
thanks for the responses.
I’ve been able to mount and umount the system.img from the grinch folder.
However after umount -l /mnt/L4T I don’t see where the system.img pops up that I’d copy over to the Linux_for_Tegra folder. Sorry for the basic questions. If you (or anyone else) has more turnkey-type process suggestions, any are welcome. thanks
A mount point is just where the content of the system.img is made available in the format of an ext4 partition. The file itself can be anywhere for that purpose. If your L4T R19.3 were unpacked at:
/where/L4T/is/at/
…then there will be subdirectories:
/where/L4T/is/at/Linux_for_Tegra/
/where/L4T/is/at/Linux_for_Tegra/bootloader/
…within this last subdirectory is where flash.sh looks for system.img:
/where/L4T/is/at/Linux_for_Tegra/bootloader/system.img
I suggest use of the cp command to copy an unmodified system.img somewhere else simply for preserving a copy which won’t be modified, and then use mount on the actual system.img within the L4T flash bootloader area if modification is desired. When flash.sh runs with “-r” this is the system.img which will be used and anything done to update it will propagate to the cloned Jetsons. There are no “turnkey” solutions per se, although I’ve been thinking about creating a version of flash.sh to do this (this wouldn’t happen in the near future).