Re: [systemd-devel] Create a tmpfile with content from output of executing a command

[Mantas Mikulėnas]

No, and that doesn't sound like a good fit for systemd-tmpfiles anyway.

Use an ordinary Type=oneshot .service instead. (In current systemd
versions, you can even specify StandardOutput to be a file; in older
versions calling `/bin/sh -c "... > file"` is fine.)

Your email domain has a strict SPF/DMARC policy, and the obsolete
mailing-list system used by Freedesktop.org does not play well with that,
leading to some places such as Gmail quarantining all list-relayed messages
from you. (I think it's because the list server damages your DKIM
signatures.)

On Thu, Oct 5, 2023 at 12:44 PM Renjaya Raga Zenta <
renjaya.ze...@formulatrix.com> wrote:

> Hi list,
>
> I'd like to create a temporary file using systemd-tmpfiles. The file
> will contain merge of multiple text files. Can the argument field in
> tmpfiles.d be a path to an executable? So I can create a script to
> print the content of those multiple files.
>
> Or maybe there is another way to do this?
>
>
> Thank you.
>


-- 
Mantas Mikulėnas

Re: [systemd-devel] How to make an encrypted disk mentioned in /etc/crypttab "optional"?

[Aaron Rainbolt]

On 10/9/23 02:38, Andrei Borzenkov wrote:

On Mon, Oct 9, 2023 at 10:10 AM Aaron Rainbolt  wrote:

Good morning/evening, and thanks for your time.

I'm attempting to create a Fedora-based immutable distro (not based on
Silverblue) that stores user data in an encrypted /home partition. The
goal is to have something that behaves somewhat similar to Chrome OS.
One feature I'm attempting to implement is a "guest mode", whereby a
user can sign into the system without providing any password, but if
they do so they don't gain access to the system's owner's data and
virtually anything they do is erased upon shutdown.

In order to do this, I have two /home directories - one is part of the
(immutable) root filesystem, which can only be written to thanks to a
Dracut-created ramdisk overlay. The other is stored in an encrypted
partition. I'm using a crypttab line like this to prepare the encrypted
partition:

  firebook-home LABEL=firebook-crypt none luks,discard,nofail

And I'm using an fstab line like this to mount it:

  /dev/mapper/firebook-home /home ext4 defaults,nofail 0 0


Where is your user home directory located?


Note that I've marked both of these with "nofail" - the goal is that the
user will be prompted for their password by systemd upon boot, but if
they do not provide the password (by intentionally providing a wrong
password three times), the encrypted drive should not be mounted and the
system should boot normally using the ephemeral home directory provided
by the root filesystem + ramdisk overlay.


I am not sure whether systemd can even express such logic. Check
whether any service involved in logging in has dependency on /home
(like RequiresMountsFor=/home).


Sadly I don't think this is the issue - I tried changing it so that the 
encrypted partition was mounted at /home/user rather than directly at 
/home, and GNOME still fails to start if I flunk the password intentionally.



This seems to be *almost* working, however if I intentionally provide a
wrong password to the password prompt a few times, it doesn't actually
"give up" on getting a password from me. What it does instead is it
stops asking me for the password at boot, but then rather than starting
GNOME it just leaves me at a console screen. If I am able to get GDM to
appear somehow, I can't sign in.

What I end up doing is switching to a TTY, signing in, and then
elevating to root to troubleshoot. Once I've elevated to root, I get a
`wall` message informing me that the system is *still waiting* for a
password and that I need to run `systemd-tty-ask-password-agent` (I
think?) to provide it. If I go ahead and do this, then restart GDM, I'm
able to sign in after that. (I could be wrong about what command it's
asking me to run, but I think it was `systemd-tty-ask-password-agent`.)

  From my research, it looks like systemd is refusing to ever truly "give
up" on getting the password for the encrypted /home directory, despite
the use of `nofail` in the fstab and crypttab files. I'm not finding any
documentation on how to get systemd to "give up" on getting the
password. For my particular use case, I'd like systemd to just forget
that the encrypted drive exists at all if the wrong password is given.
If the user wants to mount the encrypted drive after that, they should
either reboot or use cryptsetup manually.

