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.
Autologin stays on a black screen for ~30s while pam_gnome_keyring blocks the session
Reported by odcpw · filed Sep 27, 2026 · open at source
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?
- AreaOutside the audited area· Decided by agents · verified
- 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?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
System details
ThinkPad T14 Gen 6, Intel Core Ultra 7 258V, Intel Arc Graphics 130V/140V (8086:64a0, xe). Omarchy 4.0.0.r2304.g7b336b1-1. Kernel 7.2.5-4-omarchy (linux-omarchy 7.2.5-4, installed 2026-09-25 22:12 CEST, first boot 2026-09-27 16:50 CEST). SDDM autologin. Plymouth quiet splash.
What's wrong?
After the boot splash quit, the panel stayed black for about 31 seconds. Hyprland then started normally. The GPU was already up and the backlight was on (69818/174545). Nothing crashed.
SDDM accepted autologin immediately. It did not start the Wayland session until pam_gnome_keyring.so finished. That step blocked for 29.9 seconds. The keyring daemon was started only at the end of the wait, came up in about 100ms, and then logged that it could not unlock the login keyring. Autologin has no password, so the unlock failure itself also happens on a fast boot. The new part is the 30 second wait, with Plymouth already gone and no greeter on screen.
This boot, 2026-09-27:
- 16:50:36.538 Plymouth quit
- 16:50:36.645
gkr-pam: no password is available for user - 16:50:36.651
pam_unix(sddm-autologin:session): session opened - 16:51:06.448
Starting GNOME Keyring daemon(gnome-keyring 1:50.0-1) - 16:51:06.552 daemon started
- 16:51:06.581
gkr-pam: couldn't unlock the login keyring. - 16:51:06.582 Wayland session starts
- 16:51:07.404 Hyprland banner
Previous boot, 2026-09-25, kernel 7.2.5-3-omarchy, same messages, 0.18 seconds from authentication to Session started true, Hyprland up by 16:50:36-equivalent +0.8s.
/etc/pam.d/sddm-autologin (owned by sddm) still has -session optional pam_gnome_keyring.so auto_start. xe initialized in the first second of boot, including fbcon: Deferring console take-over. That did not hold the picture: the stall is the gap inside sddm-helper above.
Expected: the session starts within a second of Plymouth quitting, as on the 2026-09-25 boot.
Saw this once, on the first boot of 7.2.5-4. I can't show from the log that the new kernel caused the keyring wait. What the log shows is that autologin sat in that PAM step for 30 seconds while the screen was black.
View raw text
### System details ThinkPad T14 Gen 6, Intel Core Ultra 7 258V, Intel Arc Graphics 130V/140V (`8086:64a0`, xe). Omarchy `4.0.0.r2304.g7b336b1-1`. Kernel `7.2.5-4-omarchy` (linux-omarchy 7.2.5-4, installed 2026-09-25 22:12 CEST, first boot 2026-09-27 16:50 CEST). SDDM autologin. Plymouth `quiet splash`. ### What's wrong? After the boot splash quit, the panel stayed black for about 31 seconds. Hyprland then started normally. The GPU was already up and the backlight was on (69818/174545). Nothing crashed. SDDM accepted autologin immediately. It did not start the Wayland session until `pam_gnome_keyring.so` finished. That step blocked for 29.9 seconds. The keyring daemon was started only at the end of the wait, came up in about 100ms, and then logged that it could not unlock the login keyring. Autologin has no password, so the unlock failure itself also happens on a fast boot. The new part is the 30 second wait, with Plymouth already gone and no greeter on screen. This boot, 2026-09-27: - 16:50:36.538 Plymouth quit - 16:50:36.645 `gkr-pam: no password is available for user` - 16:50:36.651 `pam_unix(sddm-autologin:session): session opened` - 16:51:06.448 `Starting GNOME Keyring daemon` (gnome-keyring 1:50.0-1) - 16:51:06.552 daemon started - 16:51:06.581 `gkr-pam: couldn't unlock the login keyring.` - 16:51:06.582 Wayland session starts - 16:51:07.404 Hyprland banner Previous boot, 2026-09-25, kernel `7.2.5-3-omarchy`, same messages, 0.18 seconds from authentication to `Session started true`, Hyprland up by 16:50:36-equivalent +0.8s. `/etc/pam.d/sddm-autologin` (owned by sddm) still has `-session optional pam_gnome_keyring.so auto_start`. xe initialized in the first second of boot, including `fbcon: Deferring console take-over`. That did not hold the picture: the stall is the gap inside `sddm-helper` above. Expected: the session starts within a second of Plymouth quitting, as on the 2026-09-25 boot. Saw this once, on the first boot of 7.2.5-4. I can't show from the log that the new kernel caused the keyring wait. What the log shows is that autologin sat in that PAM step for 30 seconds while the screen was black.
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.
- Out of scopeDecided by agents · verified · 2026-10-09 19:22 UTC