Jetson nano only boots after reinserting a memory card

Hi,

My jetson nano freezes rarely. I try taking out the power supply ( 4 amp barrel jack) out and re inserting to reset the board. But it doesnot boot( the green LED turns ON ) even if i reconnect the power supply multiple times. But when I take the memory card out and put it back, the board boots up.

My jetson nano syslog

Jan 13 15:37:35 jetsonNano-desktop systemd-timesyncd[3427]: Synchronized to time server 85.220.190.246:123 (1.pool.ntp.org).
Jan 13 15:38:07 jetsonNano-desktop systemd[1]: Starting GPS (Global Positioning System) Daemon...
Jan 13 15:38:07 jetsonNano-desktop systemd[1]: Started GPS (Global Positioning System) Daemon.
Jan 13 15:38:21 jetsonNano-desktop nvargus-daemon[4903]: === NVIDIA Libargus Camera Service (0.97.3)=== Listening for connections...=== gst-launch-1.0[6467]: Connection established (7FB00581D0)OFParserListModules: module list: /proc/device-tree/tegra-camera-platform/modules/module0
Jan 13 15:38:21 jetsonNano-desktop nvargus-daemon[4903]: NvPclHwGetModuleList: WARNING: Could not map module to ISP config string
Jan 13 15:38:21 jetsonNano-desktop nvargus-daemon[4903]: NvPclHwGetModuleList: No module data found
Jan 13 15:38:21 jetsonNano-desktop nvargus-daemon[4903]: OFParserGetVirtualDevice: NVIDIA Camera virtual enumerator not found in proc device-tree
Jan 13 15:38:21 jetsonNano-desktop nvargus-daemon[4903]: ---- imager: No override file found. ----
Jan 13 15:38:21 jetsonNano-desktop nvargus-daemon[4903]: LSC: LSC surface is not based on full res!
Jan 13 15:38:21 jetsonNano-desktop nvargus-daemon[4903]: === gst-launch-1.0[6467]: CameraProvider initialized (0x7fa8832cd0)LSC: LSC surface is not based on full res!
Jan 13 15:42:11 jetsonNano-desktop systemd[1]: Created slice User Slice of busnet.
Jan 13 15:42:11 jetsonNano-desktop systemd[1]: Starting User Manager for UID 1000...
Jan 13 15:42:11 jetsonNano-desktop systemd[1]: Started Session 7 of user busnet.
Jan 13 15:42:11 jetsonNano-desktop systemd[28600]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
Jan 13 15:42:11 jetsonNano-desktop systemd[28600]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
Jan 13 15:42:11 jetsonNano-desktop systemd[28600]: Listening on GnuPG cryptographic agent and passphrase cache.
Jan 13 15:42:11 jetsonNano-desktop systemd[28600]: Starting D-Bus User Message Bus Socket.
Jan 13 15:42:11 jetsonNano-desktop systemd[28600]: Listening on GnuPG cryptographic agent and passphrase cache (access for web browsers).
Jan 13 15:42:11 jetsonNano-desktop systemd[28600]: Reached target Timers.
Jan 13 15:42:11 jetsonNano-desktop systemd[28600]: Started Pending report trigger for Ubuntu Report.
Jan 13 15:42:11 jetsonNano-desktop systemd[28600]: Listening on GnuPG network certificate management daemon.
Jan 13 15:42:11 jetsonNano-desktop systemd[28600]: Reached target Paths.
Jan 13 15:42:11 jetsonNano-desktop systemd[28600]: Listening on D-Bus User Message Bus Socket.
Jan 13 15:42:11 jetsonNano-desktop systemd[28600]: Reached target Sockets.
Jan 13 15:42:11 jetsonNano-desktop systemd[28600]: Reached target Basic System.
Jan 13 15:42:11 jetsonNano-desktop systemd[28600]: Reached target Default.
Jan 13 15:42:11 jetsonNano-desktop systemd[28600]: Startup finished in 154ms.
Jan 13 15:42:11 jetsonNano-desktop systemd[1]: Started User Manager for UID 1000.
Jan 13 15:42:12 jetsonNano-desktop gnome-shell[5654]: pushModal: invocation of begin_modal failed
Jan 13 15:42:12 jetsonNano-desktop gnome-shell[5654]: pushModal: invocation of begin_modal failed
Jan 13 15:42:12 jetsonNano-desktop gnome-shell[5654]: error: Unable to lock: Lock was blocked by an application

Can anyone tell me a reason for the problem?
So what is the proper way to solve the issue without touching the hardware?
Which other log file will have the details for this issue?

Not sure what do you mean “touch the hardware”.

In general, to deal with a boot up issue, you have to dump the log from uart console.

https://www.jetsonhacks.com/2019/04/19/jetson-nano-serial-console/

We run these systems in remote setups. We cannot keep going to the hardware physically to reboot them.

You want us to keep all our test setups with the uart console ? Its hard to have uart to usb hardware with our test hardware all the time. Is there any other way to take a dump of the logs without the uart setup?

This is just for debug. Once we found out the root cause of your issue, we won’t need to dump the log anymore.

We cannot help if there is no log here.

Just a thought on the topic: Keep in mind that even another Jetson can run a serial console to the other Jetson and log (you’d want to have enough disk space though). If you happen to have two Jetsons, then the serial log can be from one Jetson to the other, and from the other back to the original. The result would be that if both Jetsons do not fail simultaneously, then the one failing will be logged on the other.

Do you have two Jetsons together? Or can you put a second Jetson there to do the logging? If one Jetson is only for logging, then a single Jetson could log several others via USB serial UART.