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

Boot failure: depmod runs before DKMS, leaving modules.dep stale for mkinitcpio

Reported by amlucas0xff · filed Mar 15, 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

Boot failure: depmod runs before DKMS, leaving modules.dep stale for mkinitcpiorevision 1 · captured 2026-09-28 21:29 UTC via poll

Problem

After pacman -Syu upgrades the kernel, the system drops to emergency mode on next boot.

Root cause: Pacman hook execution order creates a race condition:

60-depmod              → builds modules.dep (DKMS modules not built yet)
70-dkms-install        → builds nvidia.ko, xpadneo.ko, etc.
90-mkinitcpio-install  → tries to include nvidia modules, but modules.dep
                          doesn't list them → ERROR → skips UKI rebuild

The old UKI stays on the ESP with the previous kernel version. On reboot, the kernel looks for modules in /usr/lib/modules/<old-version>/ which no longer exists. Emergency mode.

Affected setup: Any Omarchy install using nvidia-open-dkms (or any DKMS module) + Limine UKI boot.

Reproduction

  1. Have nvidia-open-dkms and limine-mkinitcpio-hook installed
  2. Run pacman -Syu when a new kernel version is available
  3. Reboot → emergency mode
  4. Chroot and inspect: ls /usr/lib/modules/*/modules.dep shows no modules.dep, or a stale one missing DKMS modules

Fix

A pacman hook at priority 75 that re-runs depmod after DKMS builds complete:

`/etc/pacman.d/hooks/75-depmod-after-dkms.hook`

[Trigger]
Type = Path
Operation = Install
Operation = Upgrade
Target = usr/lib/modules/*/updates/dkms/*.ko*
Target = usr/lib/modules/*/extramodules/*.ko*

[Action]
Description = Rebuilding module dependencies after DKMS...
When = PostTransaction
Exec = /bin/sh -c 'for d in /usr/lib/modules/*/; do [ -f "${d}modules.order" ] && depmod "$(basename "$d")"; done'

Corrected execution order:

60-depmod              → initial modules.dep
70-dkms-install        → builds DKMS modules
75-depmod-after-dkms   → re-indexes modules.dep with DKMS output
90-mkinitcpio-install  → builds UKI with all modules present

Notes

  • The upstream fix belongs in limine-entry-tool, filed there as well
  • Related: #4827 (missing DKMS packages), #4781
  • This hook only fires when DKMS actually produces .ko files, no wasted runs otherwise
View raw text
## Problem

After `pacman -Syu` upgrades the kernel, the system drops to emergency mode on next boot.

**Root cause:** Pacman hook execution order creates a race condition:

```
60-depmod              → builds modules.dep (DKMS modules not built yet)
70-dkms-install        → builds nvidia.ko, xpadneo.ko, etc.
90-mkinitcpio-install  → tries to include nvidia modules, but modules.dep
                          doesn't list them → ERROR → skips UKI rebuild
```

The old UKI stays on the ESP with the previous kernel version. On reboot, the kernel looks for modules in `/usr/lib/modules/<old-version>/` which no longer exists. Emergency mode.

**Affected setup:** Any Omarchy install using `nvidia-open-dkms` (or any DKMS module) + Limine UKI boot.

## Reproduction

1. Have `nvidia-open-dkms` and `limine-mkinitcpio-hook` installed
2. Run `pacman -Syu` when a new kernel version is available
3. Reboot → emergency mode
4. Chroot and inspect: `ls /usr/lib/modules/*/modules.dep` shows no `modules.dep`, or a stale one missing DKMS modules

## Fix

A pacman hook at priority 75 that re-runs `depmod` after DKMS builds complete:

**`/etc/pacman.d/hooks/75-depmod-after-dkms.hook`**

```ini
[Trigger]
Type = Path
Operation = Install
Operation = Upgrade
Target = usr/lib/modules/*/updates/dkms/*.ko*
Target = usr/lib/modules/*/extramodules/*.ko*

[Action]
Description = Rebuilding module dependencies after DKMS...
When = PostTransaction
Exec = /bin/sh -c 'for d in /usr/lib/modules/*/; do [ -f "${d}modules.order" ] && depmod "$(basename "$d")"; done'
```

Corrected execution order:

```
60-depmod              → initial modules.dep
70-dkms-install        → builds DKMS modules
75-depmod-after-dkms   → re-indexes modules.dep with DKMS output
90-mkinitcpio-install  → builds UKI with all modules present
```

## Notes

- The upstream fix belongs in [limine-entry-tool](https://gitlab.com/Zesko/limine-entry-tool), filed there as well
- Related: #4827 (missing DKMS packages), #4781
- This hook only fires when DKMS actually produces `.ko` files, no wasted runs otherwise

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 02:41 UTC