A VM is not supported, and the flash software has no way to configure a VM, but if you can get the USB to always pass through to the VM and not allow the parent o/s to ever intercept, then it can be made to work. It is up to the end user to go through the learning curve of customizing the VM.
A live Ubuntu 18.04 should work. I don’t know if perhaps you mean you have a “server edition” of 18.04, but I would think this would work if it has the required components installed. Did you try with some sort of server edition of Ubuntu 18.04? If so, then I am curious what the failure was.
Not seeing a board connected implies either the Jetson is not in recovery mode, or else there is a break in the USB (well, it could also be that the hardware expected is some other model and your model is not supported). For example, in some cases there are commercial versions (TX2i industrial) versus non-commercial versions (the TX2 dev kit or a TX2 module not listed as industrial), and this might cause the USB to not see what it looks for. Sometimes some older laptops seem to also no longer work even though other computers do (because of USB issues).
If you run “
lsusb -d 0955:7c18”, and see a response, then it means the software should see a TX2. The “
0955:” lists NVIDIA devices, and the combination with “
7c18” limits this to the TX2. Other models will have something different than “17c18
". So to see anything "NVIDIA" you could run "lsusb -d 0955:`”.
Btw, USB is hot plug. If the Jetson is in recovery mode, and if you are watching a terminal which is running “
dmesg --follow”, then as you plug in the USB you should see a log about the particular device. Any form of error (or lack of error) in that log is important for debugging.
Different flash commands take into account different carrier boards. The module itself has its own support, and if the lsusb shows the right module, then that support should be good to go. If you have a dev kit, then the carrier board is supported by default. If you have a third party carrier board, then you have to use their board support package, which is adjusting for the carrier board.
Also, third party micro-B USB cables have a very high failure rate when it comes to running data for any significant time or speed. You might go through five different “charger” cables before you find one which will work for a flash. The dev kit supplied cable will always work (if there is a USB failure with that cable, then it is extremely unlikely that changing the cable will help).
I don’t know about this, I could only guess:
Sometimes there are network issues, or login issues. When using JetPack/SDK Manager you need the newest SDKM (currently 1.3, no doubt in the future there will be some other revision). Some of the login protocols changed and older releases probably will have issues. However, if that were the case, then you would have probably hit other errors earlier on.
The actual flash is from the “driver package”, and the SDKM is just a front end to this during flash. Your driver package, after a flash, will exist here:
If you go there, and see the content in “
rootfs/” is populated (and if you tried to flash once it should be populated), then you can try command line flash, and log the flash. Assuming the TX2 is in recovery mode, the micro-B USB cable is connected, and you can see a response from “
lsusb -d 0955:7c18”, then this would flash and produce a log when run from the “
sudo ./flash.sh jetson-tx2 mmcblk0p1 2>&1 | tee log_flash.txt
The forum will allow you to upload a “
.txt” text based log file.