Hi everyone I’m trying to clone my tx2 for backup for avoiding to flash from start every time using the following topic: https://devtalk.nvidia.com/default/topic/1000105/jetson-tx2/tx2-cloning/
But i try to use the last flash.sh and I encounter:
I’ve trying from the flash.sh of the latest jetpack, and the one provided in the topic, and it is the same error.
Any ideas?
I’m using xenial on the host pc, if that helps
Which L4T version exists on the Jetson now, and which driver package version are you using the flash.sh script from? The “jetson-tx2” is definitely valid, but only in releases for the TX2. You can see the current Jetson L4T version via:
head -n 1 /etc/nv_tegra_release
Note: The current JetPack 4.x series (L4T R31.x) is for Xavier only…don’t know if it would make this complaint.
On the jetson I have:
dgromov@dgromov-GL552VW ~> dgromov@dgromov-GL552VW ~> ssh nvidia@10.42.0.22
(base)
Welcome to Ubuntu 16.04.5 LTS (GNU/Linux 4.4.38-tegra aarch64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
0 packages can be updated.
0 updates are security updates.
Last login: Thu Oct 25 21:36:09 2018 from 10.42.0.1
nvidia@tegra-ubuntu:~$ head -n 1 /etc/nv_tegra_release
# R28 (release), REVISION: 2.1, GCID: 11272647, BOARD: t186ref, EABI: aarch64, DATE: Thu May 17 07:29:06 UTC 2018
nvidia@tegra-ubuntu:~$
And I’m using the last jetpack that support the jetson tx2.
I’m running ./flash.sh in the host. Should I run on the Jetson ?
This is my flash.sh that is in the download folder of the Jetpack folder
I’m using JetPack-L4T-3.3-linux-x64_b39.run
Sorry this was a cell of trying to copy the code in a code segment, but didn’t work.
I’m sorry pasting code is a mess here:
the gist is in here:
“flash.sh” always runs from the host with the Jetson in recovery mode and connected via the micro-B USB cable. Using this as you have on the host is correct and valid.
Because your host is R28.2.1 you would use the R28.2.1 driver package’s flash.sh. The latest JetPack which uses R28.2.1 driver package (JetPack is a front end and downloads the driver package) JetPack3.3 would be the version which supports cloning on your Jetson. Any of the JetPack4.x series (using L4T R31.x) would fail. So your version of JetPack and L4T tools are valid and compatible with that particular Jetson for cloning purposes.
This is a very odd error if the Jetson is there in recovery mode with USB. What is the exact clone command you used?
I’m attaching a screenshot of my bash session that shows that lsusb shows the jetson-tx2 in recovery mode, and the exact command: the one that you mention on the mentioned cloning thread.
[img]
[/img]
In a more explicit way:
sudo ./flash.sh -r -k APP -G my_backup.img jetson-tx2 mmcblk0p1
Also I would like to make the remark that the forum posting tool is not friendly to put code or images.
From what I can tell this should work. VMs are not supported, but a VM should not cause the error you see (a VM would probably still fail, but it would not fail this early on). I’m going to suggest that you try downloading and unpacking the R28.2.1 driver package separately in its own empty directory. You won’t need the sample rootfs, and you won’t need to run apply_binaries.sh since you are only reading the Jetson and not flashing it.
If this fails, then can you try this without a VM? The driver package, without the JetPack GUI, does not have any requirement for a specific Linux distribution…most any x86_64 Linux PC will work on command line.
If that fails, then I think you found a bug or something strange which I have not seen before.
Well I’ve used a VM because it failed in the same way on the host PC (the baremetal OS - Xenial), I was able to flash the Jetson from the VM using the Jetpack binary no prob (installing everything from the files and drivers to VisionWork Samples), I have downloaded multiples times the flash.sh script from _installer, but no avail same error.
Can you point me on where to report this bug?
You are in the correct place, but this bug is so odd I have to wonder what is going on. On the other hand, the _installer directory version might differ between JetPack and other versions since it uses a mutable manifest file to find what it wants. I’m going to suggest one more step: Try with the R28.2 driver package…I know for a fact that this works:
[url]https://developer.nvidia.com/embedded/linux-tegra-r282[/url]
Although you wouldn’t flash a mix of R28.2 and R28.2.1 the clone mechanism of R28.2 is guaranteed to be valid. If this fails in the same way it is probably something going on with the system…if not, then it is evidence that it is time to mark this as a bug.
[url]https://developer.nvidia.com/embedded/linux-tegra-r282[/url]
The reason I am suggesting more work is because if you go through RMA and end up in the same place due to a problem not part of the Jetson you’ll lose far more time than trying the R28.2 clone.
I think is time to pinpoint this as a bug:
I first did it on the Virtualbox Machine:
I’m annexing the md5sum so you can verify the flash script.
Also, in a xenial machine with no virtualbox (native os):
(base) dgromov@dgromov-GL552VW:~/backup_folder$ md5sum flash.sh
279e5b81c39ab48806378739e445b748 flash.sh
(base) dgromov@dgromov-GL552VW:~/backup_folder$ sudo ./flash.sh -r -k APP -G my_backup.img jetson-tx2 mmcblk0p1
Error: Invalid target board - jetson-tx2.
Usage: sudo ./flash.sh [options] <target_board> <rootdev>
Where,
target board: Valid target board name.
rootdev: Proper root device.
(base) dgromov@dgromov-GL552VW:~/backup_folder$ lsb_release -cs
xenial
once with tx2 I had to use some value like mmcblk0p12 instead of mmcblk0p1 when flashing with flash.sh
However, regarding to your issue, it appears that -G is not required for flashing, please use for reference the post: TX2 Cloning - Jetson TX2 - NVIDIA Developer Forums
As soon as you are using -G key , you are rather like reading from partition than flashing, as it appears to me.
Moreover, I can see the below in your quote:
(base)
does that mean that you are running the execution from within virtual env?
You may also use dd for exporting a partition from jetson, in my opinion.
Even if something is wrong with the command line he passed, it calls “jetson-tx2” an invalid target board. Perhaps there is something wrong, but it isn’t what the message says. There was a patch for earlier R28.1 flash.sh for clone, but R28.2 and newer should be ok…and if not, then the error it claims is not correct…“jetson-tx2” is a valid target.
For reference I’m re-posting the URL from the original message:
[url]https://imgur.com/j5Sq938[/url]
While I suspect using a VM would cause failure, a VM would not cause this particular error (without work, had this error not appeared, likely the clone would have failed at a later time). It just seems very strange. In fact he has apparently tried a native Ubuntu system as well with the same result. Sadly you can’t use “strace” on flash.sh since it is a script, and I wouldn’t suggest hacking the script to have it give more information unless familiar with bash…but I know from other use of flash.sh that it should work. I am puzzled.
Yes, I have both run the script on a VM, and a native xenial OS.
Anything that I can do from my part to help me out?
the base on the bash shell it’s a helper that I created whenever I append something to PATH, I use anaconda so it puts anaconda’s python first in the PATH, do not know if that something that might affect the bug (but in the vm bash shell I do not modified the PATH).
Any ideas?