Is there any way to make systemd "give up" on getting a password?

Thanks for your help!

Aaron

Re: [systemd-devel] Fedora 38 and signed PCR binding

[Aleksandar Kostadinov]

Console didn't show anything but I found these lines in system log.

> Oct 08 18:34:51 systemd-sysusers[228]: Creating group 'tss' with GID 59.
> Oct 08 18:34:51 systemd-sysusers[228]: Creating user 'tss' (Account used for 
> TPM access) with UID 59 and GID 59.
> Oct 08 18:34:51 systemd-tmpfiles[232]: Failed to parse ACL 
> "default:group:tss:rwx", ignoring: Invalid argument
>
> Oct 08 18:34:52 systemd[1]: Found device 
> dev-disk-by\x2duuid-16b6da19\x2d8810\x2d49f8\x2d8923\x2dce803dacc3a1.device - 
> UMIS_RTFTJ032VGD1EWX 3.
> Oct 08 18:34:52 systemd[1]: Starting 
> systemd-cryptsetup@luks\x2d16b6da19\x2d8810\x2d49f8\x2d8923\x2dce803dacc3a1.service
>  - Cryptography Setup for luks-16b6da19-8810-49f8-8923-ce803dacc3a1...
>
> Oct 08 18:34:53 systemd-cryptsetup[437]: Couldn't find signature for this PCR 
> bank, PCR index and public key.
> Oct 08 18:34:53 systemd-cryptsetup[437]: Set cipher aes, mode xts-plain64, 
> key size 512 bits for device 
> /dev/disk/by-uuid/16b6da19-8810-49f8-8923-ce803dacc3a1.
> Oct 08 18:34:53 systemd-cryptsetup[437]: Automatically discovered security 
> TPM2 token unlocks volume.
> Oct 08 18:34:54 systemd-cryptsetup[437]: Couldn't find signature for this PCR 
> bank, PCR index and public key.
> Oct 08 18:34:54 systemd-cryptsetup[437]: TPM2 operation failed, falling back 
> to traditional unlocking: No such device or address
>
> Oct 08 18:35:24 systemd-cryptsetup[437]: Set cipher aes, mode xts-plain64, 
> key size 512 bits for device 
> /dev/disk/by-uuid/16b6da19-8810-49f8-8923-ce803dacc3a1.
> Oct 08 18:35:26 systemd-cryptsetup[437]: Successfully extended PCR index 15 
> with 
> 'cryptsetup:luks-16b6da19-8810-49f8-8923-ce803dacc3a1:16b6da19-8810-49f8-8923-ce803dacc3a1'
>  and volume key (banks sha1, sha256).
> Oct 08 18:35:26 systemd[1]: Finished 
> systemd-cryptsetup@luks\x2d16b6da19\x2d8810\x2d49f8\x2d8923\x2dce803dacc3a1.service
>  - Cryptography Setup for luks-16b6da19-8810-49f8-8923-ce803dacc3a1.

How to know what is the issue causing "Couldn't find signature for
this PCR bank, PCR index and public key." ?

On Sun, Oct 8, 2023 at 3:20 PM Aleksandar Kostadinov
 wrote:
