[kd913]

I am confused at which stage this is happening.

Is this after the bootloader, after initramfs but now systemd-cryptsetup is loaded and unlock the first disk?

AFAIK when I do my first disk unlock, at that point does systemd units get loaded including systemd-mounting.

Those mounts can already already mount/unlock encrypted secondary disks, based on the keyfiles stored on the now decrypted disk. So what exactly in this case is the advantage of any of this?

EDIT: Also, is there any discussions over ftpm support? Last I checked TPM2 was ok, but ftpm (which most intel/AMD now using) are a bit flaky in regards to support.

[dathinab]

Quoting the man page:

At early boot and when the system manager configuration reloaded, /etc/crypttab is translated systemd-cryptsetup@.service units by systemd-cryptsetup-generator(8).

So this should run during mkinitcpios systemd hook, I think (i.e.during "initramfs times").

EDIT: Also as a service it can also run later one if you e.g. plug in a LUKS encrypted hard drive I think. I haven't tried it out.

[Foxboron]

Initramfs I believe. `systemd-cryptenrol` would probably just be a binary like any other and wrap `cryptsetup` which is on your initramfs.

[gdamjan1]

here's what I had to do on Arch to enable unlocking the root volume with TPM2: https://github.com/systemd/systemd/pull/17741#issuecomment-7...

it'll need some work from the distros so the whole process is a bit more straightforward.

[gdamjan1]

fTPM on my Ryzen 3600 worked.