SDDM login loop or password not accepted on Omarchy

There are two very different failures behind “Omarchy will not let me log in”, and they need opposite fixes. Either the greeter rejects your password, or the greeter accepts it and the session dies a second later and drops you back. Everything below was checked against the 4.0.4 source tree, with 3.x differences called out.

The fix

1. Decide which failure you have. Get a text console with Ctrl+Alt+F2, log in, then run:

   journalctl -u sddm -b | tail -40

   Lines like pam_unix(sddm:auth): authentication failure or [PAM] authenticate: Authentication failure mean the password was rejected. Go to step 2. A clean Session started true followed by the greeter returning a second later means authentication succeeded and the session crashed. Skip to step 6.

2. Check whether you are simply locked out. Omarchy raises the failure limit to ten attempts in /etc/security/faillock.conf and writes unlock_time=120 into /etc/pam.d/system-auth, so a lockout normally clears itself after two minutes.

   faillock --user "$USER"
   sudo faillock --reset --user "$USER"

   The manual covers this under Troubleshooting. If the output was empty, you were never locked out, and the password really is arriving wrong.

3. Fix the greeter keyboard layout. This is the single most common cause on any non-US layout. Check what the system thinks your layout is:

   localectl status
   grep -E 'KEYMAP|XKBLAYOUT|XKBVARIANT' /etc/vconsole.conf

   On 4.x, edit /usr/share/sddm/hyprland.lua and add an input table to the existing call:

   hl.config({
     input = {
       kb_layout = "fr",
       kb_variant = "",
     },
   
     misc = {
       disable_hyprland_logo = true,
       disable_splash_rendering = true,
       force_default_wallpaper = 0,
     },
   
     animations = {
       enabled = false,
     },
   })

   On 3.x the file is /usr/share/sddm/hyprland.conf and the syntax is the old block form:

   input {
     kb_layout = fr
   }

   On 4.x the .lua file belongs to the omarchy-settings package, so a package upgrade can overwrite it. Re-apply the edit after updates until this lands upstream. On 3.x, issue #6880 found hyprland.conf was not owned by any package, and its reporter kept the edit in a separate file under /etc/sddm/ pointed at by a CompositorCommand drop-in instead.

4. If you cannot edit anything yet, type the password in US positions. The greeter is a plain US QWERTY keyboard no matter what the label on the key says. Several reporters got in this way and fixed the config afterwards.

5. Check that SDDM knows who you are. Two files matter:

   cat /etc/sddm.conf.d/autologin.conf
   cat /var/lib/sddm/state.conf

   User= must be your account. In issue #5044 it had been written as root, which loops forever. In issue #7949, after an interrupted install resumed through arch-chroot, SDDM authenticated an empty username and logged User not known to the underlying authentication module; writing a correct [Autologin] block was the workaround there.

6. If the password is accepted and the session dies, the compositor is failing, not PAM. Read journalctl -b | grep -Ei 'hyprland|aquamarine|uwsm_env-preloader' and check ~/.cache/hyprland/ for a crash report. Three causes have clear reports: an NVIDIA kernel and userspace mismatch after an update, a colon-bearing AQ_DRM_DEVICES value, and a shell error in ~/.config/uwsm/env.d/. Those are covered on /fix/black-screen-after-login/.

Verify it worked

Log out from the Omarchy menu rather than rebooting, so you meet the real greeter instead of autologin. Type one layout-sensitive character into the username field first, such as the at sign or the underscore, and confirm it appears correctly. Then log in normally. Afterwards, journalctl -u sddm -b | grep -c 'Authentication failure' should return zero for that boot.

Why it happens

SDDM starts a Wayland greeter by launching its own Hyprland instance. Omarchy’s /etc/sddm.conf.d/10-wayland.conf sets CompositorCommand=start-hyprland -- --config /usr/share/sddm/hyprland.lua, and that config is deliberately minimal: in the 4.0.4 tree it declares only misc and animations. Hyprland has no reason to look at /etc/vconsole.conf or /etc/X11/xorg.conf.d/00-keyboard.conf, so kb_layout stays at its built-in default of us.

The session is fine, which is what makes this so confusing. Since 4.0.0 the shipped default/hypr/input.lua reads /etc/vconsole.conf at runtime and derives kb_layout, kb_variant and kb_options from it. The greeter never got the same treatment. Two pull requests offered to share that logic, #9177 and #11293, and neither was merged.

Autologin hides the bug. On an encrypted install the LUKS passphrase already gates access, so omarchy-provision-owner keeps the autologin drop-in permanently, and the sddm-autologin PAM service never checks a password at all. The first time you actually see the greeter is after a logout or a compositor crash, long after install, with nothing pointing at the layout. AltairSD described exactly that sequence in issue #10269.

One more trap worth knowing: SDDM does not filter /etc/sddm.conf.d by file extension, so a renamed autologin.disabled is still read. Move the file out of the directory instead.

If that did not work

• The loop started right after an update. A failed DKMS build can leave a stale UKI whose embedded NVIDIA module no longer matches userspace, and Hyprland then aborts at EGL init. Issue #5706 walks through it. See /fix/nvidia-drivers-omarchy-4/.
• You edited your monitor config recently. In issue #6439 a fixed resolution and refresh rate made Hyprland fail silently; switching that entry to preferred restored login. See /fix/monitors-conf-replaced-by-monitors-lua/.
• You changed your password from the Omarchy menu. Issue #9147 reports gkr-pam: couldn't unlock the login keyring. and a reset progress bar on the next cold boot, because the keyring was not re-encrypted with the new password. That one is open and unfixed.
• The machine reboots instead of looping. On a ThinkPad T470 in issue #8190, a TPM that answered but timed out failed the PCR barrier unit and forced a reboot right after the password. Disabling the Security Chip in firmware was the workaround.
• No console key works. One commenter in #5706 could not reach any TTY from the loop. Reboot, pick an older entry in the Limine menu, and work from there. See /fix/stuck-at-tty-or-cannot-switch-tty/ and /upgrade/rollback-with-snapper-and-limine/.

Evidence for the keymap cause is strong and reproduced across fr, be, de, es, gb, Colemak and Russian layouts. Evidence for the keyring and TPM cases is a single report each, so treat those as leads rather than known answers.

Related

• /fix/black-screen-after-login/
• /fix/lock-screen-wont-unlock/
• /fix/luks-passphrase-not-accepted-at-boot/
• /switch/non-us-keyboard-layout-luks-sddm/
• /keyboard/layouts-and-locale/