>
> Also forgot to mention how I have setup the RSA keys:
>
> > openssl genrsa -out /etc/systemd/tpm2-pcr-private-key.pem 2048
> > openssl rsa -in /etc/systemd/tpm2-pcr-private-key.pem -pubout -out 
> > /etc/systemd/tpm2-pcr-public-key.pem
>
> and
>
> > echo "add_dracutmodules+=\" tpm2-tss \"" > /etc/dracut.conf.d/tpm2.conf
>
> The secure boot key I assume is alright because I have secure boot
> enabled and it boots the kernel.
>
> On Sun, Oct 8, 2023 at 3:08 PM Aleksandar Kostadinov
>  wrote:
> >
> > I've progressed past this point by upgrading to Fedora 39 Beta which
> > apparently has a newer ukify version. The issue now though is that
> > automatic unlock does not work. I need to enter password manually and
> > I see no errors in console output.
> >
> > Here's what I did:
> > > sudo systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto 
> > > --tpm2-public-key-pcrs=11 /dev/sda3
> >
> > > $ sudo cat /etc/crypttab
> > > luks-### UUID=### none discard,tpm2-device=auto,tpm2-measure-pcr=yes
> >
> > > sudo dracut -f
> >
> > >   /usr/lib/systemd/ukify build \
> > > --linux=/lib/modules/6.5.5-300.fc39.x86_64/vmlinuz \
> > > --initrd=/boot/initramfs-6.5.5-300.fc39.x86_64.img \
> > > --pcr-private-key=/etc/systemd/tpm2-pcr-private-key.pem \
> > > --pcr-public-key=/etc/systemd/tpm2-pcr-public-key.pem \
> > > --phases='enter-initrd' \
> > > --pcr-banks=sha1,sha256 \
> > > --secureboot-private-key=/etc/secure_boot/db_custom.key \
> > > --secureboot-certificate=/etc/secure_boot/db_custom.pem \
> > > --sign-kernel \
> > > --cmdline=@/etc/kernel/cmdline \
> > > --measure \
> > > --output=/boot/efi/EFI/fedora/uki/vmlinuz.efi
> >
> > > efibootmgr -c -d /dev/sda -p 1 -l /EFI/FEDORA/UKI/VMLINUZ.EFI -L "Fedora 
> > > UKI"
> >
> > The UKI entry now does boot. But waits for luks decryption password.
> >
> > I added a print line to the `ukify` executable to see the signature
> > file generated.
> >
> > > {"sha1": [{"pcrs": [11], "pkfp": 
> > > "77cb92791d56699be04ab48bdc85adbd6e12ec2816241eadbe0859650684bee7", 
> > > "pol": 
> > > "3d43ca831277c9a57f7741a23dca2896da9ece1417d1dc047c7a018014571580", 
> > > "sig": 
> > > "hJ4fhnRPXmsEXdq6o5eVS9WbGyJJdp/Q+x8Op5EPp0JmnB79nuGZqtTK1tYaxjzgN6/w/Wq1k93p/owSks9I7SJ5wJ0ciA4Ruaou49HdK0eDBbDmJ+Bsb33t/tP7bgXrpz2KEzkpmxd9SkIfM/0cK9tHJfrlvuAZgNr9vr3zLBkaWGI2XkDhOCnujWvxatDX2L63IPUyAZ+CGqvSL95734MPsJ0VWeP3w0mBb9KfMw7jifWLVj+1A3V5iY2bK5HYCzMBab91XuQo2JjMRDfE33PlqkiRFq56AwpLkZAVijndFNHJj7zHrzXBBsKWsO+t3i6WVF4g2cmaISVs6ehIJw=="}],
> > >  "sha256": [{"pcrs": [11], "pkfp": 
> > > "77cb92791d56699be04ab48bdc85adbd6e12ec2816241eadbe0859650684bee7", 
> > > "pol": 
> > > "76e24d931952b45046e001cac3ed6a6f9b76162f

[systemd-devel] Help! Reached target Local File Systems order is incorrect

[Tony Rodriguez]

Created a service that invokes a "systemctl daemon-reload". Goal is for 
a reload to occur early in the boot process, before other user made 
services are invoked.  During additional testing, sometimes it is 
correct and other times it is out of order (incorrect -  See steps C).  
It may work for 5 or 6 times after each reboot/shutdown, then randomly 
become incorrect. How can I make this more consistent? Already tried 
various keyword combinations (wants,before,after, etc) within the unit 
file, all without luck.
Thought about something like "After=var.mount, etc" as well, but that is 
inflexible because I will not know filesystems users may create.


A) Unit file

[Unit]
Description=Systemctl-Reload
Wants=local-fs.target
DefaultDependencies=yes

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/systemctl daemon-reload

[Install]
WantedBy=local-fs.target


B)  Correct order: ** Reached target Local File Systems is after all 
mounting is done. Sometimes it works.


eg:
journalctl --boot=0 | grep -E 'Mounting |Mounted |Local File'
Oct 09 11:21:39 rocky8-linux-build systemd[1]: Mounting Kernel 
Configuration File System...
Oct 09 11:21:39 rocky8-linux-build systemd[1]: Mounted Kernel 
Configuration File System.
Oct 09 11:21:40 rocky8-linux-build systemd[1]: Reached target Local File 
Systems (Pre).
Oct 09 11:21:40 rocky8-linux-build systemd[1]: Reached target Local File 
Systems.

Oct 09 11:21:40 rocky8-linux-build systemd[1]: Mounting /sysroot...
Oct 09 11:21:40 rocky8-linux-build kernel: XFS (dm-0): Mounting V5 
Filesystem

Oct 09 11:21:40 rocky8-linux-build systemd[1]: Mounted /sysroot.
Oct 09 11:21:41 rocky8-linux-build systemd[1]: Mounting /sysroot/usr...
Oct 09 11:21:41 rocky8-linux-build kernel: XFS (dm-2): Mounting V5 
Filesystem

Oct 09 11:21:41 rocky8-linux-build systemd[1]: Mounted /sysroot/usr.
Oct 09 11:21:41 rocky8-linux-build systemd[1]: Stopped target Local File 
Systems.
Oct 09 11:21:41 rocky8-linux-build systemd[1]: Stopped target Local File 
Systems (Pre).
Oct 09 11:21:41 rocky8-linux-build systemd[1]: Mounted POSIX Message 
Queue File System.
Oct 09 11:21:41 rocky8-linux-build systemd[1]: Mounted Kernel Debug File 
System.
Oct 09 11:21:41 rocky8-linux-build systemd[1]: Mounted Huge Pages File 
System.
Oct 09 11:21:42 rocky8-linux-build systemd[1]: Mounting FUSE Control 
File System...
Oct 09 11:21:42 rocky8-linux-build systemd[1]: Mounted FUSE Control File 
System.
Oct 09 11:21:42 rocky8-linux-build systemd[1]: Reached target Local File 
Systems (Pre).

Oct 09 11:21:42 rocky8-linux-build systemd[1]: Mounting /boot...
Oct 09 11:21:42 rocky8-linux-build systemd[1]: Mounting /tmp...
Oct 09 11:21:42 rocky8-linux-build systemd[1]: Mounting /var...
Oct 09 11:21:42 rocky8-linux-build kernel: XFS (vda2): Mounting V5 
Filesystem
Oct 09 11:21:42 rocky8-linux-build kernel: XFS (dm-3): Mounting V5 
Filesystem

Oct 09 11:21:42 rocky8-linux-build systemd[1]: Mounting /home...
Oct 09 11:21:42 rocky8-linux-build kernel: XFS (dm-4): Mounting V5 
Filesystem
Oct 09 11:21:42 rocky8-linux-build kernel: XFS (dm-5): Mounting V5 
Filesystem

Oct 09 11:21:42 rocky8-linux-build systemd[1]: Mounted /tmp.
Oct 09 11:21:43 rocky8-linux-build systemd[1]: Mounted /boot.
Oct 09 11:21:43 rocky8-linux-build systemd[1]: Mounting /boot/efi...
Oct 09 11:21:43 rocky8-linux-build systemd[1]: Mounted /boot/efi.
Oct 09 11:21:43 rocky8-linux-build systemd[1]: Mounted /home.
Oct 09 11:21:43 rocky8-linux-build systemd[1]: Mounted /var.
*** Oct 09 11:21:43 rocky8-linux-build systemd[1]: Reached target Local 
File Systems.  <<--- This is correct
Oct 09 11:21:43 rocky8-linux-build systemd[1]: Mounting RPC Pipe File 
System...

Oct 09 11:21:43 rocky8-linux-build systemd[1]: Mounted RPC Pipe File System.

C)  Other times a mount is randomly out of order:
eg:
journalctl --boot=0 | grep -E 'Mounting |Mounted |Local File'
Oct 09 11:21:39 rocky8-linux-build systemd[1]: Mounting Kernel 
Configuration File System...
Oct 09 11:21:39 rocky8-linux-build systemd[1]: Mounted Kernel 
Configuration File System.
Oct 09 11:21:40 rocky8-linux-build systemd[1]: Reached target Local File 
Systems (Pre).
Oct 09 11:21:40 rocky8-linux-build systemd[1]: Reached target Local File 
Systems.

