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.
Fresh installs missing modules.dep — depmod runs against wrong/no kernel version during installer bootstrap
Reported by CRTFD-DVLPR · filed Sep 12, 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
Summary
On a fresh Omarchy install, the installed kernel's /usr/lib/modules/<version>/modules.dep (and other depmod-generated files) is never created. This silently breaks any subsequent mkinitcpio/UKI rebuild — every module name lookup fails ("module not found" for essentially every module, including core ones like nvme_core, dm_crypt, amdgpu), and the build aborts with "No modules were added to the image."
The failure is safe in the sense that limine-mkinitcpio-install detects the failed build and does not overwrite the existing working UKI — so a system doesn't lose its ability to boot the currently-installed kernel. But it means the very first attempt to rebuild the initramfs/UKI for any reason (kernel update, cmdline change, etc.) fails outright, and the underlying cause (missing modules.dep) is non-obvious from the error output.
Root cause (best guess)
The installer bootstraps the target system with:
pacman -b /mnt//var/lib/pacman/ -r /mnt -Sy --noconfirm --needed ... base sudo linux-firmware mkinitcpio linux btrfs-progs amd-ucodeA depmod pacman hook is present (/usr/share/libalpm/hooks/60-depmod.hook, from kmod) and does fire during this transaction. However, depmod with no explicit kernel-version argument operates against uname -r (the currently running kernel) by default. During installer bootstrap into /mnt, the running kernel is still the live ISO's kernel — the freshly-unpacked target kernel hasn't booted and has no corresponding running process to resolve a version from. So the hook runs, but doesn't generate modules.dep for the actual target kernel version.
Evidence
- Fresh install timestamp:
2026-09-11 11:44(frompacman -Qi linux) pacman.logshows the exact bootstrap invocation above/usr/lib/modules/7.2.3-arch1-3/contained onlykernel/,modules.builtin,modules.builtin.modinfo,modules.order,pkgbase,vmlinuz— nomodules.dep,modules.alias,modules.dep.bin, etc.- Manually running
sudo depmod -a 7.2.3-arch1-3immediately generated a validmodules.dep(942KB), and the nextmkinitcpio/UKI rebuild succeeded cleanly.
Suggested fix
In the installer, explicitly run depmod -a <target-kernel-version> -b /mnt (or equivalent arch-chroot/basedir-aware invocation) after installing the kernel package, rather than relying on the generic 60-depmod.hook to infer the version from the running environment.
Environment
- Omarchy BUILD_ID 4.0.3
- Kernel: 7.2.3-arch1-3
- mkinitcpio 41.1-1, limine-mkinitcpio-hook 1.38.0-1.1
View raw text
## Summary
On a fresh Omarchy install, the installed kernel's `/usr/lib/modules/<version>/modules.dep` (and other depmod-generated files) is never created. This silently breaks any subsequent `mkinitcpio`/UKI rebuild — every module name lookup fails ("module not found" for essentially every module, including core ones like `nvme_core`, `dm_crypt`, `amdgpu`), and the build aborts with "No modules were added to the image."
The failure is safe in the sense that `limine-mkinitcpio-install` detects the failed build and does not overwrite the existing working UKI — so a system doesn't lose its ability to boot the currently-installed kernel. But it means the very first attempt to rebuild the initramfs/UKI for any reason (kernel update, cmdline change, etc.) fails outright, and the underlying cause (missing `modules.dep`) is non-obvious from the error output.
## Root cause (best guess)
The installer bootstraps the target system with:
```
pacman -b /mnt//var/lib/pacman/ -r /mnt -Sy --noconfirm --needed ... base sudo linux-firmware mkinitcpio linux btrfs-progs amd-ucode
```
A `depmod` pacman hook is present (`/usr/share/libalpm/hooks/60-depmod.hook`, from `kmod`) and does fire during this transaction. However, `depmod` with no explicit kernel-version argument operates against `uname -r` (the *currently running* kernel) by default. During installer bootstrap into `/mnt`, the running kernel is still the live ISO's kernel — the freshly-unpacked target kernel hasn't booted and has no corresponding running process to resolve a version from. So the hook runs, but doesn't generate `modules.dep` for the actual target kernel version.
## Evidence
- Fresh install timestamp: `2026-09-11 11:44` (from `pacman -Qi linux`)
- `pacman.log` shows the exact bootstrap invocation above
- `/usr/lib/modules/7.2.3-arch1-3/` contained only `kernel/`, `modules.builtin`, `modules.builtin.modinfo`, `modules.order`, `pkgbase`, `vmlinuz` — no `modules.dep`, `modules.alias`, `modules.dep.bin`, etc.
- Manually running `sudo depmod -a 7.2.3-arch1-3` immediately generated a valid `modules.dep` (942KB), and the next `mkinitcpio`/UKI rebuild succeeded cleanly.
## Suggested fix
In the installer, explicitly run `depmod -a <target-kernel-version> -b /mnt` (or equivalent `arch-chroot`/basedir-aware invocation) after installing the kernel package, rather than relying on the generic `60-depmod.hook` to infer the version from the running environment.
## Environment
- Omarchy BUILD_ID 4.0.3
- Kernel: 7.2.3-arch1-3
- mkinitcpio 41.1-1, limine-mkinitcpio-hook 1.38.0-1.1Validation
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 12:02 UTC