Cinnamon is stuck in a loop on the login screen

Desktop Environments Cinnamon
1

Hello everyone,

I stopped using EndeavourOS months ago—back in January 2026, I believe.

Following an update, I’ve been stuck in a continuous loop at the login screen (LightDm, it seems).

I am able to log in via chroot, and I recently performed all the necessary updates, but that hasn’t resolved the issue.

Note: I recall seeing a post about this back then, but I never got around to addressing it. Interestingly, the same problem also occurred when I was using Debian Sid (which was also buggy at the time).

I’ve included my graphics card specifications below. Thanks for your help!

Graphics:
Device-1: Intel HD Graphics 6000 vendor: Apple driver: i915 v: kernel
arch: Gen-8 ports: active: HDMI-A-1,eDP-1 empty: DP-1,DP-2,HDMI-A-2
bus-ID: 00:02.0 chip-ID: 8086:1626 class-ID: 0300
Display: x11 server: X.Org v: 21.1.11 with: Xwayland v: 23.2.6 driver: X:
loaded: modesetting unloaded: fbdev,vesa dri: iris gpu: i915 display-ID: :0
screens: 1

2

Maybe a timeshift has stolen your free space? I remember in LinuxMint a lot of people had those ligin loops because of not enough free space.

3

hello, I don’t think so,

root@falke-MacBookAir /]# df -h
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/nvme0n1p2 931G 528G 403G 57% /
/dev/nvme0n1p2 931G 528G 403G 57% /home
/dev/nvme0n1p2 931G 528G 403G 57% /var/log
/dev/nvme0n1p2 931G 528G 403G 57% /var/cache
udev 3,7G 0 3,7G 0% /dev
tmpfs 3,9G 8,0K 3,9G 1% /dev/shm
tmpfs 785M 9,8M 775M 2% /run
tmpfs 5,0M 12K 5,0M 1% /run/lock
tmpfs 785M 196K 785M 1% /run/user/1000
/dev/nvme0n1p1 1022M 739M 284M 73% /boot/efi

4

Hey, I run your issue via my LLM agent, this is the solution:

Since disk space is clearly fine (~400 GB free), a LightDM login loop after a long update hiatus (January until now) and maintenance in chroot is typically caused by one of two things:

#### 1. Session Authority / Permissions owned by Root

When doing updates or rescue work in chroot or running commands with sudo, root frequently takes ownership of session token files in your user’s home directory. If LightDM cannot write or lock .Xauthority, it immediately bounces back to the greeter:

From a TTY (Ctrl+Alt+F3) or chroot:

ls -la /home/<your-username>/.Xauthority /home/<your-username>/.ICEauthority

If either is owned by root:root, reclaim ownership:

sudo chown <your-username>:<your-username> /home/<your-username>/.Xauthority /home/<your-username>/.ICEauthority 
# Also ensure \~/.cache is owned by you: 
sudo chown <your-username>:<your-username> /home/<your-username>/.cache

#### 2. Unmerged PAM .pacnew files

A 10-month gap in updates on Arch/EndeavourOS almost certainly dropped .pacnew files in PAM (pambase updates). If /etc/pam.d/system-login.pacnew or lightdm.pacnew was left unmerged, pam_open_session fails during login while LightDM itself appears “active (running)”:

# Check if you have unmerged PAM configs: 
ls -la /etc/pam.d/\*.pacnew

If found, review and merge them using pacdiff or meld.

#### 3. Inspect the session error log

To see the exact reason LightDM or Cinnamon aborted:

journalctl -u lightdm -b 0 -n 50 
cat /home/<your-username>/.xsession-errors

──────
*(Tip: If you’d rather run a quick, automated health check across your system from TTY/chroot, you can check out the read-only sys-health https://github.com/Gbur79/Sys-Health diagnostic utility: sys-health --audit. It specifically tests for root-owned desktop authority files, PAM .pacnew collisions,
broken drivers, and systemd session failures).