Hello,
I have enabled auto-login and everything was working fine until i installed tensorflow and other stuff and i believe this issue is not because of installing other packages. I think GDM is failing to detect display or some racing problem. also when i restart gdm.service it is working fine.
I have attached gdm.service logs please let me know if any solution.
logs_before_servicerestart.txt (32.6 KB)
Logs after restarting service
Sep 22 09:28:20 ubuntu systemd[1]: Stopping GNOME Display Manager...
Sep 22 09:28:21 ubuntu gdm3[1237]: Child process -2572 was already dead.
Sep 22 09:28:21 ubuntu systemd[1]: gdm.service: Succeeded.
Sep 22 09:28:21 ubuntu systemd[1]: Stopped GNOME Display Manager.
Sep 22 09:28:21 ubuntu systemd[1]: Starting GNOME Display Manager...
Sep 22 09:28:21 ubuntu systemd[1]: Started GNOME Display Manager.
Sep 22 09:28:21 ubuntu gdm-autologin][6312]: gkr-pam: no password is available for user
Sep 22 09:28:21 ubuntu gdm-autologin][6312]: pam_unix(gdm-autologin:session): session opened for user n by (uid=0)
Sep 22 09:28:21 ubuntu gdm-autologin][6312]: gkr-pam: gnome-keyring-daemon started properly
Hi Eldho_K_K,
Are you using the devkit or custom board for Orin NX?
What’s your Jetpack version in use?
Do you have steps to reproduce the issue?
Is your issue about the auto-login or gdm.service?
Hi @KevinFFF,
It is a custom board from seeed studio
Jetpack: 5.1.1
R35 (release), REVISION: 3.1, GCID: 32827747, BOARD: t186ref,
EABI: aarch64, DATE: Sun Mar 19 15:19:21 UTC 2023
I think it is auto-login issue which causing gdm to fail first time after boot
Sep 22 09:17:16 ubuntu gdm-autologin][1243]: pam_unix(gdm-autologin:session): session opened for user n by (uid=0)
Sep 22 09:18:53 ubuntu gdm-autologin][1243]: pam_systemd(gdm-autologin:session): Failed to create session: Connection timed out
Sep 22 09:18:53 ubuntu gdm-autologin][1243]: gkr-pam: unable to locate daemon control file
i think similar issue is mentioned here https://github.com/systemd/systemd/issues/2863
I think the script i have for running in kiosk mode is causing the issue
[Desktop Entry]
Type=Application
Name=Kiosk
Exec=/home/factana/kiosk.sh
X-GNOME-Autostart-enabled=true
am i doing something wrong here?
Is that (Kiosk) your custom application?
If so, what is this application used for?
It seems not included in the default Jetpack release.
Hi @KevinFFF
It is basically to run chromium browser in kiosk mode.
Could you share this application and the usage to cause the auto-login issue?
Have you verified there’s no issue w/o loading this application?
I’m using chromimum-browser to run a web application in kiosk mode
kiosk.sh script is as below
#!/bin/bash
# Run this script in display 0 - the monitor
export DISPLAY=:0
# Hide the mouse from the display
unclutter &
# If Chromium crashes (usually due to rebooting), clear the crash flag so we don't have the annoying warning bar
sed -i 's/"exited_cleanly":false/"exited_cleanly":true/' /home/n/.config/chromium/Default/Preferences
sed -i 's/"exit_type":"Crashed"/"exit_type":"Normal"/' /home/n/.config/chromium/Default/Preferences
# Run Chromium and open tabs
/usr/bin/chromium-browser --kiosk http://localhost &
yes, I have verified it couple of times.
My bad, sometimes it is failing without loading the application too.
So… do you have the exact reproduce steps for this auto-login failed issue?
Well, I’m don’t know how to reproduce this issue maybe i need to refalsh the OS and start from begining.
Also i have a doubt is it because the serial console is open
$ who
n ttyTCU0 2023-09-25 23:57
n ttyAMA0 2023-09-25 23:57
We would need the exact steps to reproduce locally to do further check.
I would suggest verifying with the latest JP5.1.2(R35.4.1) first.
This is combined UART which will output serial console log of MB1/MB2/UEFI/Kernel.
This is the second debug UART which will output kernel logs.
If you don’t want this UART, you could just remove it from kernel command line.
Is there any way to disable it without flashing OS
Please modify the /boot/extlinux/extlinux.conf to remove the entry for /dev/ttyAMA0.
The problem with this board is after when i try falshing using sdkmanager when after falshing OS image it fails to ssh via 192.168.55.1 and the host pc cannot detect it at all, i had seen this issue reported somewhere and since it is custom board whey asked to communicate with seeed studio itself.
If recovery mode detection is failing, then the issue is different versus detection of a fully running Jetson. During a normal flash in recovery mode, the flash will complete, and then the Jetson will self-reboot and no longer be in recovery mode. This is when first boot setup occurs, and when the account which is set up is used via ssh to install some optional packages, e.g., CUDA. When fully booted the default setup creates a device mode virtual ethernet device for the ssh content install, or for other purposes. If this does not run, then the Jetson is also not detected, but it is due to software which fails in a normal boot (not from recovery mode issues).
The serial console itself has no dependencies on being booted or being in recovery mode. The host PC should always detect this even if there is no traffic (this assumes a USB port integrated on the Jetson; the serial console for header pins does not contain USB hardware, and failure to detect a USB serial UART is then a host PC issue rather than being a Jetson issue).
The address 192.168.55.1 is the address assigned to the Jetson upon fully booting and running the virtual USB ethernet. If you use wired ethernet, then you could easily use that instead if you know the address which is assigned by DHCP. If 192.168.55.1 does not fail, but you still can’t install software, it might be because the first boot account setup was never completed (you can’t use ssh without an account).
If 192.168.55.1 fails, then here are some possibilities:
- USB might be failing. USB is just a data pipe with some surrounding intelligence about the device.
- The host PC might be rejecting this address setup due to security. Default Ubuntu will usually “just work”, but Windows, and even some Linux setups, will not blindly accept all mysterious USB devices being plugged in without some sort of ok by the user.
- One can monitor “
dmesg --follow” on the host PC, and then unplug and replug the correct USB cable (the one used for flash, not the serial console), and see what log lines appear. This should differentiate between whether it is a USB issue or a security setup issue or a login name (first boot setup) issue.
- If a VM is involved anywhere, then this is probably an issue about 90% of the time due to incorrect setup.
Note that some third party carrier boards are an exact match for electrical layout compared to the NVIDIA dev kits, and in those cases the third party will state to just use the NVIDIA software. This is kind of rare though, and in most cases the third party will either provide a patch to the NVIDIA software, or else will provide their own flash software (the BSP, or Board Support Package) which is actually patched NVIDIA software. The most common part of that patch is for the device tree. If the device tree is not correct, then you can expect parts of the hardware will simply stop functioning on a fully booted Jetson. One part of this hardware which might fail is USB or ethernet. If 192.168.55.1 fails, and if it isn’t due to security setup of the host PC, then you need to be absolutely certain that the software you used does not have the wrong device tree. Are you certain you are using the correct flash software (mainly the correct device tree)? If you are, then post the log lines appearing due to plugin of the fully booted Jetson’s USB during “dmesg --follow”.
1 Like
192.168.55.1 is from the l4tbr0, which is created from the USB interface.
You could check the serial console log at this moment to know its state.
Hi @linuxdev
Okay… i understand how it works but i don’t think there is any issue with USB data pipe since i have used the same host PC and usb cable to flash jetson nano before.
Host PC i’m using is having ubuntu 18.04 with 8GB RAM
To test this after OS falsh i have removed the board from recovery mode and checked if i can login and I could.
Also, i have a question do i need to remove the jumpers once the OS image flash is done?
Anyways next time i flash i will follow the instructions to see logs.
Just letting you know, I never connect monitor to board when i’m falshing the board so i don’t really know what happens in there while flashing
Hi @KevinFFF
I think the autologin is solved after disabling serial-console.
Weird but it works. I don’t know what is wrong