Proof Portal

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-78GitHub issuePublicDecided· Out of scope

blank black screen

Reported by abdrezzakboumediene · filed Sep 26, 2026 · open at source

Decided: Out of scope — decided by agents · verified 3 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

blank black screenrevision 1 · captured 2026-09-28 21:23 UTC via poll

System details

it is mentioned down here

What's wrong?

Describe the Bug

After installing Omarchy 4.0.4-1, the system boots to a blank black screen with no desktop, no bar, and no terminal. Super+Return does nothing. SDDM autologin succeeds but the graphical session never appears.

Steps to Reproduce

  1. Install Omarchy 4.0.4-1 on a system
  2. Boot and wait for SDDM autologin
  3. Observe: blank black screen, no desktop environment

Expected Behavior

After autologin, the Omarchy desktop (Hyprland + uwsm + Omarchy shell/bar) should appear.

System Information

  • Omarchy: 4.0.4-1
  • Kernel: 7.2.5-3-omarchy
  • CPU: Intel Celeron 925 @ 2.30GHz (1 core, Penryn, 2008)
  • GPU: Intel Mobile 4 Series Integrated Graphics (Sandy Bridge, i915 driver)
  • RAM: 4GB
  • Display: LVDS-1, 1366x768 @ 60Hz
  • Machine: eMachines eME528 (HM55-MV motherboard)
  • Firmware: Phoenix BIOS 1.3408 (02/14/2011)

Full debug: omarchy debug --no-sudo --print

Investigation

Issue A: Session file not in SDDM search path

The omarchy.desktop Wayland session file is installed to /usr/local/share/wayland-sessions/omarchy.desktop but SDDM only searches /usr/share/wayland-sessions/ for session files.

SDDM log shows it reads the file from the non-standard location:

Reading from "/usr/local/share/wayland-sessions/omarchy.desktop"
Session "/usr/local/share/wayland-sessions/omarchy.desktop" selected, command: "uwsm start -g -1 -e -D Hyprland hyprland.desktop" for VT 1

This may not work on all SDDM configurations. The file should also be installed to /usr/share/wayland-sessions/ (the standard location per freedesktop.org spec).

Issue B: Session exits immediately after autologin

After the session is launched, SDDM shows the session starting then immediately removing the display:

Session started true
Auth: sddm-helper exited successfully
Removing display SDDM::Display(0x5f7fc82e6730) ...

The omarchy.desktop session uses:

Exec=uwsm start -g -1 -e -D Hyprland hyprland.desktop

The -g -1 flag tells uwsm to use the greeter's display. After autologin, the greeter session is torn down and the display is removed — so the user session has nothing to attach to and exits.

Fix: Remove -g -1 from the Exec line (change to uwsm start -e -D Hyprland hyprland.desktop).

Issue C: No Hyprland process after boot

After boot, hyprctl returns HYPRLAND_INSTANCE_SIGNATURE not set! (is hyprland running?) — confirming Hyprland never started. No Hyprland process visible in ps aux.

Proposed Fixes

  1. Install omarchy.desktop to /usr/share/wayland-sessions/ in addition to /usr/local/share/wayland-sessions/
  2. Remove the -g -1 flag from the uwsm command in omarchy.desktop, or use a different display handoff approach for autologin
  3. Investigate whether SDDM's CompositorCommand=start-hyprland -- --config /usr/share/sddm/hyprland.lua in the [Wayland] section conflicts with the omarchy.desktop session launch

Additional Context

  • SDDM autologin enabled: User=abdo, Session=omarchy.desktop
  • Older GPU (Intel HD Graphics 2000, Sandy Bridge) — unknown if relevant
  • Issue may be specific to autologin; manual login at SDDM may behave differently
View raw text
### System details

it is mentioned down here

### What's wrong?

## Describe the Bug

After installing Omarchy 4.0.4-1, the system boots to a blank black screen with no desktop, no bar, and no terminal. Super+Return does nothing. SDDM autologin succeeds but the graphical session never appears.

## Steps to Reproduce

1. Install Omarchy 4.0.4-1 on a system
2. Boot and wait for SDDM autologin
3. Observe: blank black screen, no desktop environment

## Expected Behavior

After autologin, the Omarchy desktop (Hyprland + uwsm + Omarchy shell/bar) should appear.

## System Information

- **Omarchy:** 4.0.4-1
- **Kernel:** 7.2.5-3-omarchy
- **CPU:** Intel Celeron 925 @ 2.30GHz (1 core, Penryn, 2008)
- **GPU:** Intel Mobile 4 Series Integrated Graphics (Sandy Bridge, i915 driver)
- **RAM:** 4GB
- **Display:** LVDS-1, 1366x768 @ 60Hz
- **Machine:** eMachines eME528 (HM55-MV motherboard)
- **Firmware:** Phoenix BIOS 1.3408 (02/14/2011)

Full debug: `omarchy debug --no-sudo --print`

## Investigation

### Issue A: Session file not in SDDM search path

The `omarchy.desktop` Wayland session file is installed to `/usr/local/share/wayland-sessions/omarchy.desktop` but SDDM only searches `/usr/share/wayland-sessions/` for session files.

SDDM log shows it reads the file from the non-standard location:
```
Reading from "/usr/local/share/wayland-sessions/omarchy.desktop"
Session "/usr/local/share/wayland-sessions/omarchy.desktop" selected, command: "uwsm start -g -1 -e -D Hyprland hyprland.desktop" for VT 1
```

This may not work on all SDDM configurations. The file should also be installed to `/usr/share/wayland-sessions/` (the standard location per freedesktop.org spec).

### Issue B: Session exits immediately after autologin

After the session is launched, SDDM shows the session starting then immediately removing the display:
```
Session started true
Auth: sddm-helper exited successfully
Removing display SDDM::Display(0x5f7fc82e6730) ...
```

The `omarchy.desktop` session uses:
```
Exec=uwsm start -g -1 -e -D Hyprland hyprland.desktop
```

The `-g -1` flag tells uwsm to use the greeter's display. After autologin, the greeter session is torn down and the display is removed — so the user session has nothing to attach to and exits.

**Fix:** Remove `-g -1` from the Exec line (change to `uwsm start -e -D Hyprland hyprland.desktop`).

### Issue C: No Hyprland process after boot

After boot, `hyprctl` returns `HYPRLAND_INSTANCE_SIGNATURE not set! (is hyprland running?)` — confirming Hyprland never started. No Hyprland process visible in `ps aux`.

## Proposed Fixes

1. Install `omarchy.desktop` to `/usr/share/wayland-sessions/` in addition to `/usr/local/share/wayland-sessions/`
2. Remove the `-g -1` flag from the uwsm command in `omarchy.desktop`, or use a different display handoff approach for autologin
3. Investigate whether SDDM's `CompositorCommand=start-hyprland -- --config /usr/share/sddm/hyprland.lua` in the `[Wayland]` section conflicts with the `omarchy.desktop` session launch

## Additional Context

- SDDM autologin enabled: `User=abdo`, `Session=omarchy.desktop`
- Older GPU (Intel HD Graphics 2000, Sandy Bridge) — unknown if relevant
- Issue may be specific to autologin; manual login at SDDM may behave differently

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:50 UTC