Oct 09 11:21:40 rocky8-linux-build systemd[1]: Mounting /sysroot...
Oct 09 11:21:40 rocky8-linux-build kernel: XFS (dm-0): Mounting V5 
Filesystem

Oct 09 11:21:40 rocky8-linux-build systemd[1]: Mounted /sysroot.
Oct 09 11:21:41 rocky8-linux-build systemd[1]: Mounting /sysroot/usr...
Oct 09 11:21:41 rocky8-linux-build kernel: XFS (dm-2): Mounting V5 
Filesystem

Oct 09 11:21:41 rocky8-linux-build systemd[1]: Mounted /sysroot/usr.
Oct 09 11:21:41 rocky8-linux-build systemd[1]: Stopped target Local File 
Systems.
Oct 09 11:21:41 rocky8-linux-build systemd[1]: Stopped target Local File 
Systems (Pre).
Oct 09 11:21:41 rocky8-linux-build systemd[1]: Mounted POSIX Message 
Queue File System.
Oct 09 11:21:41 rocky8-linux-build systemd[1]: Mounted Kernel Debug File 
System.

Re: [systemd-devel] How to make an encrypted disk mentioned in /etc/crypttab "optional"?

[Aaron Rainbolt]

On 10/9/23 02:38, Andrei Borzenkov wrote:

