Boot issue after improper shutdown


I have been experiencing a weird issue with my Jetson TK1 for a while now: if I shut down the jetson by holding down the power button, it won’t boot into Ubuntu automatically on the next startups. To resolve this, I need to connect a keyboard+monitor and log into the console at startup. Then I need to sudo shutdown it before it will boot into Ubuntu again. This is really annoying because I don’t always have a keyboard available and thus always need to take the entire platform and hook it up at a workstation in the lab… I was wondering if there is a way to access the console via USB (not RS232 serial, I don’t have an adapter here with me),

If not, is there any way to figure what goes wrong and causes the Jetson to have these boot issues?

I’m running on the 21.2 GRINCH Kernel…

Thanks a lot!


Just in general using the power button without a real shutdown hurts any operating system that buffers its file system. ext4 is journaling but something will still be lost even if the partition is not corrupted. I suppose something on the front panel header could be set to do a proper shutdown with a button on that header, but I have not set up such a thing (the header is next to the DB9 serial console connector and provides the same pins as a desktop computer would provide to chassis buttons).

I have not tried to use USB for communications, I imagine doing so is possible but involved (more so than getting a serial UART USB cable). You would have to have dedicated software on both sides of the USB connection using ordinary USB. Ethernet ssh is one alternative.

There is probably interest in the community in different ways to use that front panel header, someone may have already set one up to do power down on press.

Thanks for the quick answer. I didn’t have another choice but to power down the jetson with the button as the network connection stopped working and I couldn’t regain access even after plugging in and out multiple times… And there was no keyboard/display available…

I also cannot ssh into it via ethernet, as it gets stuck on boot up before setting up the network interfaces… Guess I’ll have to go and use display+usb keyboard to get it back to working every time this happens… Kind of annoying, a proper shutdown button would be very much appreciated!


There is a known issue with gigabit cutting out on R21.1 through R21.2. You might want to flash to R21.3.


Any news on how this error can happen? Did you solve it somehow?

I also have encountered this error many times with my Jetson (Both with the standard image and the grinch kernel). Whenever my Jetson freezes, and it does that quite often, there is no network connection and no visible output. I need to log into a consolve (STR+ALT+F4 for example) and blindly type sudo shutdown -P now. Then it will power down and I can again boot into a graphical user interface.

Any possibility to avoid this or any Idea whats the reason behind?

Best regards

If the shutdown command works, then Linux didn’t fail per se. Just the interface.

Under X11 I’d expect the possibility of the X server failing, but not seeing console output (while typing in still works) is unexpected and not common for a text terminal. I have not heard of this directly, although it is possible that sleep and forced logout bugs could conceivably be doing this as well…without knowing that it works to type into the console without feedback of what was typed such console failures could be overlooked.

Much of the auto logout and auto sleep bugs went away with R21.3. What L4T version are you using? Do you have serial console available when this happens (serial console would let you view logs or shutdown without being blind)? Serial console is very important for debug.


Currently I am using R21.2.0 with the grinch kernel 19.3.8

I am now a little clearer on how to reproduce the error. Basically I have two setups:

  1. The Jetson with my Chalkboard Electronics 7" Display
  2. The Jetson with a normal Monitor (BENQ GL2460)

Both setups do not start the graphical interface after an improper shutdown (i.e: when Jetson freezes and I reset or I manually pull the plug to reproduce this error)

With the display I get no interface whatsoever but Keyboard inputs are still accepted. So I can change to a terminal with STR+ALT+F4 and blindly log in and shutdown the Jetson with “$sudo shutdown -P now”

With the monitor I come into the same state but at least I see the console output. There I can type in again sudo shutdown.

Then when I restart the Jetson the graphical Interface appears again.

Any idea what causes unity to not start after an improper shutdown? A collegue of mine also had similar problems with an Odroid and got around by running fsck every boot to check for corrupt files but I dot not know yet how to run fsck during runtime.

I also generally would like to avoid the Jetson from freezing to prevent this error state. Are there any guidelines or knowledge how to handle the Jetson so that it does not freeze during use?

In the meantime I will upgrade to the latest L4T Version and see how the problem is handled there.

Thanks and best regards

It’s hard to say exactly what would cause a GUI failure after restart from improper shutdown…there is no definition of how a corrupt startup should work. There is a general theme though of temporary files and socket files related to applications like unity, and those files which should have been cleaned up are perhaps still there (socket files for example are only created by an application as it runs, and should be destroyed by the application when it exits…abruptly stopping without shutdown destroys the cleanup of those files).

I don’t know if this particular issue will be changed by R21.3, but this release does fix a lot of important issues…it is worth upgrading from R21.2 even if the particular issue isn’t resolved.


I now finally was able to update to the newest L4T Release but unfortunately the issue still remains.

Whenever the system needs to be shutdown by force (Reset Button or loss of Power) the Unity GUI does not come up at the next boot. I need to switch to a console (with a new display I am now able to see this) and shut down the system manually. Then boot again and unity appears again.

Any ideas what could couse this? Or any idea to tell unity to start unity anyway?

Thanks and best regards

Usually there is some sort of temporary file that should have been cleaned up, but incorrect shutdown doesn’t allow it. E.G., there might be a generated socket file. There isn’t any specification of how displays should clean up when using a corrupt file system…unity is likely trying to start, but has incorrect configuration because of the temp files.

If you knew which temp files needed to be removed, you could add removal to rc.local, but the real fix is to shut down cleanly. As is, the components of the system are doing what they are supposed to do. What needs to be solved is the reason for the incorrect shutdown…what is causing the requirement for this?

I think you are right! Unity is definitely trying to start but it cant. Yesterday I played around more and now I have two possible solutions. Either make a “clean” shutdown or try to start unity manually by typing “sudo service lightdm restart”. However I need to type this two times, because at the first time there happens nothing. After the second time lightdm starts and unity appears. Strange behaviour

As for the incorrect shutdown … I get the feeling that the Jetson freezes a lot. I have no experience with the 21.3 L4T but with the earlier versions it would just freeze from time to time out of no special reason. One of the possible reasons is when I compile a lot of code on the Jetson. Then it appeared to freeze more often but that is just a guess…

Any Idea what those files I could delete are?

Having the GUI freeze has indeed been a common topic on earlier releases. However, with R21.3 the issue seems to be mostly gone. I have also compiled a lot of software on Jetson, although not via the native GUI (I log in via ssh, my main computer monitor is larger than the one on Jetson); I have not had the GUI fail me (I’ve been using R21.3 almost exclusively, except for some testing).

One of the problems with automatically deleting files is that you must guarantee the delete occurs prior to any attempt for X11 to run. The files I see in a normal X11 prior to logging in are in /tmp:

directory .ICE-unix
file      .X0-lock
directory .X11-unix

If forcible deletes work manually, you might be able to back up then modify “/etc/init/lightdm.conf” to do the deletes, or study “/etc/init.d/x11-common”.