Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
SDDM greeter ignores system keyboard layout, causing silent password-mismatch after autologin is used up
Reported by AltairSD · filed Sep 5, 2026Closed upstream on 2026-09-21 by bjarneo via an automated message, as a duplicate of #6880 (R-1858). GitHub close reason: completed.
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- Not yet mapped to any requirement or component.
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
Title: SDDM greeter ignores system keyboard layout, causing silent password-mismatch after autologin is used up
What happened
On a LUKS-encrypted install, autologin is permanent, and its PAM stack
(sddm-autologin → pam_permit.so) never actually checks the password, so
boot always "succeeds" regardless of what's typed. But when the SDDM greeter
is shown for real (e.g. after logging out), it authenticates via the normalsddm PAM service (pam_unix), and that genuinely fails — because the
greeter's compositor config, /usr/share/sddm/hyprland.lua (from theomarchy-settings package), has no input block at all, so Hyprland falls
back to its default US keyboard layout.
On a non-US keyboard (in my case UK/gb), any password character that sits
differently between layouts ("/@, #/£, ~/#, \/|, etc.) gets
typed as the wrong character, so real authentication at the greeter fails
every time — while autologin masks the bug completely until the user
actually exercises the manual login path.
Meanwhile ~/.config/hypr/input.lua (the real session's Hyprland config)
correctly derives kb_layout/kb_variant/kb_options from/etc/vconsole.conf; the greeter's minimal config just never does the same.
Expected
The SDDM greeter's Hyprland instance should use the system's actual keyboard
layout (from /etc/vconsole.conf, same source input.lua uses), so a
password typed there authenticates correctly.
Steps to reproduce
- Install Omarchy with a non-US keyboard layout (e.g. UK) on an
encrypted disk, so autologin persists.
2. Set a password containing a character whose position/shift-mapping
differs between US and your layout.
3. Boot — autologin succeeds regardless of the password (it isn't checked).
4. Log out, or otherwise trigger the real SDDM greeter, and type the actual
password. Authentication fails (journalctl -u sddm shows
pam_unix(sddm:auth): authentication failure), even though the same
password is correct in every other context (sudo, screen lock in the
real session, etc.).
System details
- Omarchy version: 4.0.2-1
- CPU: Intel Core i9-14900HX
- GPU: Intel Raptor Lake-S UHD Graphics + NVIDIA GeForce RTX 5070 Max-Q (Mobile)
- Keyboard:
gb(UK), set vialocalectl//etc/vconsole.conf - Disk: LUKS-encrypted root (btrfs on
crypto_LUKS)
Suggested fix
Give /usr/share/sddm/hyprland.lua the same read_vconsole() +kb_layout/kb_variant/kb_options logic already used in/usr/share/omarchy/default/hypr/input.lua, so the greeter's compositor
matches the system's real layout instead of defaulting to us.
View raw text
**Title:** SDDM greeter ignores system keyboard layout, causing silent password-mismatch after autologin is used up **What happened** On a LUKS-encrypted install, autologin is permanent, and its PAM stack (`sddm-autologin` → `pam_permit.so`) never actually checks the password, so boot always "succeeds" regardless of what's typed. But when the SDDM greeter is shown for real (e.g. after logging out), it authenticates via the normal `sddm` PAM service (`pam_unix`), and that genuinely fails — because the greeter's compositor config, `/usr/share/sddm/hyprland.lua` (from the `omarchy-settings` package), has no `input` block at all, so Hyprland falls back to its default **US** keyboard layout. On a non-US keyboard (in my case UK/`gb`), any password character that sits differently between layouts (`"`/`@`, `#`/`£`, `~`/`#`, `\`/`|`, etc.) gets typed as the wrong character, so real authentication at the greeter fails every time — while autologin masks the bug completely until the user actually exercises the manual login path. Meanwhile `~/.config/hypr/input.lua` (the real session's Hyprland config) correctly derives `kb_layout`/`kb_variant`/`kb_options` from `/etc/vconsole.conf`; the greeter's minimal config just never does the same. **Expected** The SDDM greeter's Hyprland instance should use the system's actual keyboard layout (from `/etc/vconsole.conf`, same source `input.lua` uses), so a password typed there authenticates correctly. **Steps to reproduce** 1. Install Omarchy with a non-US keyboard layout (e.g. UK) on an encrypted disk, so autologin persists. 2. Set a password containing a character whose position/shift-mapping differs between US and your layout. 3. Boot — autologin succeeds regardless of the password (it isn't checked). 4. Log out, or otherwise trigger the real SDDM greeter, and type the actual password. Authentication fails (`journalctl -u sddm` shows `pam_unix(sddm:auth): authentication failure`), even though the same password is correct in every other context (sudo, screen lock in the real session, etc.). **System details** - Omarchy version: 4.0.2-1 - CPU: Intel Core i9-14900HX - GPU: Intel Raptor Lake-S UHD Graphics + NVIDIA GeForce RTX 5070 Max-Q (Mobile) - Keyboard: `gb` (UK), set via `localectl`/`/etc/vconsole.conf` - Disk: LUKS-encrypted root (btrfs on `crypto_LUKS`) **Suggested fix** Give `/usr/share/sddm/hyprland.lua` the same `read_vconsole()` + `kb_layout`/`kb_variant`/`kb_options` logic already used in `/usr/share/omarchy/default/hypr/input.lua`, so the greeter's compositor matches the system's real layout instead of defaulting to `us`.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
No decision has been recorded yet.