exploring systemd hooks to enable pam_luks keyring integration

[d-cas]

Companion PR

A companion PR for the Omarchy ISO enables testing with systemd hooks:
omacom-io/omarchy-iso#60

Both PRs are exploratory, designed to gather data on whether systemd hooks provide enough benefit over the current udev approach to justify the change.

---

What This PR Explores

The current initramfs uses udev-based hooks, which work well. This PR explores whether systemd hooks offer enough additional value to warrant switching.

Not claiming systemd is "better", just different, with different capabilities. This PR exists to empirically determine if those differences matter for Omarchy users.

Inspired by: @kappafon's investigation in #2326 showing encrypt hook limitations with FIDO2 multi-token, and @ryanrhughes's work in #2242 on keyring unlock challenges.

What Both Approaches Share

• Both are actively maintained in Arch
• Both support LUKS encryption
• Both work with UKIs
• udev hooks remain perfectly valid for most users

What We're Testing

Already Confirmed ✅

• FIDO2 Multi-Token: Works with 3+ YubiKeys (addresses Feature Request: Switch to dracut for robust multi-FIDO2 key support with LUKS2 #2326)
• Boot Speed: Noticeably faster due to parallel device discovery
• Diagnostics: journald logging from earliest boot stages
• Fresh Install: Works cleanly via companion ISO PR

Needs Data 🧪

• Boot Speed Numbers: Need systemd-analyze measurements
• Various Hardware: Different configs, edge cases
• pam_luks.so Integration: Potential path to solve Login and UKI updates #2242 keyring issue
• TPM2 Auto-Unlock: Architectural option if Omarchy moves to DM-based authentication (Framework testing available)

Known Trade-offs ⚠️

• More complex configuration than busybox approach
• Migration has risks (high-stakes, requires extensive testing)
• Different debugging paradigm when things go wrong

The Hypothesis

If systemd hooks enable:

1. Faster boot times
2. Future pam_luks.so integration for automatic keyring unlock (Login and UKI updates #2242)
3. FIDO2 multi-token for users who want it (Feature Request: Switch to dracut for robust multi-FIDO2 key support with LUKS2 #2326)
4. Better diagnostics
5. Architectural flexibility: TPM2 auto-unlock as an option if Omarchy decides to move authentication from LUKS to the display manager

Then the trade-offs might be worth it.

If not, we document why and move on.

This PR exists to test that hypothesis.

Changes

Modified install/login/limine-snapper.sh to generate systemd hooks in /etc/mkinitcpio.conf.d/omarchy_hooks.conf:

# Current (udev-based):
HOOKS=(base udev plymouth keyboard autodetect microcode modconf kms keymap consolefont block encrypt filesystems fsck btrfs-overlayfs)

# Testing (systemd-based):
HOOKS=(base systemd plymouth keyboard autodetect microcode modconf kms sd-vconsole block sd-encrypt filesystems fsck sd-btrfs-overlayfs)

Includes optional migration script at migrations/[timestamp].sh for existing installations (not recommended until thoroughly tested).

Testing Status & Results

Fresh Installs (Working) ✅

• VM with LUKS encryption: Clean
• Bare metal daily driver (multiple NVMe): Clean
• FIDO2 multi-token (3+ YubiKeys): Working
• UKI generation: Compatible
• Companion ISO: omarchy-iso#60 tested

Still Gathering Data 🧪

• Boot speed measurements (systemd-analyze)
• TPM2 unlock testing (Framework users needed)
• Various hardware configurations
• Edge cases and failure modes

Migration (Available, Not Recommended Yet) ⚠️

• Script exists and works
• High-stakes due to initramfs sensitivity
• Should only be tested by volunteers who understand the risks
• Fresh installs are the safer path

How to Test

Fresh Install:

1. Use companion ISO PR: omarchy-iso#60
2. Install Omarchy normally
3. Boot and report results

Existing System (Advanced Users Only):

1. Review migration script carefully
2. Have recovery plan ready
3. Test in VM first
4. Report results (success or failure)

What Happens Next

Data gathering is in progress. Based on results:

If benefits outweigh trade-offs: Fresh installs only (following Limine precedent)
If trade-offs too high: Close PR, document findings for community knowledge
If unclear: Opt-in approach or extended testing period

Results will be posted as comments as testing progresses.

Potential synergy with #2242

If this proves beneficial, it opens architectural options:

Option A (current + pam_luks.so):

• User unlocks LUKS with passphrase/FIDO2
• pam_luks.so captures unlock event and unlocks keyring
• SDDM autologin completes
• Result: Single unlock, everything available

Option B (requires TPM2, alternative model):

• TPM2 auto-unlocks LUKS
• User authenticates at SDDM/GDM instead
• Keyring unlocks from DM authentication
• Result: LUKS for encryption, DM for access control

systemd hooks enable both approaches. udev hooks only support Option A (and pam_luks.so hasn't been tested with udev hooks yet).

But we need data to know if it's worth it.

Credits

Thanks to @kappafon for the research in #2326 and @ryanrhughes for the context in #2242 that informed this exploration.

---

Testing Progress

This section will be updated as data comes in.

Boot Speed

• systemd-analyze measurements needed
• Comparison vs current udev approach

TPM2

• Framework laptop testing
• Enrollment process documentation

FIDO2

• Multi-token (3+ YubiKeys): Confirmed working

Hardware Compatibility

• NVIDIA: Working
• AMD: Needs testing
• Various configs: Ongoing

---

This PR remains in draft while we gather data.

[dharmavagabond]

FYI, from limine-snapper-sync docs:

Note: For systemd hooks, use sd-btrfs-overlayfs, since btrfs-overlayfs is incompatible.

[d-cas]

Good catch on the btrfs-overlayfs hook! Will update to use sd-btrfs-overlayfs for systemd compatibility.

[d-cas]

Update: Reframing as Exploration

After Ryan's feedback and more testing, I've reframed this PR as an exploration rather than a recommendation.

What we're testing:

• Boot speed improvement (parallel vs sequential device discovery)
• Path to pam_luks.so integration (potential solution for Login and UKI updates #2242 keyring unlock)
• FIDO2 multi-token support (addresses Feature Request: Switch to dracut for robust multi-FIDO2 key support with LUKS2 #2326)
• Better diagnostics (journald from earliest boot)

Status so far:

• Fresh installs: Working cleanly (VM + bare metal daily driver)
• Daily driver stable: Running systemd hooks on my main system for [X days/weeks] without issues
• Companion ISO PR: omarchy-iso#60 tested and functional
• Migration script: Built and working, but high-stakes (initramfs sensitivity)

Next steps:

1. Get boot speed measurements (systemd-analyze)
2. Test various hardware configurations
3. Document edge cases and failure modes
4. Gather community feedback from testers

The goal: Empirically determine if systemd hooks provide enough benefit over the current udev approach to justify the change. Fresh installs only (per Ryan's Limine precedent) if we proceed.

Will post testing results in this thread as they come in.

[d-cas]

Converting to draft while I determine the best path forward based on maintainer feedback. The migration complexity and testing gaps need to be addressed before this is merge-ready.

[ryanrhughes]

@d-cas did you find any issue with this from a new install state? If this was something that was a better long-term fit (still subject to some testing / review), it could also be something that doesn't have a migration path.

There's no inherent harm in remaining on the legacy architecture and the risks of change may not be worth the rewards.

We had to do a similar thing when we made the decision to use Limine as the boot loader of choice. The risks involved in trying to automatically migrate everyone were just too high.

[d-cas]

No issues on fresh installs so far. VM tested and my daily driver is running the systemd config clean.

Migration is theoretically doable. It's just converting UUID syntax from busybox to systemd format in /etc/default/limine and /etc/mkinitcpio.conf.d/omarchy_hooks.conf, then rebuilding with limine-update. Not as complex as I initially thought. More high-stakes than high-risk since we know the outcome when the syntax is right. Would just need tight testing since initramfs is unforgiving when you get it wrong.

That said, fresh installs only makes way more sense. The big wins are boot speed (noticeably faster, haven't timed it yet) and opening the door to pam_luks.so integration. That could solve the keyring unlock problem from #2242 in a cleaner way. Decrypt once, everything unlocks.

I'll focus on fresh install testing: different hardware configs, edge cases, installer validation.

[d-cas]

Fresh Install Testing Results

Built and tested with companion ISO PR omarchy-iso#60.

System booted successfully with systemd hooks:

Config:

• HOOKS: base systemd plymouth keyboard autodetect microcode modconf kms block sd-vconsole sd-encrypt filesystems fsck sd-btrfs-overlayfs
• Kernel cmdline: rd.luks.name=<UUID>=root (systemd syntax)
• Boot: Clean, no errors
• FIDO2 unlock: Working

Testing continues on bare metal daily driver. Boot speed measurements coming next.

[mlombardi96]

I also took a stab at this a couple of week ago, but I made it a switchable setting instead of the new default. You can check out the code here: master...mlombardi96:omarchy:switchable-initramfs

One thing to note is that I ran into issues running out of password attempts on the Plymouth screen and the entire boot failing. To fix this, I also had to add rd.luks.options=tries=0 to the kernel command line.

[d-cas]

One thing to note is that I ran into issues running out of password attempts on the Plymouth screen and the entire boot failing. To fix this, I also had to add rd.luks.options=tries=0 to the kernel command line.

Killer work @mlombardi96 !

Thanks for the note on password attempts. Really helpful data point at this stage. I updated the code right after you brought it to my attention.

Are you still running the systemd config? Any other gotchas you've run into?

I'm trying to evaluate closely the pros, cons, and risks of systemd vs busybox. Would love to hear what you've learned from running it.

[mlombardi96]

@d-cas I recently did a fresh install so I'm not currently running it. But I never ran into any issues other than the password retry issue.

I didn't notice any meaningful increase or decrease in boot times with the systemd-based config, but it might cause slightly increased boot times for older machines, so that's probably worth testing.