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.
Vulkan driver not backfilled: pre-vulkan.sh installs left without Mesa Vulkan ICD
Reported by ki11e6 · filed Jun 14, 2026Closed upstream on 2026-07-18 by dhh. GitHub close reason: completed. No closing PR or commit is recorded — "completed" alone is not evidence of a fix.
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
System details
Intel UHD 630 (CoffeeLake-H) + NVIDIA GTX 1650 Mobile (Optimus laptop), Omarchy 3.8.2
What's wrong?
Systems installed before `install/config/hardware/vulkan.sh` was added (commit 694eb8c6, "Install vulkan drivers by default", 2026-02-20) never get the Mesa Vulkan driver for their iGPU, and no migration backfills it. So Intel/AMD machines installed earlier are left with no Mesa Vulkan ICD.
On this Optimus laptop the effect was concrete and user-visible: NVIDIA Vulkan ships via nvidia-utils (installed at setup by nvidia.sh), so the only Vulkan device present was the NVIDIA dGPU. mpv (default vo=gpu-next/Vulkan) therefore rendered every frame on the discrete GPU and cross-presented to the Intel-driven compositor, which stalled — mpv repeatedly hit "Application Not Responding". Installing vulkan-intel made the iGPU a Vulkan device again and resolved it.
Root cause: install/ scripts only run once at initial setup. vulkan.sh was introduced as an install-time step but no corresponding migrations/*.sh was shipped, so it never reaches pre-existing systems.
Verification on this machine:
- Installed 2026-02-18 (pacman.log first transaction).
- vulkan.sh added 2026-02-20 — two days after install, so it never ran here.
- pacman.log shows vulkan-intel was never installed until I did so manually on 2026-06-14.
- intel-media-driver (from intel/video-acceleration.sh) and nvidia-open-dkms (from nvidia.sh) are present — so the other hardware scripts ran; only the Vulkan driver fell through the gap.
- grep -rl "vulkan-intel\|vulkan-radeon\|VULKAN_DRIVERS" migrations/ → no matches.
Suggested fix
A one-line migration that re-applies the vulkan.sh detection (it uses omarchy-pkg-add, which is idempotent, so it's a no-op on systems that already have the driver). Happy to open a PR — see below.
View raw text
### System details Intel UHD 630 (CoffeeLake-H) + NVIDIA GTX 1650 Mobile (Optimus laptop), Omarchy 3.8.2 ### What's wrong? Systems installed **before `install/config/hardware/vulkan.sh` was added** (commit `694eb8c6`, "Install vulkan drivers by default", 2026-02-20) never get the Mesa Vulkan driver for their iGPU, and **no migration backfills it**. So Intel/AMD machines installed earlier are left with no Mesa Vulkan ICD. On this Optimus laptop the effect was concrete and user-visible: NVIDIA Vulkan ships via `nvidia-utils` (installed at setup by `nvidia.sh`), so the **only** Vulkan device present was the NVIDIA dGPU. mpv (default `vo=gpu-next`/Vulkan) therefore rendered every frame on the discrete GPU and cross-presented to the Intel-driven compositor, which stalled — mpv repeatedly hit "Application Not Responding". Installing `vulkan-intel` made the iGPU a Vulkan device again and resolved it. **Root cause:** `install/` scripts only run once at initial setup. `vulkan.sh` was introduced as an install-time step but no corresponding `migrations/*.sh` was shipped, so it never reaches pre-existing systems. **Verification on this machine:** - Installed `2026-02-18` (`pacman.log` first transaction). - `vulkan.sh` added `2026-02-20` — two days after install, so it never ran here. - `pacman.log` shows `vulkan-intel` was never installed until I did so manually on `2026-06-14`. - `intel-media-driver` (from `intel/video-acceleration.sh`) and `nvidia-open-dkms` (from `nvidia.sh`) are present — so the other hardware scripts ran; only the Vulkan driver fell through the gap. - `grep -rl "vulkan-intel\|vulkan-radeon\|VULKAN_DRIVERS" migrations/` → no matches. ### Suggested fix A one-line migration that re-applies the `vulkan.sh` detection (it uses `omarchy-pkg-add`, which is idempotent, so it's a no-op on systems that already have the driver). Happy to open a PR — see below.
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.