My jetson orin nano is no longer booting properly. It used to do the thing where it does an initial boot showing a loading boot screen, then goes dark, then does the actual boot that logs me into my OS. Now, however, once it finishes that initial loading boot screen & goes dark again, it doesn’t do the full boot, and the screen stays dark
The orin nano uses an SD card that was loaded with the appropriate Jetson Orin Nano Developer Kit SD Card image. It worked for a few months before suddenly stopping.
What might be going on, and how can I fix this? Any help is appreciated.
Wouldn’t this destroy all the data on the SD card as well as the environment? I’d like to be able to recover everything, as there is some important data on it, and the environment took some time to configure.
Backing up data in the SD card should be easy.
If you don’t want to re-flash it, then at least capture the serial console log so we know what’s happening behind the scene:
Hi, I’ve followed this guide using the cable used in it, and tried using both another orin nano with jetpack and a windows machine using both PuTTY and RealTerm, and had no luck getting anything useful. On the nano, using minicom, I get either a blank input stream or a few odd characters. I’ve attached pictures and a vid of this:
Additionally, when using PuTTY, the output file is blank. However, with RealTerm, I do get some output before the process hit’s the break condition, but it’s usually just an odd character. I’ve attached that file here as well. capture.txt (86 Bytes)
Still have some issues where it doesn’t connect every time, but was able to finally get an input stream! Attached it as a log file. Hope it helps! orin_nano_serial_logfile.log (138.6 KB)
looks like the bootloader is still working, but the file system on the SD card is corrupted so it cannot be mounted correctly.
Please see if you can still access the SD card with a host PC, back up the data and re-flash it.
(I think the SD card image method should do it; you don’t really need SDK Manager here.)
FYI, that many errors is “extraordinary”. This is only typical of a corrupt filesystem which is written to many times while already corrupt. Usually mount will be refused if a filesystem is corrupt.
This problem could be a failing SD card, so I’d recommend replacing it to find out. However, if it isn’t a bad SD card, then the real goal is to figure out the first corruption. The first corruption was probably much smaller than this:
[ 316.902463] EXT4-fs (mmcblk1p1): error count since last fsck: 6305
Corrupted filesystems can be misleading when you look at what “seems” to be corrupted since one inode can have an effect on other inodes. On the other hand, sometimes the corruption does provide a clue. I do see this:
[ 13.062742] systemd[1]: Failed to determine whether /run is a mount point: Bad message
This tends to be the operating system’s territory for applications needing file locks. If an app refuses to shut down correctly before a system shutdown, then sometimes it can result in that file being corrupt. However, the journal should take care of it if it is just one file. “/var/run” is actually a directory containing a lot of lock files, so it is possible that one file in the directory started the corruption, and that the containing run/ subdirectory ended up corrupting. That still wouldn’t explain 6305 error counts since run/ would not contain anywhere even remotely close to that many lock files. I would bet that the “/var/run” message is just one symptom which is noted in logs because of the need for temp lock files at the start of boot. Most likely there is corruption all throughout the system.
Some possibilities (with different likelihoods):
The SD card is dying.
One or more applications are hanging on shutdown.
Improper shutdown.
Brownout (power being sufficient to operate, but not sufficient for proper disk write). Jetsons tend to just self-shutdown in that condition, so I wouldn’t even consider brownout.
What I can’t explain is why, upon boot, the rootfs with errors would ever be mounted. With 6305 errors rootfs should never have been mounted. This would be a requirement before any mount on “/var/run”. It should not have got to that step. It is bizarre that this would happen. My suggestion is to get a new SD card and see if it happens again after a complete flash.
