Stuck on Boot Up


My Xavier was working fine yesterday. One of the last things I had done was create a tarball of my root directory and copied it (over SSH) to another machine. I used it for a couple minor things afterward and had no issue. I left it on and plugged in to ethernet. When I got back this morning it was stuck on the log in screen. I could enter my password, but after hitting enter the log in screen just refreshed. I powered down and powered back up and also tried just restarting, but both times I get stuck on boot up.

Log after power up:

Log after restart:

Does anyone have any ideas on what could have happened? And how to fix without reflashing Jetpack?

If the i2c error at 0x50 was for the monitor’s EDID query, then it might be that the system is otherwise working. Can you ssh in, or “CTRL-ALT-F3” and then log in to a text prompt? Or via serial console? If the system is otherwise up and running debugging will likely be easier. Any information on the monitor itself would also be useful, especially any HDMI adapters.

Also, is this Jetson accessible to the general internet? If there is no router or firewall blocking outside access from the wild, are all of your login name/password combinations non-guessable (not defaults)?

I did not try to SSH in. The network I had been connected to is down. “CTRL-ALT-F3” did not work for me.

I had the board connected to the router of a guest network. Yes I did have an easily guessable password. Is having it hacked a likely possibility? I do not know much about networking and security but am suspicious since that particular network is down entirely.

I did not figure out how to solve the problem. I ended up reflashing with the SDK Manager.

I think the problem may have been this:
The tarball was too big and I maxed out my memory. I had memory usage notifications turned off. Everything seemed ok at first, but crashed my Xavier after restarting.

Earlier releases of L4T (and in fact most Ubuntu) had default admin names/passwords. Anyone who installed behind their own router was protected from unsolicited outside network traffic. Those who were not (e.g., students in dormitories always share wide open networks) would be network scanned and hacked quite fast. So if for example you used a release with the “ubuntu”/“ubuntu” name/pass, and you were visible to other uncontrolled systems, there is an extremely high chance there was a malicious hack involved. If you were behind a router and could trust people there, then the risk is rather low. If you changed the password to a non-default, then risk was also low.

Running out of resources is a very reasonable possibility. Even the host PC has to have a lot of disk space before starting as people often do not realize entire eMMC partitions are being created prior to flash. The Jetsons themselves are like other computers and once filesystems fill up and temp files cannot be written logins and many applications will fail. That’s for physical disk/eMMC storage. If RAM is filled, then this will certain bring the system down, but if you can log in, then typically it is easy to disable programs consuming too much RAM.