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.
Early thunderbolt module loading in v3.2.3 breaks multi-monitor on discrete GPU systems
Reported by justcarlson · filed Dec 16, 2025Closed 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
MacBook Pro 16" 2019 (MacBookPro16,1), AMD Radeon RX 5500M (dGPU) + Intel UHD 630 (iGPU), CalDigit TS4 Thunderbolt dock, 2 external monitors, Omarchy v3.2.3, Kernel 6.18.1-arch1-Watanare-T2-1-t2
What's wrong?
After updating to v3.2.3, only 1 of 2 external monitors is detected. This is a regression introduced by PR #1894 which added early thunderbolt module loading to mkinitcpio.
Root Cause
The thunderbolt module loading in initramfs causes a race condition with discrete GPU initialization:
thunderbolt: device links to tunneled native ports are missing!
thunderbolt: 0:6 <-> 3:14 (DP): not active, tearing down <-- DP tunnel destroyed
amdgpu: initializing kernel modesetting <-- GPU loads 2 sec laterThe thunderbolt controller tears down DisplayPort tunnels before the GPU driver is ready to claim them. This affects systems where external monitors are connected via DP-over-Thunderbolt tunneling through a discrete GPU.
Evidence
- Fresh install of older ISO: both monitors work
- After
omarchy updateto v3.2.3: only 1 monitor detected - Swapping dock ports: switches which monitor works (confirms dock/cables are fine)
/sys/class/drm/card3-DP-7/statusshowsdisconnectedat kernel level
Fix
Removing the early thunderbolt module loading resolves the issue:
sudo rm /etc/mkinitcpio.conf.d/thunderbolt_module.conf
sudo mkinitcpio -P
sudo rebootAfter reboot, both monitors are detected correctly. Thunderbolt functionality is preserved (module loads at runtime instead of early boot).
Suggested Solution
The fix from #1894 helps systems that need Plymouth on Thunderbolt displays, but breaks multi-monitor on discrete GPU systems. Possible solutions:
1. Don't load thunderbolt early by default - let it load at runtime (breaks Plymouth on TB displays)
2. Also load GPU modules early - add amdgpu, i915, etc. to initramfs alongside thunderbolt
3. Make it opt-in - document the thunderbolt early loading as optional for users who need it
Related
- #1893 - Original issue that prompted #1894
- #1894 - PR that introduced the thunderbolt early loading
View raw text
### System details MacBook Pro 16" 2019 (MacBookPro16,1), AMD Radeon RX 5500M (dGPU) + Intel UHD 630 (iGPU), CalDigit TS4 Thunderbolt dock, 2 external monitors, Omarchy v3.2.3, Kernel 6.18.1-arch1-Watanare-T2-1-t2 ## What's wrong? After updating to v3.2.3, only 1 of 2 external monitors is detected. This is a regression introduced by PR #1894 which added early `thunderbolt` module loading to mkinitcpio. ## Root Cause The thunderbolt module loading in initramfs causes a race condition with discrete GPU initialization: ``` thunderbolt: device links to tunneled native ports are missing! thunderbolt: 0:6 <-> 3:14 (DP): not active, tearing down <-- DP tunnel destroyed amdgpu: initializing kernel modesetting <-- GPU loads 2 sec later ``` The thunderbolt controller tears down DisplayPort tunnels before the GPU driver is ready to claim them. This affects systems where external monitors are connected via DP-over-Thunderbolt tunneling through a discrete GPU. ## Evidence - Fresh install of older ISO: **both monitors work** - After `omarchy update` to v3.2.3: **only 1 monitor detected** - Swapping dock ports: **switches which monitor works** (confirms dock/cables are fine) - `/sys/class/drm/card3-DP-7/status` shows `disconnected` at kernel level ## Fix Removing the early thunderbolt module loading resolves the issue: ```bash sudo rm /etc/mkinitcpio.conf.d/thunderbolt_module.conf sudo mkinitcpio -P sudo reboot ``` After reboot, both monitors are detected correctly. Thunderbolt functionality is preserved (module loads at runtime instead of early boot). ## Suggested Solution The fix from #1894 helps systems that need Plymouth on Thunderbolt displays, but breaks multi-monitor on discrete GPU systems. Possible solutions: 1. **Don't load thunderbolt early by default** - let it load at runtime (breaks Plymouth on TB displays) 2. **Also load GPU modules early** - add `amdgpu`, `i915`, etc. to initramfs alongside thunderbolt 3. **Make it opt-in** - document the thunderbolt early loading as optional for users who need it ## Related - #1893 - Original issue that prompted #1894 - #1894 - PR that introduced the thunderbolt early loading
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.