Yes that worked OK.
[ 1604.7420 ] Flashing completed
[ 1604.7421 ] Coldbooting the device
[ 1604.7439 ] tegradevflash --reboot coldboot
[ 1604.7457 ] Cboot version 00.01.0000
[ 1604.8495 ]
Starts up correctly to the GUI.
Hope the running commentary was useful.
MS
One thing to know about cloning is that it can take a lot of time. Reading from a Jetson to create a 15GB clone image is time-consuming. The reverse direction is also true. I think the reason why a “sparse” image was introduced was because of how excessively long it took to flash a 15GB image…the sparse image is calculated on the host machine, which is reasonably fast, and then the sparse image flash is much faster than flashing a raw image. When you restore from a clone you’re back to a very slow flash…I have not timed it, but I would not be surprised if restoring from an uncompressed clone takes more than an hour, whereas the sparse image of that same partition might take a few minutes.
A consideration regarding cloning is about partition size. Even though other partitions are not normally visible, the root partition does not exist by itself. I’m not sure what size/location changes exist to various other partition sizes or locations when changing the size of the rootfs via a normal flash, but it may be possible that restoring a clone would require the Jetson to have been originally flashed with the same size of rootfs.
It is possible the mistaken “-R” options (versus “-r”) may have rearranged partitions earlier in a way which caused failure for some clone operations until a regular flash took place. I’ve not heard of the supplied USB micro-B cable being an issue before, the shorter cable working may have been a coincidence.
Yes it may well have been a coincidence.
I did notice that each retry to flash the same standard OS image with the
sudo ./flash.sh -r jetson-tx1 mmcblk0p1
command got a little bit further.
But after the 5th attempt and no further than 13% before failure an element of desparation crept in.
Thanks again for your help and the explanation for the difference between the image and the raw image.
Hi,
I have exactly the same problem as MartinSnaith.
i am trying to clone images now and i’m stuck here “writing partition APP with system.img”.
i have waited for at least more than 10 hours but it’s still 1%.
however when i check the running processes, it seems like it is running now.
should i wait more ?
If cloning resulted in part of the system.img being cloned, then you probably had the command correct. There may be other issues. A clone can take a couple of hours, but 10 is an obvious problem. Some people have issues with a VM stopping in the middle…is this a VM for host?
If it helps anyone, the stages for creating a ‘replica’ TX1 for me were:
Assuming you have installed a TX1 from the dev kit, and done some work on board and now you want a backup and a second clone TX1:
Do the clone of the APP partition as above (page 1) with tegraflash.py
Create a ‘new’ TX1 from an identical version of L4T by running the
./flash.sh jetson-tx1 mmcblk0p1
with your out of the box new devkit TX1
Do the ./tegraflash.py “APP write command” as above.
Just doing clone and restore of the APP partition on an out of the box TX1 will not copy all the partitions you need
Just to share my 2 cents.
I’ve always used an SD card, instead of the on-board eMMC, for software development on JTX1. I found this approach pretty useful because: (a) I wouldn’t be limited with only 16GB (eMMC) of storage space; (b) I could swap between different software environments (dev/demo/product) really quickly; (c) it’s easy to recover from rootfs problems or kernel crashes.
By cloning the SD card, you’d also be able to clone the software environment to another JTX1 easily.
I’ve shared how I set up the SD card in the following blog post.