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.
Unable to boot with Intel Arc B60 Pro Creator - triggers monitor factory test loop in early boot
Reported by Geoff-Ilmax · filed Sep 14, 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
MSI X570/AMD - Omarchy 4.0.3, Intel Arc B60 pro creator
What's wrong?
Booting normally drops into an unstable DisplayPort link training state immediately after the Limine phase, causing the displays to panic and enter an inescapable RGBW factory burn-in test loop.Persistent log files (journalctl) fail to cache the failure states because the kernel hard-locks before volatile memory records can write out to the root filesystem storage layers.Booting with nomodeset functions perfectly as a temporary workaround, dropping the environment safely into a hardware acceleration-disabled simpledrm session mapping to card0-Unknown-1. omarchy-debug logs uploaded UwGLaZ
View raw text
### System details MSI X570/AMD - Omarchy 4.0.3, Intel Arc B60 pro creator ### What's wrong? Booting normally drops into an unstable DisplayPort link training state immediately after the Limine phase, causing the displays to panic and enter an inescapable RGBW factory burn-in test loop.Persistent log files (journalctl) fail to cache the failure states because the kernel hard-locks before volatile memory records can write out to the root filesystem storage layers.Booting with nomodeset functions perfectly as a temporary workaround, dropping the environment safely into a hardware acceleration-disabled simpledrm session mapping to card0-Unknown-1. omarchy-debug logs uploaded UwGLaZ
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 13:30 UTC