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.
Login loop after update if nvidia DKMS fails to build for the new kernel
Reported by sanity · filed May 9, 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
Heads up - running omarchy update today put my machine into an unrecoverable login loop. SDDM took my password and bounced straight back to the login screen, no error visible to a normal user. Took me a few hours to figure out, so posting in case the failure mode helps.
What happened
Today's pacman transaction upgraded a bunch of stuff including:
- linux 6.19.13 -> 7.0.3
- linux-lts 6.18.24 -> 6.18.28
- nvidia-open-dkms 595.58.03 -> 595.71.05
DKMS for nvidia-open-dkms 595.71.05 failed to build against both new kernels (GCC internal compiler error in nvidia's source, probably an upstream nvidia bug since 7.0.x isn't in their support matrix yet). The build for the still-running kernel 6.19.13 succeeded.
mkinitcpio then ran via the limine hook for each new kernel and produced:
==> ERROR: module not found: 'nvidia'
==> ERROR: module not found: 'nvidia_modeset'
==> ERROR: module not found: 'nvidia_uvm'
==> ERROR: module not found: 'nvidia_drm'
==> Generating module dependencies
==> Creating zstd-compressed initcpio image
==> WARNING: errors were encountered during the build. The image may not be complete.
==> Creating unified kernel image: '/tmp/staging_uki.efi'
==> Unified kernel image generation successful
ERROR: mkinitcpio failed for kernel 7.0.3-arch1-2, skipping.Note the contradiction in the last two lines. mkinitcpio exits non-zero and limine-mkinitcpio-install correctly skips the mv to /boot, so no new UKI for 7.0.3 or 6.18.28-lts.
The old linux 6.19.13 directory is also still on disk (nice touch, the modules-post hook keeps the running kernel around). But its pkgbase is no longer owned by any installed package, so limine-mkinitcpio-install silently skips it too with the "pacman -Qqo ... &>/dev/null" branch.
Net result: zero UKIs got rebuilt during this transaction. The existing /boot/EFI/Linux/omarchy_linux.efi still contains the OLD nvidia kernel module embedded in initramfs. After reboot:
- Kernel 6.19.13 boots from the stale UKI
- Old nvidia 595.58.03 kernel module loads from the embedded initramfs
- Userspace libGL/libEGL etc are now 595.71.05 on disk from this transaction
- Hyprland aborts in
CHyprOpenGLImpl::initEGLbecause nvidia kernel and userspace versions must match exactly - SDDM's session script exits, SDDM bounces back to the login screen, forever
- From the user's POV: type password, get re-prompted, no error
Why it's hard to catch
- mkinitcpio prints "Unified kernel image generation successful" immediately above "ERROR: mkinitcpio failed for kernel X, skipping". In a
--noconfirmtranscript scrolling past, that looks fine. - The pacman transaction completes with exit 0.
omarchy updatereports success. - Nothing checks "did this transaction produce at least one bootable UKI for any installed kernel before allowing reboot?".
- Once you're stuck at the SDDM loop, no diagnostic tells you Hyprland is crashing. You have to find a TTY and dig through journalctl.
Suggestions
Cheapest fixes first:
- Make
limine-mkinitcpio-installtrack whether any UKI was successfully written in the transaction. If not, print something loud at the end ("no UKI was rebuilt this transaction, DO NOT REBOOT until you have rebuilt one"). Even nicer: drop a marker file that the next SDDM session checks and surfaces as a desktop notification.
- The skip of "pkgbase not owned by any package" silently drops the running kernel from rebuild even when it would have succeeded. At minimum log a warning. Maybe consider rebuilding it anyway when no other UKI got built, since you have the running modules and vmlinuz sitting right there.
- Detect the version mismatch between the loaded
nvidiakernel module and userspace nvidia-utils on session start (or in greeter). A small check could either notify or auto-recover viamodprobe -r/modprobebefore Hyprland tries to come up.
- Long shot: ask upstream mkinitcpio not to print "Unified kernel image generation successful" when it knows the image is incomplete.
Recovery for anyone bricked the same way
If you find this issue while stuck:
# from ctrl-alt-f2 console
sudo systemctl stop sddm
sudo modprobe -r nvidia_drm nvidia_uvm nvidia_modeset nvidia
sudo modprobe nvidia
sudo systemctl start sddm
# log in normally - Hyprland should come upThen before next reboot, rebuild the UKI for your running kernel:
sudo /usr/bin/mkinitcpio --kernel "$(uname -r)" \
--uki /tmp/staging_uki.efi --cmdline /proc/cmdline
sudo mv /tmp/staging_uki.efi /boot/EFI/Linux/<prefix>_linux.efi
# update sha512 hashes in /boot/limine.conf to match new fileSetup
AMD Threadripper, NVIDIA RTX 3090 Ti, btrfs+luks, limine, SDDM, Hyprland.
View raw text
Heads up - running `omarchy update` today put my machine into an unrecoverable login loop. SDDM took my password and bounced straight back to the login screen, no error visible to a normal user. Took me a few hours to figure out, so posting in case the failure mode helps.
### What happened
Today's pacman transaction upgraded a bunch of stuff including:
- `linux` 6.19.13 -> 7.0.3
- `linux-lts` 6.18.24 -> 6.18.28
- `nvidia-open-dkms` 595.58.03 -> 595.71.05
DKMS for nvidia-open-dkms 595.71.05 failed to build against both new kernels (GCC internal compiler error in nvidia's source, probably an upstream nvidia bug since 7.0.x isn't in their support matrix yet). The build for the still-running kernel 6.19.13 succeeded.
mkinitcpio then ran via the limine hook for each new kernel and produced:
```
==> ERROR: module not found: 'nvidia'
==> ERROR: module not found: 'nvidia_modeset'
==> ERROR: module not found: 'nvidia_uvm'
==> ERROR: module not found: 'nvidia_drm'
==> Generating module dependencies
==> Creating zstd-compressed initcpio image
==> WARNING: errors were encountered during the build. The image may not be complete.
==> Creating unified kernel image: '/tmp/staging_uki.efi'
==> Unified kernel image generation successful
ERROR: mkinitcpio failed for kernel 7.0.3-arch1-2, skipping.
```
Note the contradiction in the last two lines. mkinitcpio exits non-zero and `limine-mkinitcpio-install` correctly skips the mv to /boot, so no new UKI for 7.0.3 or 6.18.28-lts.
The old `linux` 6.19.13 directory is also still on disk (nice touch, the modules-post hook keeps the running kernel around). But its pkgbase is no longer owned by any installed package, so `limine-mkinitcpio-install` silently skips it too with the "pacman -Qqo ... &>/dev/null" branch.
Net result: zero UKIs got rebuilt during this transaction. The existing `/boot/EFI/Linux/omarchy_linux.efi` still contains the OLD nvidia kernel module embedded in initramfs. After reboot:
- Kernel 6.19.13 boots from the stale UKI
- Old nvidia 595.58.03 kernel module loads from the embedded initramfs
- Userspace libGL/libEGL etc are now 595.71.05 on disk from this transaction
- Hyprland aborts in `CHyprOpenGLImpl::initEGL` because nvidia kernel and userspace versions must match exactly
- SDDM's session script exits, SDDM bounces back to the login screen, forever
- From the user's POV: type password, get re-prompted, no error
### Why it's hard to catch
- mkinitcpio prints "Unified kernel image generation successful" immediately above "ERROR: mkinitcpio failed for kernel X, skipping". In a `--noconfirm` transcript scrolling past, that looks fine.
- The pacman transaction completes with exit 0. `omarchy update` reports success.
- Nothing checks "did this transaction produce at least one bootable UKI for any installed kernel before allowing reboot?".
- Once you're stuck at the SDDM loop, no diagnostic tells you Hyprland is crashing. You have to find a TTY and dig through journalctl.
### Suggestions
Cheapest fixes first:
1. Make `limine-mkinitcpio-install` track whether *any* UKI was successfully written in the transaction. If not, print something loud at the end ("no UKI was rebuilt this transaction, DO NOT REBOOT until you have rebuilt one"). Even nicer: drop a marker file that the next SDDM session checks and surfaces as a desktop notification.
2. The skip of "pkgbase not owned by any package" silently drops the running kernel from rebuild even when it would have succeeded. At minimum log a warning. Maybe consider rebuilding it anyway when no other UKI got built, since you have the running modules and vmlinuz sitting right there.
3. Detect the version mismatch between the loaded `nvidia` kernel module and userspace nvidia-utils on session start (or in greeter). A small check could either notify or auto-recover via `modprobe -r/modprobe` before Hyprland tries to come up.
4. Long shot: ask upstream mkinitcpio not to print "Unified kernel image generation successful" when it knows the image is incomplete.
### Recovery for anyone bricked the same way
If you find this issue while stuck:
```
# from ctrl-alt-f2 console
sudo systemctl stop sddm
sudo modprobe -r nvidia_drm nvidia_uvm nvidia_modeset nvidia
sudo modprobe nvidia
sudo systemctl start sddm
# log in normally - Hyprland should come up
```
Then before next reboot, rebuild the UKI for your running kernel:
```
sudo /usr/bin/mkinitcpio --kernel "$(uname -r)" \
--uki /tmp/staging_uki.efi --cmdline /proc/cmdline
sudo mv /tmp/staging_uki.efi /boot/EFI/Linux/<prefix>_linux.efi
# update sha512 hashes in /boot/limine.conf to match new file
```
### Setup
AMD Threadripper, NVIDIA RTX 3090 Ti, btrfs+luks, limine, SDDM, Hyprland.
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:54 UTC