JETSON TX2 logged successful flash, but nothing is available on after board restart.

Problem: I am trying to flash my JETSON TX2 from VMware workstation 14 player (running ubuntu 16.04) on my windows machine. I finally got the vm to recognize the board as a usb device upon booting in recovery mode. However, after I finished the instillation the log reported flashing was successful, but there aren’t any demos or programs on the board. The last thing that I was prompted with was determining device IP. I selected manual entry.

Log file:
Using rootfs directory of: /home/evan/Downloads/64_TX2/Linux_for_Tegra/rootfs
Extracting the NVIDIA user space components to /home/evan/Downloads/64_TX2/Linux_for_Tegra/rootfs
Extracting the BSP test tools to /home/evan/Downloads/64_TX2/Linux_for_Tegra/rootfs
Extracting the NVIDIA gst test applications to /home/evan/Downloads/64_TX2/Linux_for_Tegra/rootfs
Extracting the configuration files for the supplied root filesystem to /home/evan/Downloads/64_TX2/Linux_for_Tegra/rootfs
Creating a symbolic link nvgstplayer pointing to nvgstplayer-1.0
Creating a symbolic link nvgstcapture pointing to nvgstcapture-1.0
Extracting Weston to /home/evan/Downloads/64_TX2/Linux_for_Tegra/rootfs
Adding symlink libcuda.so --> libcuda.so.1.1 in target rootfs
Adding symlink libGL.so --> libGL.so.1 in target rootfs
Adding symlink libnvbuf_utils.so --> libnvbuf_utils.so.1.0.0 in target rootfs
Adding symlink libnvid_mapper.so --> libnvid_mapper.so.1.0.0 in target rootfs
Adding symlink libcuda.so --> tegra/libcuda.so in target rootfs
Adding symlink libEGL.so --> libEGL.so.1 in target rootfs
Adding symlink libGLESv2.so --> libGLESv2.so.2 in target rootfs
Adding symlink /home/evan/Downloads/64_TX2/Linux_for_Tegra/rootfs/usr/lib/aarch64-linux-gnu/libdrm_nvdc.so --> /home/evan/Downloads/64_TX2/Linux_for_Tegra/rootfs/usr/lib/aarch64-linux-gnu/tegra/libdrm.so.2
Adding symlink nvidia_icd.json --> /etc/vulkan/icd.d/nvidia_icd.json in target rootfs
Creating symlinks for weston, wayland-demos, libinput and wayland-ivi-extention modules
Adding symlinks for NVIDIA systemd services
Copying USB device mode filesystem image to /home/evan/Downloads/64_TX2/Linux_for_Tegra/rootfs
Disabling NetworkManager-wait-online.service
Disable the ondemand service by changing the runlevels to ‘K’
Extracting the firmwares and kernel modules to /home/evan/Downloads/64_TX2/Linux_for_Tegra/rootfs
Extracting the kernel headers to /home/evan/Downloads/64_TX2/Linux_for_Tegra/rootfs/usr/src
tar: write error
Adding symlink /home/evan/Downloads/64_TX2/Linux_for_Tegra/rootfs/lib/modules/4.4.38-tegra/build --> /usr/src/linux-headers-4.4.38-tegra
Installing Image into /boot in target rootfs
Installing the board *.dtb files into /boot in target rootfs
Success!

I have no idea what to do next. I have attempted to complete the process through virtual box w/virtual box extenstions and failed. I deleted everything from the virtual box, attempted flashing and failed. Then I downloaded VM workstation and downloaded JETPACK, tried installing got the log shown above, but to no avail the board still doesn’t have the drivers or demos that I need. Any help would be greatly appreciated.

VMs don’t normally work. Some people have figured out how to make the USB remain owned by the VM even if the device is re-enumerated. Similar for ethernet bridging when it gets to package install.

If you got to the “Success!” part it probably means flash is good. If you lack video after that, then this isn’t a sign of flash or system failure…it’s just a symptom of video configuration failure. One thing which can cause this is if the video has any sort of VGA adapter…the wire used for a monitor to give its specifications to the video card driver doesn’t exist for VGA. Some adapters also don’t pass through this wire (the DDC wire).

If you have a router, then as the Jetson boots you should see the router log a DHCP request. You can use that IP address to ssh in (either name/pass of “ubuntu”/“ubuntu” or “nvidia”/“nvidia”).

Sometimes you can get a text console with CTRL-ALT-F2.

A serial console is by far the best way to work with issues when part of the system is failing.