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.
“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.
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.
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.
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.
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.
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).