Jetson Nano (first boot) don't work after the first update system

Good morning all,

I have been working for 1 year on a 4GB nano jetson, everything is going well.
I recently bought a 2gb nano jetson, I flash the card, I configure my jetson, I run the update and install aptitude. Then the computer asks me to restart. When I restart the NVIDIA logo appears on the screen, then the screen remains black with a few white flashes at times. I use the Labists 5V 3A power supply recommended by Nvidia. Has anyone ever had this problem?

Thank you

Is it correct that the question is for the 2GB unit? Was the SD card installation working prior to the update?

If you have serial console, or even ssh access, then it is a lot easier to find out what is going on. If this is video as an issue, then chances are serial console and ssh are easily reached. The flashing sounds like something is crashing when going to GUI mode, then it tries again.

FYI, if you were running X normally, then the key binding CTRL-ALT-F2 (also F3 through F6) would take you to a text mode terminal as well. This should work from the local keyboard even if X is crashing, but the binding would have to be hit at a moment when X is starting but not yet killed off.

You might also mention which SD card image is used, and how it was installed. For example, there are some prebuilt images, or flash from SDKM, so on. Knowing the actual release version might also matter.

Yes, it is the 2gb jetson that has this problem.
The installation of the SD was working fine before the update yes. Yes I managed to open the console at startup, but I don’t see an error. It was installed by following the Nvidia tutorial step by step with the same software (

Hi val_lam59,

We are discussing on the same issue in another thread.

[Jetson Nano blank screen during and after boot]

For those interested, the thread mentioned by @val_lam59 is here:

I don’t know what is going on, but it is likely there is some sort of conflicting package update. It sounds like you are using a dev kit, but if using a third party carrier board, then this failure would be likely. For the case of a dev kit such updates are unexpected and probably need to isolate which package update is causing the failure. About all I can suggest for this is examining logs in “/var/log/apt”.

Note logs such as “/var/log/eipp.log.xz” can be examined like this:
xzcat /var/log/eipp.log.xz | less -i
(the “i” of “less -i” just says that if you do text searches it will be case insensitive; the above is similar to using xzless)

Individual logs can be examined like this:
gzcat /var/log/history.log.1.gz | less -i

You could also copy the file somewhere else, decompress with gunzip or xz, and rename with a “.txt” file name suffix to attach directly to the forum.

Note that I would recommend looking at the other thread instead since this is a growing topic.