On Mon, Oct 9, 2023 at 10:10 AM Aaron Rainbolt  wrote:

Good morning/evening, and thanks for your time.

I'm attempting to create a Fedora-based immutable distro (not based on
Silverblue) that stores user data in an encrypted /home partition. The
goal is to have something that behaves somewhat similar to Chrome OS.
One feature I'm attempting to implement is a "guest mode", whereby a
user can sign into the system without providing any password, but if
they do so they don't gain access to the system's owner's data and
virtually anything they do is erased upon shutdown.

In order to do this, I have two /home directories - one is part of the
(immutable) root filesystem, which can only be written to thanks to a
Dracut-created ramdisk overlay. The other is stored in an encrypted
partition. I'm using a crypttab line like this to prepare the encrypted
partition:

  firebook-home LABEL=firebook-crypt none luks,discard,nofail

And I'm using an fstab line like this to mount it:

  /dev/mapper/firebook-home /home ext4 defaults,nofail 0 0


Where is your user home directory located?


That's slightly complicated, since there's two of them in this setup.

The root filesystem is a squashfs. Dracut mounts it at boot and applies 
a ramdisk overlay so that changes can be written to the root filesystem 
but they are all lost at shutdown. I have one /home directory in this 
squashfs, which has a subdirectory /home/user for the user account.


However, I also have a partition with the label "firebook-crypt" that is 
set up as /dev/mapper/firebook-home. It is mounted at /home (hiding the 
/home that is backed by the ramfs overlay) and contains it's own "user" 
directory. So basically if the system boots with the encrypted disk 
mounted, /home is backed by a LUKS partition, otherwise it is backed by 
a ramdisk overlay.



Note that I've marked both of these with "nofail" - the goal is that the
user will be prompted for their password by systemd upon boot, but if
they do not provide the password (by intentionally providing a wrong
password three times), the encrypted drive should not be mounted and the
system should boot normally using the ephemeral home directory provided
by the root filesystem + ramdisk overlay.


