I enabled clevis to unlock my luks encrypted hardrive dnf install clevis clevis-luks clevis-dracut clevis luks bind -d /dev/nvme0n1p3 sss '//redacted' grubby --update-kernel=ALL --args=rd.neednet=1 grub2-mkconfig -o /boot/grub2/grub.cfg dracut -f It works well but after upgrade to fedora 44 I can see issues with "Unknown user" in the logs Reproducible: Didn't try Actual Results: sh# sh# journalctl -b | grep -E "tss|Switch Root" Feb 25 00:01:54 lslebodn.example.com systemd-tmpfiles[372]: Failed to parse ACL "default:group:tss:rwx", ignoring: Invalid argument Feb 25 00:01:54 lslebodn.example.com systemd-tmpfiles[372]: Failed to parse ACL "default:group:tss:rwx", ignoring: Invalid argument Feb 25 00:01:54 lslebodn.example.com systemd-tmpfiles[384]: /usr/lib/tmpfiles.d/tpm2-tss-fapi.conf:2: Failed to resolve user 'tss': Unknown user Feb 25 00:01:54 lslebodn.example.com systemd-tmpfiles[384]: Failed to parse ACL "default:group:tss:rwx", ignoring: Invalid argument Feb 25 00:01:54 lslebodn.example.com systemd-tmpfiles[384]: /usr/lib/tmpfiles.d/tpm2-tss-fapi.conf:4: Failed to resolve user 'tss': Unknown user Feb 25 00:01:54 lslebodn.example.com systemd-tmpfiles[384]: Failed to parse ACL "default:group:tss:rwx", ignoring: Invalid argument Feb 25 00:01:54 lslebodn.example.com systemd-tmpfiles[384]: /usr/lib/tmpfiles.d/tpm2-tss-fapi.conf:6: Failed to resolve group 'tss': Unknown group Feb 25 00:01:54 lslebodn.example.com systemd-tmpfiles[384]: /usr/lib/tmpfiles.d/tpm2-tss-fapi.conf:7: Failed to resolve group 'tss': Unknown group Feb 25 00:01:55 lslebodn.example.com systemd-udevd[509]: /usr/lib/udev/rules.d/60-tpm-udev.rules:3 Failed to resolve user 'tss', ignoring: Unknown user Feb 25 00:01:55 lslebodn.example.com systemd-udevd[509]: /usr/lib/udev/rules.d/60-tpm-udev.rules:4 Failed to resolve group 'tss', ignoring: Unknown group Feb 25 00:02:15 lslebodn.example.com systemd[1]: Reached target initrd-switch-root.target - Switch Root. Feb 25 00:02:15 lslebodn.example.com systemd[1]: Starting initrd-switch-root.service - Switch Root... Feb 25 00:02:16 lslebodn.example.com systemd[1]: Stopped initrd-switch-root.service - Switch Root. Feb 25 00:02:16 lslebodn.example.com systemd[1]: Stopped target initrd-switch-root.target - Switch Root. Note: Boot works well for me; I was just confused by errors in the logs. It took me some time to realize it is before Switch Root Expected Results: Similar as with older kernel sh# journalctl -b | grep -E "tss|Switch Root" Feb 25 14:31:23 lslebodn.example.com systemd-sysusers[371]: Creating group 'tss' with GID 59. Feb 25 14:31:23 lslebodn.example.com systemd-sysusers[371]: Creating user 'tss' (Account used for TPM access) with UID 59 and GID 59. Feb 25 14:31:47 lslebodn.example.com systemd[1]: Reached target initrd-switch-root.target - Switch Root. Feb 25 14:31:47 lslebodn.example.com systemd[1]: Starting initrd-switch-root.service - Switch Root... Feb 25 14:31:48 lslebodn.example.com systemd[1]: Stopped initrd-switch-root.service - Switch Root. Feb 25 14:31:48 lslebodn.example.com systemd[1]: Stopped target initrd-switch-root.target - Switch Root. Additional Information: I tried to regenerate intrd couple of times but it did not help Package versions: sh$ rpm -qf /usr/lib/sysusers.d/tpm2-tss.conf tpm2-tss-4.1.3-9.fc44.x86_64 sh$ rpm -q dracut systemd dracut-108-5.fc44.x86_64 systemd-259.1-1.fc44.x86_64
Maybe it is related by I cannot see systemd-sysusers.service in the problematic /boot/initramfs-6.19.3-300.fc44.x86_64.img lsinitrd /boot/initramfs-6.19.3-300.fc44.x86_64.img | grep -E "tss|sysuser" systemd-sysusers tpm2-tss -rwxr-xr-x 1 root root 604128 Jan 16 01:00 usr/lib64/libtss2-esys.so.0.0.1 lrwxrwxrwx 1 root root 21 Jan 16 01:00 usr/lib64/libtss2-esys.so.0 -> libtss2-esys.so.0.0.1 -rwxr-xr-x 1 root root 931120 Jan 16 01:00 usr/lib64/libtss2-fapi.so.1.0.0 lrwxrwxrwx 1 root root 21 Jan 16 01:00 usr/lib64/libtss2-fapi.so.1 -> libtss2-fapi.so.1.0.0 -rwxr-xr-x 1 root root 298248 Jan 16 01:00 usr/lib64/libtss2-mu.so.0.0.1 lrwxrwxrwx 1 root root 19 Jan 16 01:00 usr/lib64/libtss2-mu.so.0 -> libtss2-mu.so.0.0.1 -rwxr-xr-x 1 root root 28904 Jan 16 01:00 usr/lib64/libtss2-rc.so.0.0.0 lrwxrwxrwx 1 root root 19 Jan 16 01:00 usr/lib64/libtss2-rc.so.0 -> libtss2-rc.so.0.0.0 -rwxr-xr-x 1 root root 159768 Jan 16 01:00 usr/lib64/libtss2-sys.so.1.0.1 lrwxrwxrwx 1 root root 20 Jan 16 01:00 usr/lib64/libtss2-sys.so.1 -> libtss2-sys.so.1.0.1 -rwxr-xr-x 1 root root 23904 Jan 16 01:00 usr/lib64/libtss2-tcti-cmd.so.0.0.0 lrwxrwxrwx 1 root root 25 Jan 16 01:00 usr/lib64/libtss2-tcti-cmd.so.0 -> libtss2-tcti-cmd.so.0.0.0 -rwxr-xr-x 1 root root 23912 Jan 16 01:00 usr/lib64/libtss2-tcti-device.so.0.0.0 lrwxrwxrwx 1 root root 28 Jan 16 01:00 usr/lib64/libtss2-tcti-device.so.0 -> libtss2-tcti-device.so.0.0.0 -rwxr-xr-x 1 root root 28032 Jan 16 01:00 usr/lib64/libtss2-tctildr.so.0.0.0 lrwxrwxrwx 1 root root 24 Jan 16 01:00 usr/lib64/libtss2-tctildr.so.0 -> libtss2-tctildr.so.0.0.0 -rwxr-xr-x 1 root root 32216 Jan 16 01:00 usr/lib64/libtss2-tcti-mssim.so.0.0.0 lrwxrwxrwx 1 root root 27 Jan 16 01:00 usr/lib64/libtss2-tcti-mssim.so.0 -> libtss2-tcti-mssim.so.0.0.0 -rwxr-xr-x 1 root root 32208 Jan 16 01:00 usr/lib64/libtss2-tcti-swtpm.so.0.0.0 lrwxrwxrwx 1 root root 27 Jan 16 01:00 usr/lib64/libtss2-tcti-swtpm.so.0 -> libtss2-tcti-swtpm.so.0.0.0 drwxr-xr-x 2 root root 0 Jan 16 01:00 usr/lib/sysusers.d -rw-r--r-- 1 root root 379 Jan 16 01:00 usr/lib/sysusers.d/basic.conf -rw-r--r-- 1 root root 118 Jan 16 01:00 usr/lib/sysusers.d/dbus.conf -rw-r--r-- 1 root root 316 Jan 16 01:00 usr/lib/sysusers.d/systemd-journal.conf -rw-r--r-- 1 root root 128 Jan 16 01:00 usr/lib/sysusers.d/tpm2-tss.conf -rw-r--r-- 1 root root 592 Jan 16 01:00 usr/lib/tmpfiles.d/tpm2-tss-fapi.conf working previous one root@lslebodn-thinkpadp1gen7:~# lsinitrd /boot/initramfs-6.18.12-200.fc43.x86_64.img | grep -E "tss|sysuser" systemd-sysusers tpm2-tss -rwxr-xr-x 1 root root 74048 Oct 14 02:00 usr/bin/systemd-sysusers -rwxr-xr-x 1 root root 579640 Jul 25 2025 usr/lib64/libtss2-esys.so.0.0.1 lrwxrwxrwx 1 root root 21 Oct 14 02:00 usr/lib64/libtss2-esys.so.0 -> libtss2-esys.so.0.0.1 -rwxr-xr-x 1 root root 898440 Jul 25 2025 usr/lib64/libtss2-fapi.so.1.0.0 lrwxrwxrwx 1 root root 21 Oct 14 02:00 usr/lib64/libtss2-fapi.so.1 -> libtss2-fapi.so.1.0.0 -rwxr-xr-x 1 root root 277840 Jul 25 2025 usr/lib64/libtss2-mu.so.0.0.1 lrwxrwxrwx 1 root root 19 Oct 14 02:00 usr/lib64/libtss2-mu.so.0 -> libtss2-mu.so.0.0.1 -rwxr-xr-x 1 root root 29024 Jul 25 2025 usr/lib64/libtss2-rc.so.0.0.0 lrwxrwxrwx 1 root root 19 Oct 14 02:00 usr/lib64/libtss2-rc.so.0 -> libtss2-rc.so.0.0.0 -rwxr-xr-x 1 root root 155808 Jul 25 2025 usr/lib64/libtss2-sys.so.1.0.1 lrwxrwxrwx 1 root root 20 Oct 14 02:00 usr/lib64/libtss2-sys.so.1 -> libtss2-sys.so.1.0.1 -rwxr-xr-x 1 root root 23976 Jul 25 2025 usr/lib64/libtss2-tcti-cmd.so.0.0.0 lrwxrwxrwx 1 root root 25 Oct 14 02:00 usr/lib64/libtss2-tcti-cmd.so.0 -> libtss2-tcti-cmd.so.0.0.0 -rwxr-xr-x 1 root root 24016 Jul 25 2025 usr/lib64/libtss2-tcti-device.so.0.0.0 lrwxrwxrwx 1 root root 28 Oct 14 02:00 usr/lib64/libtss2-tcti-device.so.0 -> libtss2-tcti-device.so.0.0.0 -rwxr-xr-x 1 root root 24032 Jul 25 2025 usr/lib64/libtss2-tctildr.so.0.0.0 lrwxrwxrwx 1 root root 24 Oct 14 02:00 usr/lib64/libtss2-tctildr.so.0 -> libtss2-tctildr.so.0.0.0 -rwxr-xr-x 1 root root 32312 Jul 25 2025 usr/lib64/libtss2-tcti-mssim.so.0.0.0 lrwxrwxrwx 1 root root 27 Oct 14 02:00 usr/lib64/libtss2-tcti-mssim.so.0 -> libtss2-tcti-mssim.so.0.0.0 -rwxr-xr-x 1 root root 32336 Jul 25 2025 usr/lib64/libtss2-tcti-swtpm.so.0.0.0 lrwxrwxrwx 1 root root 27 Oct 14 02:00 usr/lib64/libtss2-tcti-swtpm.so.0 -> libtss2-tcti-swtpm.so.0.0.0 lrwxrwxrwx 1 root root 27 Oct 14 02:00 usr/lib/systemd/system/sysinit.target.wants/systemd-sysusers.service -> ../systemd-sysusers.service -rw-r--r-- 1 root root 1310 Oct 14 02:00 usr/lib/systemd/system/systemd-sysusers.service drwxr-xr-x 2 root root 0 Oct 14 02:00 usr/lib/systemd/system/systemd-sysusers.service.d -rw-r--r-- 1 root root 29 Oct 14 02:00 usr/lib/systemd/system/systemd-sysusers.service.d/sysusers-dracut.conf drwxr-xr-x 2 root root 0 Oct 14 02:00 usr/lib/sysusers.d -rw-r--r-- 1 root root 118 Jul 23 2025 usr/lib/sysusers.d/dbus.conf -rw-r--r-- 1 root root 316 Oct 14 02:00 usr/lib/sysusers.d/systemd-journal.conf -rw-r--r-- 1 root root 128 Jul 25 2025 usr/lib/sysusers.d/tpm2-tss.conf -rw-r--r-- 1 root root 592 Jul 25 2025 usr/lib/tmpfiles.d/tpm2-tss-fapi.conf
I can provide output of `dracut --force --debug &> dracut-debug.log` if needed
Hello, can you check if explicitly adding the systemd-sysusers module helps? Maybe the dependency is missing. ``` dracut -f -vvv -a systemd-sysusers ```
Upstream commit commit 28adf6f91cf7e294799e5a8b73b5937644c8cde9 Author: Benjamin Drung <benjamin.drung> Date: Tue Jan 27 12:33:12 2026 +0100 fix(tpm2-tss): add tss user/group in addition to sysusers config Test 10 on ubuntu:devel shows this warning: ... Partly or perhaps completely fixes this problem or a similar problem. On my system running Fedore 44 these messages are no longer in the journal when applying this change to modules.d/73tpm2-tss/module-setup.sh Feb 25 00:01:55 lslebodn-thinkpadp1gen7.tpb.csb systemd-udevd[509]: /usr/lib/udev/rules.d/60-tpm-udev.rules:3 Failed to resolve user 'tss', ignoring: Unknown user Feb 25 00:01:55 lslebodn-thinkpadp1gen7.tpb.csb systemd-udevd[509]: /usr/lib/udev/rules.d/60-tpm-udev.rules:4 Failed to resolve diff --git a/modules.d/73tpm2-tss/module-setup.sh b/modules.d/73tpm2-tss/module-setup.sh index 6b71eee4..186cc6c8 100755 --- a/modules.d/73tpm2-tss/module-setup.sh +++ b/modules.d/73tpm2-tss/module-setup.sh @@ -32,6 +32,8 @@ installkernel() { install() { inst_sysusers tpm2-tss.conf inst_sysusers system-user-tss.conf + grep -s '^tss:' "${dracutsysrootdir-}"/etc/passwd >> "$initdir/etc/passwd" + grep -s '^tss:' "${dracutsysrootdir-}"/etc/group >> "$initdir/etc/group" inst_multiple -o \ "$tmpfilesdir"/tpm2-tss-fapi.conf \
> Partly or perhaps completely fixes this problem or a similar problem. On my system running Fedore 44 > these messages are no longer in the journal when applying this change to modules.d/73tpm2-tss/module-setup.sh That is not a fix but a workaround. tss user did not exist in the /etc/passwd for previous initrd and systemd-sysusers works well there. lsinitrd -f /etc/passwd /boot/initramfs-6.18.12-200.fc43.x86_64.img adm:x:3:4:adm:/var/adm:/usr/sbin/nologin systemd-network:x:192:192:systemd Network Management:/:/usr/sbin/nologin root:x:0:0::/root:/bin/sh nobody:x:65534:65534:Kernel Overflow User:/:/usr/sbin/nologin
(In reply to Lukas Slebodnik from comment #6) > > That is not a fix but a workaround. tss user did not exist in the > /etc/passwd for previous initrd > and systemd-sysusers works well there. > For some reason, the module 91tpm2-tss is now included in the intrd sinse F44 whereas in normal cases it was not in F43. Thus the dbus modules which requires the user tss wasn't in the initrd either.
(In reply to Pavel Valena from comment #4) > Hello, can you check if explicitly adding the systemd-sysusers module helps? > Maybe the dependency is missing. > > ``` > dracut -f -vvv -a systemd-sysusers > ``` It was already there sh# lsinitrd --mod | grep users systemd-sysusers But I ran the command and it did not help much root@lslebodn:~# uptime 13:10:38 up 2 min, 1 user, load average: 0.18, 0.19, 0.08 root@lslebodn:~# lsinitrd | grep sysuser Arguments: -f -v -v -v -a 'systemd-sysusers' systemd-sysusers drwxr-xr-x 2 root root 0 Jan 16 01:00 usr/lib/sysusers.d -rw-r--r-- 1 root root 379 Jan 16 01:00 usr/lib/sysusers.d/basic.conf -rw-r--r-- 1 root root 118 Jan 16 01:00 usr/lib/sysusers.d/dbus.conf -rw-r--r-- 1 root root 316 Jan 16 01:00 usr/lib/sysusers.d/systemd-journal.conf -rw-r--r-- 1 root root 128 Jan 16 01:00 usr/lib/sysusers.d/tpm2-tss.conf root@lslebodn:~# journalctl -b | grep -E "tss|Switch Root" Feb 27 13:07:46 lslebodn.example.com systemd-tmpfiles[370]: Failed to parse ACL "default:group:tss:rwx", ignoring: Invalid argument Feb 27 13:07:46 lslebodn.example.com systemd-tmpfiles[370]: Failed to parse ACL "default:group:tss:rwx", ignoring: Invalid argument Feb 27 13:07:46 lslebodn.example.com systemd-tmpfiles[381]: /usr/lib/tmpfiles.d/tpm2-tss-fapi.conf:2: Failed to resolve user 'tss': Unknown user Feb 27 13:07:46 lslebodn.example.com systemd-tmpfiles[381]: Failed to parse ACL "default:group:tss:rwx", ignoring: Invalid argument Feb 27 13:07:46 lslebodn.example.com systemd-tmpfiles[381]: /usr/lib/tmpfiles.d/tpm2-tss-fapi.conf:4: Failed to resolve user 'tss': Unknown user Feb 27 13:07:46 lslebodn.example.com systemd-tmpfiles[381]: Failed to parse ACL "default:group:tss:rwx", ignoring: Invalid argument Feb 27 13:07:46 lslebodn.example.com systemd-tmpfiles[381]: /usr/lib/tmpfiles.d/tpm2-tss-fapi.conf:6: Failed to resolve group 'tss': Unknown group Feb 27 13:07:46 lslebodn.example.com systemd-tmpfiles[381]: /usr/lib/tmpfiles.d/tpm2-tss-fapi.conf:7: Failed to resolve group 'tss': Unknown group Feb 27 13:07:47 lslebodn.example.com systemd-udevd[513]: /usr/lib/udev/rules.d/60-tpm-udev.rules:3 Failed to resolve user 'tss', ignoring: Unknown user Feb 27 13:07:47 lslebodn.example.com systemd-udevd[513]: /usr/lib/udev/rules.d/60-tpm-udev.rules:4 Failed to resolve group 'tss', ignoring: Unknown group Feb 27 13:08:10 lslebodn.example.com systemd[1]: Reached target initrd-switch-root.target - Switch Root. Feb 27 13:08:10 lslebodn.example.com systemd[1]: Starting initrd-switch-root.service - Switch Root... Feb 27 13:08:11 lslebodn.example.com systemd[1]: Stopped initrd-switch-root.service - Switch Root. Feb 27 13:08:11 lslebodn.example.com systemd[1]: Stopped target initrd-switch-root.target - Switch Root.
Created attachment 2131288 [details] dracut -f -vvv -a systemd-sysusers Attaching output of: dracut -f -vvv -a systemd-sysusers
There was change in dracut for systemd-users sh$ rpm -qf /usr/lib/dracut/modules.d/01systemd-sysusers/module-setup.sh dracut-107-8.fc43.x86_64 sh$$ cat /usr/lib/dracut/modules.d/01systemd-sysusers/module-setup.sh #!/usr/bin/bash # This file is part of dracut. # SPDX-License-Identifier: GPL-2.0-or-later # Prerequisite check(s) for module. check() { # If the binary(s) requirements are not fulfilled the module can't be installed. require_binaries systemd-sysusers || return 1 # Return 255 to only include the module, if another module requires it. return 255 } # Install the required file(s) and directories for the module in the initramfs. install() { inst_simple "$moddir/sysusers-dracut.conf" "$systemdsystemunitdir/systemd-sysusers.service.d/sysusers-dracut.conf" inst_sysusers basic.conf inst_multiple -o \ "$systemdsystemunitdir"/systemd-sysusers.service \ "$systemdsystemunitdir"/sysinit.target.wants/systemd-sysusers.service \ systemd-sysusers # Install the hosts local user configurations if enabled. if [[ $hostonly ]]; then inst_multiple -H -o \ "$systemdsystemconfdir"/systemd-sysusers.service \ "$systemdsystemconfdir/systemd-sysusers.service.d/*.conf" fi } vs new one root@lslebodn-thinkpadp1gen7:~# cat /usr/lib/dracut/modules.d/68systemd-sysusers/module-setup.sh #!/usr/bin/bash # This file is part of dracut. # SPDX-License-Identifier: GPL-2.0-or-later # This module should be orders afer all modules that depends on it # This is to make sure that all inst_sysusers calls are in place before systemd-sysusers is called. # Prerequisite check(s) for module. check() { # If the binary(s) requirements are not fulfilled the module can't be installed. require_binaries systemd-sysusers || return 1 # Return 255 to only include the module, if another module requires it. return 255 } # Install the required file(s) and directories for the module in the initramfs. install() { inst_sysusers basic.conf # redirect stdout temporarily to FD 3 to use filter stderr { set -o pipefail systemd-sysusers --root="$initdir" 2>&1 >&3 | grep -v "^Creating " >&2 } 3>&1 # systemd-sysusers does not set any permission # set read and write permission for the current user [[ -f "$initdir/etc/gshadow" ]] && chmod u+rw "$initdir/etc/gshadow" [[ -f "$initdir/etc/shadow" ]] && chmod u+rw "$initdir/etc/shadow" } But order of moduls does not seems to be good sh# grep inst_sysusers /usr/lib/dracut/modules.d/**/* /usr/lib/dracut/modules.d/11systemd-coredump/module-setup.sh: inst_sysusers systemd-coredump.conf /usr/lib/dracut/modules.d/11systemd-journald/module-setup.sh: inst_sysusers systemd-journal.conf /usr/lib/dracut/modules.d/11systemd-networkd/module-setup.sh: inst_sysusers systemd-network.conf /usr/lib/dracut/modules.d/11systemd-resolved/module-setup.sh: inst_sysusers systemd-resolve.conf /usr/lib/dracut/modules.d/11systemd-timesyncd/module-setup.sh: inst_sysusers systemd-timesync.conf /usr/lib/dracut/modules.d/16dbus-broker/module-setup.sh: inst_sysusers dbus.conf /usr/lib/dracut/modules.d/68systemd-sysusers/module-setup.sh:# This is to make sure that all inst_sysusers calls are in place before systemd-sysusers is called. /usr/lib/dracut/modules.d/68systemd-sysusers/module-setup.sh: inst_sysusers basic.conf /usr/lib/dracut/modules.d/73tpm2-tss/module-setup.sh: inst_sysusers tpm2-tss.conf 73tpm2-tss is executed after 68systemd-sysusers
sh# dracut --force sh# lsinitrd -f /etc/passwd | grep tss dbus:x:81:81:System Message Bus:/:/usr/sbin/nologin And changing order helped sh# mv /usr/lib/dracut/modules.d/68systemd-sysusers /usr/lib/dracut/modules.d/99systemd-sysusers sh# time dracut --force grep: /var/tmp/dracut.dGHftBf/initramfs/etc/shadow: No such file or directory real 0m42.938s user 0m51.903s sys 0m27.338s sh# lsinitrd -f /etc/passwd | grep -E "tss|dbus" dbus:x:81:81:System Message Bus:/:/usr/sbin/nologin tss:x:59:59:Account used for TPM access:/:/usr/sbin/nologin
(In reply to Lukas Slebodnik from comment #10) > # Install the required file(s) and directories for the module in the > initramfs. > install() { > inst_sysusers basic.conf > > # redirect stdout temporarily to FD 3 to use filter stderr > { > set -o pipefail > systemd-sysusers --root="$initdir" 2>&1 >&3 | grep -v "^Creating " > >&2 > } 3>&1 > > By the way: the redirects should be ">&3 2>&1". Otherwise stderr goes stdout and the new stdout == stderr both goes to &3.
Is the assumption about wrong order correct? https://bugzilla.redhat.com/show_bug.cgi?id=2442617#c10 Or changing order `mv /usr/lib/dracut/modules.d/68systemd-sysusers/ /usr/lib/dracut/modules.d/74systemd-sysusers/` would break something else.
https://bugzilla.redhat.com/show_bug.cgi?id=2448131 duplicates this report. Cross posting: Based on https://github.com/systemd/systemd/issues/21665 it does not look like sysusers should be working like this and the user should be added using something like https://github.com/dracut-ng/dracut-ng/pull/2139/files which is implemented in dracut 110. Thanks
(In reply to Joe Walker from comment #14) > https://bugzilla.redhat.com/show_bug.cgi?id=2448131 duplicates this report. > > Cross posting: > Based on https://github.com/systemd/systemd/issues/21665 it does not look > like sysusers should be working like this and the user should be added using > something like https://github.com/dracut-ng/dracut-ng/pull/2139/files which > is implemented in dracut 110. > > Thanks It would work either way, as long as systemd-sysusers is installed later than any of the modules which needs to have system users defined.
https://github.com/systemd/systemd/issues/21665 is very ancient issue I am not sure whether it is valid much here. > user should be added using something like https://github.com/dracut-ng/dracut-ng/pull/2139/files which > is implemented in dracut 110. But order of modules is much more important in dracut 110 it changed comparing to 108 * https://github.com/dracut-ng/dracut-ng/blob/5bb196277075a9a1c59572d799bffd15aa2691ae/modules.d/73tpm2-tss/module-setup.sh * https://github.com/dracut-ng/dracut-ng/blob/5bb196277075a9a1c59572d799bffd15aa2691ae/modules.d/78systemd-sysusers/module-setup.sh * https://github.com/dracut-ng/dracut-ng/commit/80bc6ba180407b3ddd6e141d7567fe8fb15f1939
*** Bug 2448131 has been marked as a duplicate of this bug. ***
Proposed as a Blocker for 44-final by Fedora user pbrobinson using the blocker tracking app because: https://fedoraproject.org/wiki/Fedora_44_Final_Release_Criteria#Automatic_partition_decryption_(Clevis)
Note, Clevis tests in openQA *do* pass, e.g. https://openqa.fedoraproject.org/tests/4616570 on the most recent IoT nightly. The test fails on aarch64 but has been failing for more than year; I've never had time to look into why but it's probably not this. Not sure why the difference in experience. Perhaps this only affects upgrades? It would be useful to have more information.
(In reply to Adam Williamson from comment #19) > Note, Clevis tests in openQA *do* pass, e.g. > https://openqa.fedoraproject.org/tests/4616570 on the most recent IoT > nightly. The test fails on aarch64 but has been failing for more than year; > I've never had time to look into why but it's probably not this. > > Not sure why the difference in experience. Perhaps this only affects > upgrades? It would be useful to have more information. Is clevis even affected by the missing tss user? The log messages shown in the first message also occurs if clevis is not installed.
(In reply to Villy Kruse from comment #20) > (In reply to Adam Williamson from comment #19) > > Note, Clevis tests in openQA *do* pass, e.g. > > https://openqa.fedoraproject.org/tests/4616570 on the most recent IoT > > nightly. The test fails on aarch64 but has been failing for more than year; > > I've never had time to look into why but it's probably not this. > > > > Not sure why the difference in experience. Perhaps this only affects > > upgrades? It would be useful to have more information. > > Is clevis even affected by the missing tss user? > > The log messages shown in the first message also occurs if clevis is not > installed. Clevis worked for me without any issue despite of `Failed to resolve group 'tss': Unknown ` in journald. Just messages in journald were annoying. But I suppressed them locally with renaming directory (&& regenerated initrd) Similar as in upstream commit * https://github.com/dracut-ng/dracut-ng/commit/80bc6ba180407b3ddd6e141d7567fe8fb15f1939
Ah, thanks. Well, for blocker purposes, the criterion says "When configured on hardware with a Trusted Platform Module (TPM), it must be possible for the Clevis utility to automatically decrypt any encrypted partitions on boot without any user intervention". It does *not* say "...and not print annoying messages to the journal". :D
@Lukas Slebodnik: > Clevis worked for me without any issue despite of `Failed to resolve group 'tss': Unknown ` in journald. It's not clear to me you are using TPM in your settings, as you redacted the sss config. Are you using the tpm2 binding? The tss group is for allowing the user to access the TPM. If you are e.g only using tang, it should not cause any actual issues. @Adam Williamson: > Note, Clevis tests in openQA *do* pass, e.g. https://openqa.fedoraproject.org/tests/4616570 on the most recent IoT nightly. The test fails on aarch64 but has been failing for more than year; I've never had time to look into why but it's probably not this. Please open an issue about it so we can investigate.
AGREED RejectedFinalBlocker RejectedFinalFreezeException Discussed at the 2026-04-20 (blocker / freeze exception) review meeting: This is rejected as a blocker as it's clear from comment 21 that this does not actually violate the cited criterion. It also doesn't seem to warrant FE status; it's not terribly severe and can be addressed sufficiently as a post-release update. https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2026-04-20/f44-blocker-review.2026-04-20-16.00.log.txt
(In reply to Sergio Correia from comment #23) > @Lukas Slebodnik: > > Clevis worked for me without any issue despite of `Failed to resolve group 'tss': Unknown ` in journald. > > It's not clear to me you are using TPM in your settings, as you redacted the > sss config. Are you using the tpm2 binding? The tss group is for allowing > the user to access the TPM. If you are e.g only using tang, it should not > cause any actual issues. > Good point. I use clevis && tang