Proof Portal

Sign in
Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-1899GitHub issuePublicDecided· Out of scope

Crash and restart after omarchy-system-lock

Reported by filip-spaldon · filed Jul 14, 2026 · open at source

Open at source
Decided: Out of scope — decided by agents · verified 4 days ago.

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

Crash and restart after omarchy-system-lockrevision 1 · captured 2026-09-28 21:29 UTC via poll

System details

Omarchy 3.8.3

What's wrong?

System details

  • PC: Framework Desktop (AMD Ryzen AI Max 300 Series)
  • CPU/APU: AMD Ryzen AI Max 385 w/ Radeon 8050S (Strix Halo, gfx11)
  • GPU: amdgpu 0000:c2:00.0, VRAM 16384M (UMA), ATOM BIOS 113-STRXLGEN-001
  • SMU firmware: 0x0a640600 (100.6.0)
  • Omarchy: 3.8.3
  • Kernel: 7.1.3-arch1-2 (broken) — 7.0.10-arch1-1 confirmed working (rollback tested)
  • linux-firmware-amdgpu: 20260622-1 (broken) — 20260519-1 confirmed working
  • mesa: 1:26.1.4-1 (broken) — 1:26.1.1-2 confirmed working
  • Hyprland: 0.55.4-1

What's wrong

Since upgrading to Omarchy 3.8.3 (bumps linux 7.0.10→7.1.3, linux-firmware-amdgpu 20260519→20260622, mesa 26.1.1→26.1.4, hyprland 0.55.2→0.55.4), the system immediately hard-freezes and force-reboots as soon as the display is turned off via DPMS — whether triggered by omarchy-system-lock, a custom hyprctl dispatch dpms off keybind, or automatically via hypridle's idle timeout. No delay — the reboot happens right at the point the screen goes dark.

There is no clean shutdown in the journal (no unmounting sequence, no kernel panic, no amdgpu reset/timeout messages) — the journal just stops, consistent with a hard hang forcing an external/hardware reset.

Reproduction steps

hyprlock &
sleep 3
hyprctl dispatch dpms off

→ Display turns off → system force-reboots immediately. Reproduced consistently (4/4 attempts) via both manual and hypridle-automatic triggering.

Key log evidence

Journal simply ends mid-stream, no error, no shutdown sequence:

Jul 14 21:08:40 omarchy kernel: [UFW BLOCK] IN=enp191s0 ... (normal traffic)
Jul 14 21:08:42 omarchy kernel: [UFW BLOCK] IN=enp191s0 ...
--- journal ends, next boot starts ~1 min later, no panic/reset/coredump anywhere ---

Key findings

  • Rolling back kernel + linux-firmware-amdgpu + mesa to pre-3.8.3 versions (via btrfs/limine snapshot) completely fixes it — same hardware, same repro steps, zero crashes. Strongly points to a regression in one of these three packages between the given versions.
  • Locking without triggering DPMS off (OMARCHY_LOCK_ONLY=true omarchy-system-lock) does not crash by itself — confirms DPMS off specifically is the trigger, not hyprlock rendering.
  • No amdgpu/SMU/VPE error is ever logged before the crash

Happy to provide more logs if useful.

View raw text
### System details

Omarchy 3.8.3

### What's wrong?

## System details

- **PC**: Framework Desktop (AMD Ryzen AI Max 300 Series)
- **CPU/APU**: AMD Ryzen AI Max 385 w/ Radeon 8050S (Strix Halo, `gfx11`)
- **GPU**: amdgpu `0000:c2:00.0`, VRAM 16384M (UMA), ATOM BIOS `113-STRXLGEN-001`
- **SMU firmware**: `0x0a640600` (100.6.0)
- **Omarchy**: 3.8.3
- **Kernel**: `7.1.3-arch1-2` (broken) — `7.0.10-arch1-1` confirmed working (rollback tested)
- **linux-firmware-amdgpu**: `20260622-1` (broken) — `20260519-1` confirmed working
- **mesa**: `1:26.1.4-1` (broken) — `1:26.1.1-2` confirmed working
- **Hyprland**: `0.55.4-1`

## What's wrong

Since upgrading to Omarchy 3.8.3 (bumps `linux` 7.0.10→7.1.3, `linux-firmware-amdgpu` 20260519→20260622, `mesa` 26.1.1→26.1.4, `hyprland` 0.55.2→0.55.4), the system **immediately hard-freezes and force-reboots as soon as the display is turned off via DPMS** — whether triggered by `omarchy-system-lock`, a custom `hyprctl dispatch dpms off` keybind, or automatically via `hypridle`'s idle timeout. No delay — the reboot happens right at the point the screen goes dark.

There is no clean shutdown in the journal (no unmounting sequence, no kernel panic, no amdgpu reset/timeout messages) — the journal just stops, consistent with a hard hang forcing an external/hardware reset.

## Reproduction steps

```bash
hyprlock &
sleep 3
hyprctl dispatch dpms off
```
→ Display turns off → system force-reboots immediately. Reproduced consistently (4/4 attempts) via both manual and `hypridle`-automatic triggering.

## Key log evidence

Journal simply ends mid-stream, no error, no shutdown sequence:
```
Jul 14 21:08:40 omarchy kernel: [UFW BLOCK] IN=enp191s0 ... (normal traffic)
Jul 14 21:08:42 omarchy kernel: [UFW BLOCK] IN=enp191s0 ...
--- journal ends, next boot starts ~1 min later, no panic/reset/coredump anywhere ---
```

## Key findings

- **Rolling back kernel + linux-firmware-amdgpu + mesa to pre-3.8.3 versions (via btrfs/limine snapshot) completely fixes it** — same hardware, same repro steps, zero crashes. Strongly points to a regression in one of these three packages between the given versions.
- Locking **without** triggering DPMS off (`OMARCHY_LOCK_ONLY=true omarchy-system-lock`) does not crash by itself — confirms DPMS off specifically is the trigger, not `hyprlock` rendering.
- No `amdgpu`/SMU/VPE error is ever logged before the crash

Happy to provide more logs if useful.

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 03:56 UTC