I am not sure whether systemd can even express such logic. Check
whether any service involved in logging in has dependency on /home
(like RequiresMountsFor=/home).

Will do, thanks!

This seems to be *almost* working, however if I intentionally provide a
wrong password to the password prompt a few times, it doesn't actually
"give up" on getting a password from me. What it does instead is it
stops asking me for the password at boot, but then rather than starting
GNOME it just leaves me at a console screen. If I am able to get GDM to
appear somehow, I can't sign in.

What I end up doing is switching to a TTY, signing in, and then
elevating to root to troubleshoot. Once I've elevated to root, I get a
`wall` message informing me that the system is *still waiting* for a
password and that I need to run `systemd-tty-ask-password-agent` (I
think?) to provide it. If I go ahead and do this, then restart GDM, I'm
able to sign in after that. (I could be wrong about what command it's
asking me to run, but I think it was `systemd-tty-ask-password-agent`.)

  From my research, it looks like systemd is refusing to ever truly "give
up" on getting the password for the encrypted /home directory, despite
the use of `nofail` in the fstab and crypttab files. I'm not finding any
documentation on how to get systemd to "give up" on getting the
password. For my particular use case, I'd like systemd to just forget
that the encrypted drive exists at all if the wrong password is given.
If the user wants to mount the encrypted drive after that, they should
either reboot or use cryptsetup manually.

Is there any way to make systemd "give up" on getting a password?

Thanks for your help!

Aaron

[systemd-devel] Forward all journal logs to the rootless podman container's STDOUT while running systemd as PID 1

[Chris Suszynski]

Hello,

I posted a question on stackoverflow [1]
,
and I thought I should forward it to this list, as the problem is rather
niche.

[1]
https://stackoverflow.com/questions/77260144/forward-all-journal-logs-to-the-rootless-podman-containers-stdout-while-running

-- 

Chris Suszyński

Senior Software Quality Engineer at Openshift Serverless

Red Hat 

Warsaw, Poland

ksusz...@redhat.com
M: +48 506-564-230 <+48-506-564-230>

GPG: 96C4 97CC AEB0 D718 922B

@RedHat    Red Hat
  Red Hat

Re: [systemd-devel] How to make an encrypted disk mentioned in /etc/crypttab "optional"?

[Andrei Borzenkov]

On Mon, Oct 9, 2023 at 10:10 AM Aaron Rainbolt  wrote:
>
> Good morning/evening, and thanks for your time.
>
> I'm attempting to create a Fedora-based immutable distro (not based on
> Silverblue) that stores user data in an encrypted /home partition. The
> goal is to have something that behaves somewhat similar to Chrome OS.
> One feature I'm attempting to implement is a "guest mode", whereby a
> user can sign into the system without providing any password, but if
> they do so they don't gain access to the system's owner's data and
> virtually anything they do is erased upon shutdown.
>
> In order to do this, I have two /home directories - one is part of the
> (immutable) root filesystem, which can only be written to thanks to a
> Dracut-created ramdisk overlay. The other is stored in an encrypted
> partition. I'm using a crypttab line like this to prepare the encrypted
> partition:
>
>  firebook-home LABEL=firebook-crypt none luks,discard,nofail
>
> And I'm using an fstab line like this to mount it:
>
>  /dev/mapper/firebook-home /home ext4 defaults,nofail 0 0
>

Where is your user home directory located?

> Note that I've marked both of these with "nofail" - the goal is that the
> user will be prompted for their password by systemd upon boot, but if
> they do not provide the password (by intentionally providing a wrong
> password three times), the encrypted drive should not be mounted and the
> system should boot normally using the ephemeral home directory provided
> by the root filesystem + ramdisk overlay.
>

I am not sure whether systemd can even express such logic. Check
whether any service involved in logging in has dependency on /home
(like RequiresMountsFor=/home).

