That command should have worked. I did notice it was flashing an A/B option though. Is it possible that one of the “Linux_for_Tegra/” config or XML files was ever edited? It isn’t unusual to take a file like “jetson-tx2i.conf” and edit this for some sort of customization. That file is also a series of “include” files, so if any of them were edited, then it might have changed something.
I’m going to suggest that you recursively copy (with preservation of permissions and ownerships) the “Linux_for_Tegra” subdirectory to something like “Linux_for_Tegra-test”, and then completely flash again with the replacement (it is R32.7.3 according to the flash log). Once it is flashed, or even with its current installation, edit something just to know if it gets flashed again. Save a copy of the running Jetson’s “/etc/nv_tegra_release.conf” and “/etc/nv_boot_control.conf” for basic information, and then clone. Does it then clone correctly? If so, then I’d follow the chain of .conf files which jetson-tx2i.conf is linked to and see if they differ somewhere.
If those files do differ, then it is a question of how they were changed. If they don’t differ, and if it is still cloning by flashing instead, then this is repeatable evidence of a bug which could be solved. You will need to preserve the original flash content (which is why I said to copy “Linux_for_Tegra”) for comparison to freshly downloaded content.
I don’t think the VM should have changed this, but if for some reason file permissions are incorrect somewhere (such as being on a non-ext4 partition), then maybe this had some effect.
Thank you for your response. The jetson-tx2i.conf was never changed. We made changes only to to the dts file and the same is being reflected in the flashed Jetson. We will try to flash again as per your suggestion to figure out what is going wrong while cloning.