However i am having troubles restoring the clone, using: sudo ./flash.sh -r -k APP jetson-nano-emmc mmcblk0p1
On a fresh device this results in:
[ 0.6795 ] tegrarcm --boot recovery
[ 0.6821 ] Applet version 00.01.0000
[ 0.7055 ]
[ 0.7056 ] Writing partition
[ 0.7082 ] tegradevflash --write APP /home/user/nvidia/nvidia_sdk/JetPack_4.3_Linux_JETSON_NANO/Linux_for_Tegra/bootloader/system.img
[ 0.7098 ] Cboot version 00.01.0000
[ 1.2918 ] Writing partition APP with /home/user/nvidia/nvidia_sdk/JetPack_4.3_Linux_JETSON_NANO/Linux_for_Tegra/bootloader/system.img
[ 1.2950 ] 00000004: Filesize is bigger than partition size
[ 1.3243 ]
Error: Return value 4
Command tegradevflash --write APP /home/user/nvidia/nvidia_sdk/JetPack_4.3_Linux_JETSON_NANO/Linux_for_Tegra/bootloader/system.img
Failed to flash/read t210ref.
I found a workaround, which is to first write the default image using sudo ./flash.sh jetson-nano-emmc mmcblk0p1. After this the original clone can be flashed. Flashing is successful, but something is still wrong as the unit gets stuck on boot. There are few messages displayed before black screen:
The “-S <size>” option is used when the image is not default size.
Keep in mind that “backup.img” is “sparse”, and will not tell you anything about the actual image size (other than the size is larger than that). When cloning you will end up with a “raw” image as well, “backup.img.raw”. This image is the exact size of the partition.
In the option for size, actual bytes divided by twice by 1024 (divided by “1024*1024”) is “MiB”, and actual bytes divided three times by 1024 (divided “1024*1024*1024”) is “GiB”.
“28GiB” is “28*1024*1024*1204”. If your raw image is 30064771072 bytes, then flash would start with: sudo ./flash.sh -S 28GiB ...
If the original flash was a default size, then there is no need for the “-S”, but otherwise you would use “-S”.
Thank you for the idea.
I tried sudo ./flash.sh -S 14GiB -r -k APP jetson-nano-emmc mmcblk0p1 with no luck :(
Fresh unit still errors on flashing [ 1.2156 ] 00000004: Filesize is bigger than partition size
And pre-flashed unit goes to black screen of death, with same text as shown in first post.
Clone image is of JetPack 4.3 with first Ubuntu configuration done. Nothing special.
Is the raw image exactly 14*1024*1024*1024 = 15032385536 bytes? It sounds like the raw image is larger than this. Note that you cannot use a sparse image to find size, only the raw clone is the exact size of the flashed image.
Both files can perform the same function when renamed “system.img”. The smaller sparse image is faster to flash, but the sparse image has no use for anything except flashing exactly as it is. The raw file is the one you can develop with. However, the very first time you start to flash and forget the “-r” option, your file is gone. If this is the only clone copy you have, then be very certain you are not accidentally erasing it.
It is very difficult to see what is going on without seeing the entire serial console boot log.
Note that a clone must be flashed using the same release which the original clone came from.
Also, if there is a filesystem error on system which is cloned, e.g., from improper shutdown, then those errors are also cloned. You have a serious filesystem error, but I don’t know where this came from originally. FYI, you can use filesystem tools like fsck.ext4 on a loopback device. However, this seems rather severe.
If your original rootfs filesystem size is not a default, or if resizing has in some way caused your clone to differ from the size the system expects by default during a flash, then the filesystem would also be bad due to truncation. I think the flash script will often see that an image is too large for a partition, but with a microSD image, I do not know what would happen. Your flash command is for an eMMC model though. Can we verify this is an eMMC model, and that the clone came from an eMMC model?
I tried to flash with both files separately, sorry for being unclear. md5sum shows that the system.img file is same as the backup file. And yes, this is a eMMC model, and clone came from eMMC model which has no filesystem errors.
Will try to access the serial log.
I am wondering - has anyone succeeded in cloning and restoring the Jetson Nano eMMC module?
To help everyone, I wanted to mention a difference between your original restore command:
…and your final restore command:
You would always use the latter version if possible. This version will also add content for the non-APP partitions such that the content is correct for the current boot configuration. The first command will only write the APP partition, and other partitions may or may not match. The time required for flashing all partitions, versus just APP, is trivial…those other partitions are so tiny in comparison to APP you wouldn’t notice.
