systemd: Add overlay for systemd to change token prompts type

[vunnyso]

Description of Changes

Use PAM_TEXT_INFO for security token prompts in systemd-homed.

The prompts for security token interaction were previously sent as error messages. This commit changes them to informational messages.

Additionally, the unused patch for a soft-lock in cosmic-greeter has been removed.

Upstream patch link: systemd/systemd#40412 (Merged)

Type of Change

• New Feature
• Bug Fix
• Improvement / Refactor

Related Issues / Tickets

Checklist

• Clear summary in PR description
• Detailed and meaningful commit message(s)
• Commits are logically organized and squashed if appropriate
• Contribution guidelines followed
• Ghaf documentation updated with the commit - https://tiiuae.github.io/ghaf/
• Author has run make-checks and it passes
• All automatic GitHub Action checks pass - see actions
• Author has added reviewers and removed PR draft status

Testing Instructions

Applicable Targets

• Orin AGX aarch64
• Orin NX aarch64
• Lenovo X1 x86_64
• Dell Latitude x86_64
• System 76 x86_64

Installation Method

• Requires full re-installation
• Can be updated with nixos-rebuild ... switch
• Other:

Test Steps To Verify:

1. Fixes https://jira.tii.ae/browse/SSRCSP-7830

[milva-unikie]

Our remote builder is struggling to build the laptop targets with this, they all failed after trying to build for a couple of hours yesterday. I will try to trigger the laptop builds one at a time to hopefully get them to complete the build.

[leivos-unikie]

I built lenovo-x1 image locally and booted from USB SSD.

Yubikey functionality seems to work now, except if booting without Yubikey (after local user with Yubikey has been created). Then it does not provide any opportunity to log in with password only.

If Yubikey is unplugged when logged in then it locks the screen and does accept password at Lock screen. If user is then logged out while Yubikey not connected, logging in with password is not possible.

If device is booted to login screen without Yubikey log in does not work via Yubikey after plugging it in.

[ktusawrk]

The build was stuck for hours with low load and low CPU usage in the remote builder. So it's not about a massive rebuild. I fed remote builder ps aux listing to Copilot:

Nothing is “wedged” at the OS level. Your build is blocked in test phases, so the machine shows low CPU and load while nix-build processes wait on their deps. Disable or patch those tests and the build should proceed.

A bit more detailed investigation

For PID 1077942 (a pytest runner using /nix/store/qzc0…-python3-3.13.11/bin/python3.13), strace only reports futex() syscalls—no connect(), poll()/select(), recvfrom()/sendto() or other I/O:
futex(... FUTEX_WAIT_BITSET_PRIVATE ...)
futex(... FUTEX_WAKE_PRIVATE ...)

That pattern means the Python process is waiting on a userspace lock/condition (threading condition, queue, or similar), i.e., idle and blocked, not doing network I/O and not CPU‑bound. Combined with the low CPU and the dozens of similar long‑lived pytest processes in your ps aux, this points to a test‑runner coordination stall—not a kernel or scheduler problem, and not (anymore) a network‑blocked test.
In practice, this usually means:

A pytest worker (or the “master” process if you use xdist) is blocked or deadlocked, and the other workers are just waiting on a work queue / barrier; or
The test collection/fixture teardown got stuck in one process, leaving the rest waiting on a global condition; or
The build recipe starts many pytest shards as separate processes; most of them finished their chunks early and are now parked on a condition variable waiting for orchestrator completion.

Your command line confirms it’s a pytest invocation with a long -k expression and many --deselect filters:
python3.13 -m pytest tests/unittest ... -k 'not (...) and not (...) ...'

Why this explains “stuck with low load”

The pytest processes are alive (so Nix thinks the step is running), but they’re all waiting on a futex.
The top‑level image derivations (…ghaf-host-disko-images.drv) therefore wait on these test derivations to finish; nothing else can progress, so the machine is mostly nix-store --serve and background daemons.

[henrirosten]

Our remote builder is struggling to build the laptop targets with this, they all failed after trying to build for a couple of hours yesterday.

I managed to make this build by manually triggering the build one-by-one for some derivations that got stuck when building the full closure.

Following analysis was done using output packages.x86_64-linux.lenovo-x1-carbon-gen11-debug from this PR on commit 9124aa7 as a reference:

The problem is, this changes systemd which triggers massive rebuilds. Attached is a graph showing:

• depth=1 reverse dependencies: graph_d1.pdf
• depth=2 reverse dependencies is already huge and barely readable: graph_d2.pdf

Full list of packages that need to be rebuild due to the change in this PR can be queried with nix-store (once evaluated):

nix-store --query --referrers-closure /nix/store/8dsk8mfykg8mm16d8gkr6y5qj6pjy9lp-0001-pam_systemd_home-Use-PAM_TEXT_INFO-for-token-prompts.patch

That is, 2044 derivations need to be rebuild, including some big ones too e.g. chromium and element.
That's the main reason why builders struggle with this PR.

[vunnyso]

Thanks @ktusawrk and @henrirosten for your analysis. systemd is one of the core component of system that's a lot of packages depends on it.
Anyways systemd patch mentioned in PR Description is merged in upstream and it will land on soon in nixos-unstable branch.

[henrirosten]

Anyways systemd patch mentioned in PR Description is merged in upstream and it will land on soon in nixos-unstable branch.

Whenever possible, I think we should prefer having patches such as this merged upstream first and take them to ghaf
only when they are available in nixos-unstable. That way, the dependencies would be built by community and made available
in nixos.org cache reducing the burden on our side.

[vunnyso]

I built lenovo-x1 image locally and booted from USB SSD.

Yubikey functionality seems to work now, except if booting without Yubikey (after local user with Yubikey has been created). Then it does not provide any opportunity to log in with password only.

Reason for it as homectl is created with FIDO2 which uses pam_systemd_home module and is executed by the greetd pam rule and requires a token to be inserted into the system. While it is possible to fall back to a password if we need to boot without a Yubikey using U2F, this approach IMO poses a security risk.

If Yubikey is unplugged when logged in then it locks the screen and does accept password at Lock screen. If user is then logged out while Yubikey not connected, logging in with password is not possible.

In lock screen, session is active so it accept password.

If device is booted to login screen without Yubikey log in does not work via Yubikey after plugging it in.

Looks like pam needs some retrigger as mentioned in pop-os/cosmic-greeter#31

Conclusion:
IMO, we can either merge this PR now or wait could wait for the systemd release, which includes the patch fix, to avoid overlaying it in ghaf.

Open to suggestions and thoughts!

[ktusawrk]

I'm afraid waiting for the systemd release is not viable. Maybe this PR needs to get merged and we have to deal with it in the release build environment in some unorthodox way, like making the build in smaller chunks.

[leivos-unikie]

I checked that login with password without Yubikey is failing also with an image built from 5c2e6f4, before Active Directory.

There has been some discussion if login without Yubikey is even required. Probably it makes ghaf more secure if login is allowed only with Yubikey (when user is created with Yubikey). So am ok with the feature.

There is just change compared to that how Yubikey used to work with ghaf previously. I checked that in manual tests we have run such Yubikey test (last time in release 25.11.1 testing) where login with password succeeds after booting without Yubikey.

[leivos-unikie]

tests on lenovo-x1

• Checked that login and unlock works ok for user created without Yubikey
• Checked that login and unlock via Yubikey works ok for user created with Yubikey

[vunnyso]

All checks have passed.