In your above screenshot, was this taken in local text mode? Or was that via ssh? It seems likely this is only the GUI software failing.
What do you see from:
sudo -s
cat `find /sys -name edid`
exit
If possible you might provide a serial console boot log. See:
http://www.jetsonhacks.com/2017/03/24/serial-console-nvidia-jetson-tx2/
Also, you will have either a log “Xorg.0.log” or “Xorg.1.log”. Go to “/var/log” and post a copy of the log (you can save a copy of the log with a “.txt” name extension and you can attach to the thread).
On the monitor connected to jetson, when it booted displayed this “Started update UTMP about System Runlevel changes”
I pressed ctrl + alt + F3 and it brought me to login into the jetson
So the second image I uploaded is from jetson
This confirms that the system is up and running normally, but the GUI itself is failing. The earlier question for the Xorg log and the command to find EDID data is to help find out why the GUI fails.
For following command
sudo -s
cat find /sys -name edid
I get the output as shown in image.
And unfortunately I don’t have USB serial module in hand with me to provide log.
Is it any other way possible to find why that when jetson connected to HDMI gets stuck…
You have EDID, and this is the most important part. On the other hand, I can’t see if the checksum is valid since it is a screenshot, but it is rare for a checksum to be bad. I would say that the configuration is possible if there is nothing unusual about the modes the monitor supports.
The Xorg log is the part which tells us more about why X fails to start. Do you have ssh access? If you do, then you can save the text file of the Xorg log instead of just a screenshot.
That is the correct log and much seems “normal” (other than seeing input devices and then removing them). I am going to suggest adding extra debug to the log. The way to do this is with a minor edit to “/etc/X11/xorg.conf”.
Within xorg.conf (human readable and you can edit) you will see:
Section "Device"
Somewhere in that section add this (specific location does not matter):
Option "ModeDebug"
Then reboot, and attach the new Xorg log. The debug mode will give very explicit driver comments on what is going on.
This log shows everything goes quite well until the very end. The Acer monitor has a large number of accepted video modes for the mode pool, and keyboard/mouse are momentarily added.
Then comes the part at the end which I don’t understand: The input devices are removed. Someone from NVIDIA will probably need to look at this, but so far as I can see, the whole X setup and run works well, udev passes the input devices in, and then the input devices are mysteriously removed.
Few days ago I remember choosing my display manager to lightdm.
I choose for the reason it’s fast.
But for the issue now, I thought I would change the display manager to gdm3.
And I did. So, finally I can see ubuntu normal boot.
Everything solved now
I thank you for your support.