Once the JetPack brush is forced to interrupt, use USB to connect the device brush again, and no TX1 device can be found.

Once the JetPack brush is forced to interrupt, use USB to connect the device brush again, and no TX1 device can be found.

Once the JetPack brush is forced to interrupt, use USB to connect the device brush again, and no TX1 device can be found ,but in fact,NVIDIA CROP can be found by using flusb at the host terminal

I assume you mean “flash” instead of “brush”. The behavior of losing the Jetson sounds like you are using a VM. VMs do this, they are not supported. Some people get VMs to work, but they have additional steps to not lose USB and ethernet (it’s a “VM” issue). If this is not a VM or different from what you are asking please give more background information.

@linuxdev Thank you for your attention to my question. I have solved the problem by restarting HOST, but a new problem has emerged. I use the virtual machine, I also know that the virtual machine has the problem of network and USB, I have done the corresponding measures. On the other hand, when I started to brush the machine, when I arrived at flush OS, the interface remained stuck. I could provide you with picture information. Please help me.



This is the main reason why a VM isn’t supported for flash. During flash the Jetson may re-enumerate and each time a VM will tend to lose knowledge of the Jetson. You will have to figure out how to tell the VM the Jetson belongs to the VM instead of the host of the VM no matter how many times the USB is removed and added back in (host owning the VM cannot take ownership of the Jetson no matter how many times it changes). I do not know the details of how to do that.

The wired ethernet may have some similar setting.

thank you linuxdev
I met another problem. When my brush was successful, I opened the TX1 normally and hung it in there. After coming back, the Ubuntu interface was blue and flickering. Only a few folders were in the interface. Is the driver bad?

There are a number of possibilities for this. It could be a crash of software, it could be a hardware problem, it could be something simple like a sleep/low-power mode setting having problems. Can you give more details about what you mean by “only a few folders were in the interface”? This latter information should narrow down the possibilities.

Also, what is the exact monitor cable type, including any adapters? Is there anything unusual about the monitor?

Does reboot at least temporarily get things working again? If not, do you have a serial console log of the failed boot?

The speed of startup is too fast, so that the boot log can’t see clearly. As for a few files on the blue screen, it’s a file on my desktop, that is, the whole screen is blue, and the new file on the desktop is OK, but the screen flashes and it seems to be refreshing. On the other hand, the heat dissipation module is hotter than usual.
I have restarted many times, not the screen and HDMI line. There are other ways to do it besides reflash the machine?

Do you have serial console? If so, then the serial console can record everything as a plain text file. The log would be extremely useful. Serial console is described here:
http://www.jetsonhacks.com/2015/12/01/serial-console-nvidia-jetson-tx1/

Are you able to use ssh to log in? If so, then you could also see if “dmesg --follow” shows logs as this occurs.

You might be able to use CTRL-ALT-F2 to get to a local text console. If you can, then check what dmesg has said at the end.

See if all files are “ok” from “sha1sum -c /etc/nv_tegra_release”.

See if “sudo” works. One example is to simply use it with “ls”:

sudo ls

See if you have disk space left:

df -H -t ext4