Ubuntu for arm64 won't let me log in

I was connected to my jetson orin nx via the Real VNC program and I clicked restart. Now Ubuntu is stuck on a purple screen with two users logging in: mine and RdpUser (which has never been there before)… By logging in to my account the screen goes black for a second and then brings me back to the loop to the purple screen with logins. I tried turning it off and on again and it doesn’t work, clicking ctrl+alt+f1/f2/f3/… but the screen just goes black and nothing happens… I have important files and configurations that I don’t want to lose, I need it really, someone’s help please! Thanks in advance to anyone who will help me! Help me please!

Do you have local access to try with serial console? If not, then remote access via ssh should probably still work. If there was an update which had an effect on the GUI, then the other local login methods probably still work (especially serial console).

Yes, the jetson is physically with me (if that’s what you meant), remote access no longer works (error: the computer refused the connection) and all the tests I did to access it that I described above have been carried out directly on/from the jetson

If networking also failed (and it seems that if ssh fails that would be the case), then you need to use the serial console. I’m thinking this probably has more than one third party vendor of carrier boards, but what is the exact/specific detail on carrier board and module?

There is some similarity between many carrier boards, and typically there is a separate USB-C or micro-OTG USB connector which is not used for either power nor for regular USB devices. An example might be the Connect Tech “Boson” carrier board (an interesting name for the carrier board since Bosons are the force carriers), which has a video here:
https://www.youtube.com/watch?app=desktop&v=t4WPyKVX61I

At around 2:37 an image is shown with a chassis, and one port is marked “OTG”. Even if you didn’t have this chassis, if this is a Connect Tech carrier board, then likely it has the micro-OTG USB port. The trick is to find out where the serial console is at.

Here’s another example (Auvidea JNX45):
https://auvidea.eu/product/70785/

excuse my ignorance on the matter, but once I find this serial port, how do I access the jetson and check that this doesn’t happen again? (because I have no idea what’s happening to jetson)

Behind/below the processor module there is a 12-pin button connector (J14).
Pin 3: RX
Pin 4: TX
Pins 7,9,11: Gnd
3.3V LVCMOS signals
This port does always work - even before Linux has started.

fchk

ok thanks, but I didn’t understand (I don’t know) what I should do, it’s probably trivial for you, but can you explain to me?

Buy this cable
https://www.amazon.com/dp/B07RBKCW3S/
Black (Ground) goes to Pin 7
White (Cable TX) goes to Pin 3 Nvidia RX
Green (Cable RX) goes to Pin 4 Nvidia TX

Use putty (Windows) or picocom (Linux) to connect to Jetson board with 115200 8N1, no handshake.
Turn on jetson board. You should see Text. if not then turn off, swap white and green and try again.

Once I’ve done this, how do I log in normally?

You should have a text mode login prompt then. From there on you can examine and resolve your problem and do data recovery etc.

ok thanks, just one last question, do you have any idea what the cause/problem could be or how to find it?

Could be anything. Defective filesystem (Linux doesn’t like hard poweroffs), full root fs, wrong permissions, networking issues, … There are too many things that could go wrong, so don’t ask for specific hints.

But even if you don’t find the cause you also have the means to save your data to network, usb stick, or even via zmodem and sz over the serial line just as we did 30 years ago.

ok, time to get the cable and I’ll try. In any case, Thank you very much for all your help and time spent for me!

Incidentally, the programs you use for serial console, e.g., PuTTY or picocom, have the ability to log the session. Any time you start logging the session prior to applying power to the Jetson, you can post that log in the forums. That log is the single most useful debug tool there is, and it is about the closest you will get to being able to have the developers sitting right there. Log messages will give clues to what is wrong with the filesystem.

in the end I reflashed the operating system via a Linux computer, but I will keep this in mind in case it happens to me.
Thanks again so much for your availability and help!

Have you bought the cable? It’s not that expensive and useful with many embedded systems. Almost all of them have a serial console that you may need to use. Without console access on Linux you simply miss important messages.

yes I bought it but it has yet to arrive. Since I needed quick access to it this time I reflashed the OS but I will definitely use the cable if it happens again! Thanks again for your interest.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.