Is there any way to clone a Jetson TX2 not using any USB connectors. I have a TX2 that seems to have lost all USB ability through some sort of ground short. The issues is, the version of JetPack / tensor flow / open CV I can not seem to built on another Jetson TX2 with any success. I have found ways to cone using USB, but are there ways to do so only over network or some other method?
Thanks!
hello scbean,
may I know what’s the real use-case, are you going to copy rootfs or something else?
dd utility should helps, it’s the tool to read/write the content to elsewhere, it may take hours for read/write huge partitions.
Thanks for getting back to me. The real world use case is, I have a damaged TX2 with I believe Jetpack 3.6 as well as Tensorflow and open CV all working to run a program. It took months to get the proper versions of Jetpack, Tensorflow, and Open CV to run the program successfully. Since the TX2 was damaged, I have spent months attempting to rebuild another TX2 with the same versions of everything to have the program work, but have been unsuccessful.
At this point I cannot even get Tensorflow to install correct on any version of Jetpack ( asked in another thread).
My hope is to “clone” the contents of the damaged TX2 to a new TX2 that USB works on. Hopefully this explanation helps.
dd does in fact work over ethernet via ssh if you want, but rsync might sometimes be a better choice. It all depends. If you do clone this way, then I suggest putting the drive into read-only mode first. You can do that via either serial console or ssh. You could then use that content (slightly different methods depending on if it is a dd copy versus rsync, with different advantages and disadvantages) to flash with. What access do you have?
Just to experiment, assuming you have login and can run sudo (not all of this requires sudo, but some does), try sync of the device, followed by putting it in read-only mode.
This is a long explanation, and you don’t need to read it all for your case (it was explaining things related though):
https://forums.developer.nvidia.com/t/enter-oem-interface-after-reboot/235298/34
The shorter answer is that once in read-only mode you can either shut down normally or simply pull the power (read-only systems won’t corrupt). If you monitor “dmesg --follow” on a terminal (you can log in via both serial console and ssh, or multiple ssh logins), call sync twice:
echo s > /proc/sysrq-trigger
echo s > /proc/sysrq-trigger
Then go to read-only mode:
echo r > /proc/sysrq-trigger
With that done you are free to use any backup method without the content changing on you during the backup (e.g., no temporary files will alter it). Without this, then typically rsync would be the only valid way to do this without the possibility of something changing on you such that the final image is inconsistent; with this rsync and dd should always work without such an issue, and dd might have advantages for “clone->flash” (rsync would work, but there are some details to be careful with).
If using dd, then on the Jetson side you’d want to do everything sudo. So you could first “sudo -s” to go into a root shell. The receiving side (a host PC) could be done as a regular user. The size of content is quite large, and so you’d need to know ahead of time if you have enough space (space required is somewhat larger than the size of the partition being cloned; then during flash of the clone you want even more space for safety).
A typical dd over ssh is (I am assuming an eMMC model; an SD card model is much simpler):
On the Jetson side:
# This will take a long time; note the file name suffix is now for gzip:
dd if=/dev/mmcblk0p1 | gzip - | ssh YourUserName@pcaddress dd of=/home/YourUserName/Downloads/clone.img.gz
Note that mixing in “sudo” might confuse the “~” in paths, and so I advise to use the full path of the destination and not use “~”.
I saw a useful link on the topic which suggests installing pv (“sudo apt-get install pv”) to monitor the pipe:
dd if=/dev/mmcblk0p1 | gzip - | pv | ssh YourUserName@pcaddress dd of=/home/YourUserName/Downloads/clone.img.gz
Even with gzip compression that will be a huge file and take a lot of time to copy it somewhere or to gunzip it, but I advise using gunzip only after you’ve moved it. One could step up the compression, which is normally for network reasons and not size restrictions, but for example, building on the above:
# bzip has better compression, but for various reasons is used less often during a backup; gzip can
# be recovered in chunks, but if part of a bzip file is lost, then the entire file is lost. In this case no
# loss is expected over the network since it is local (note I altered the destination file name suffix):
dd if=/dev/mmcblk0p1 | bzip2 -9 - | pv | ssh YourUserName@pcaddress dd of=/home/YourUserName/Downloads/clone.img.bz2
Once you have that a “normal” command line flash can be performed with the “-r” option after placing the clone as file name “system.img” at the flash software’s “Linux_for_Tegra/bootloader/” location. Example, after you have a new unit with USB, and the clone is in place using the same release of flash software:
sudo ./flash.sh -r jetson-tx2 mmcblk0p1
Great thank you! I’ll give this a try tomorrow and let you know how it works!
Don’t forget that the path you store the clone to on the host PC can be to removable media. For example, if you have a USB external hard drive with sufficient space, then you could name that as the place where you store.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.