Jetson TX2 boot problem

Hi there.

I am using Jetson Tx2 for almost one year.

Then I got a problem with booting.

“[OK]Started Update UTMP about System Runlevel Changes”

above message is the last one that I could see.

Thank you.

Is this the last seen via serial console? If not, try to get a serial console log. In cases where only the GUI is failing you might find the system actually booted correctly other than video and you wouldn’t want to flash just to fix video configuration. For serial console information see:
http://www.jetsonhacks.com/2017/03/24/serial-console-nvidia-jetson-tx2/

There could be a hardware failure, but this might also be entirely recoverable via software. If you have a lot of hard disk space a good test would be to see if you can clone your rootfs partition (and if something is failing the clone makes a nice backup and reference copy for later use). Do beware though that a clone will exceed the size of your entire rootfs on the host PC. If your rootfs is 16GB, then we might be talking 20GB of storage on the host PC (the clone produces one"raw" image which is the exact byte size of the partition, plus a “sparse” image which is less than the size of the partition).

One can clone a Jetson from most L4T/JetPack/SDKM flash releases, but instructions do vary on earlier releases. Any restore operation requires the specific release used for the original flash the clone is from. Most recent release instructions will say to place the TX2 in recovery mode, connect the micro-B USB cable, and do the following:

  • cd ~/nvidia/nvidia_sdk/JetPack...version.../Linux_for_Tegra/
  • Make sure you have a lot of spare disk space, e.g., “df -H .
  • sudo ./flash.sh -r -k APP -G my_backup.img jetson-tx2 mmcblk0p1

In the above you will have two new files (slow to create due to massive size):

  • my_backup.img, a “sparse” image.
  • my_backup.img.raw, a “raw” image.

I recommend throwing away the smaller “sparse” image and keeping only the raw image. A raw image can be examined, used for restore to different parts of the system, or used as complete rootfs partition if you flash again with the same release version. A sparse image can only be used for flashing. It takes a long time to compress a raw image, but if you are done and want to save a more compact version, then you could compress it, e.g., via “bzip2 -9 my_backup.img.raw”.

If cloning works, then your hardware is probably fully functional and only in need of flashing again (and conveniently, you might be able to just use your clone for the content to flash). If cloning fails, the it is very likely a fatal hardware issue.

Try the serial console log first though, it is a lot faster to look at that.

Btw, even if there is a hardware failure, it seems the carrier board is far more likely to be the problem than the module itself. If the issue is the carrier board, then there might be third party carrier boards you could pick from and continue to use the module with (sorry, that’s usually expensive, but sometimes the third party carrier boards have features you might want anyway).