> This seems to be *almost* working, however if I intentionally provide a
> wrong password to the password prompt a few times, it doesn't actually
> "give up" on getting a password from me. What it does instead is it
> stops asking me for the password at boot, but then rather than starting
> GNOME it just leaves me at a console screen. If I am able to get GDM to
> appear somehow, I can't sign in.
>
> What I end up doing is switching to a TTY, signing in, and then
> elevating to root to troubleshoot. Once I've elevated to root, I get a
> `wall` message informing me that the system is *still waiting* for a
> password and that I need to run `systemd-tty-ask-password-agent` (I
> think?) to provide it. If I go ahead and do this, then restart GDM, I'm
> able to sign in after that. (I could be wrong about what command it's
> asking me to run, but I think it was `systemd-tty-ask-password-agent`.)
>
>  From my research, it looks like systemd is refusing to ever truly "give
> up" on getting the password for the encrypted /home directory, despite
> the use of `nofail` in the fstab and crypttab files. I'm not finding any
> documentation on how to get systemd to "give up" on getting the
> password. For my particular use case, I'd like systemd to just forget
> that the encrypted drive exists at all if the wrong password is given.
> If the user wants to mount the encrypted drive after that, they should
> either reboot or use cryptsetup manually.
>
> Is there any way to make systemd "give up" on getting a password?
>
> Thanks for your help!
>
> Aaron
>

[systemd-devel] How to make an encrypted disk mentioned in /etc/crypttab "optional"?

[Aaron Rainbolt]

Good morning/evening, and thanks for your time.

I'm attempting to create a Fedora-based immutable distro (not based on 
Silverblue) that stores user data in an encrypted /home partition. The 
goal is to have something that behaves somewhat similar to Chrome OS. 
One feature I'm attempting to implement is a "guest mode", whereby a 
user can sign into the system without providing any password, but if 
they do so they don't gain access to the system's owner's data and 
virtually anything they do is erased upon shutdown.


In order to do this, I have two /home directories - one is part of the 
(immutable) root filesystem, which can only be written to thanks to a 
Dracut-created ramdisk overlay. The other is stored in an encrypted 
partition. I'm using a crypttab line like this to prepare the encrypted 
partition:


    firebook-home LABEL=firebook-crypt none luks,discard,nofail

And I'm using an fstab line like this to mount it:

    /dev/mapper/firebook-home /home ext4 defaults,nofail 0 0

Note that I've marked both of these with "nofail" - the goal is that the 
user will be prompted for their password by systemd upon boot, but if 
they do not provide the password (by intentionally providing a wrong 
password three times), the encrypted drive should not be mounted and the 
system should boot normally using the ephemeral home directory provided 
by the root filesystem + ramdisk overlay.


This seems to be *almost* working, however if I intentionally provide a 
wrong password to the password prompt a few times, it doesn't actually 
"give up" on getting a password from me. What it does instead is it 
stops asking me for the password at boot, but then rather than starting 
GNOME it just leaves me at a console screen. If I am able to get GDM to 
appear somehow, I can't sign in.


What I end up doing is switching to a TTY, signing in, and then 
elevating to root to troubleshoot. Once I've elevated to root, I get a 
`wall` message informing me that the system is *still waiting* for a 
password and that I need to run `systemd-tty-ask-password-agent` (I 
think?) to provide it. If I go ahead and do this, then restart GDM, I'm 
able to sign in after that. (I could be wrong about what command it's 
asking me to run, but I think it was `systemd-tty-ask-password-agent`.)


From my research, it looks like systemd is refusing to ever truly "give 
up" on getting the password for the encrypted /home directory, despite 
the use of `nofail` in the fstab and crypttab files. I'm not finding any 
documentation on how to get systemd to "give up" on getting the 
password. For my particular use case, I'd like systemd to just forget 
that the encrypted drive exists at all if the wrong password is given. 
If the user wants to mount the encrypted drive after that, they should 
either reboot or use cryptsetup manually.


Is there any way to make systemd "give up" on getting a password?

Thanks for your help!

Aaron