Root partition encryption: how to copy the generated crypttab to the initrd?

[Dragonink]

I am trying to create an image with the root partition encrypted (using repart.d Encrypt option),
thus I enabled the generated of the default initrd in a separate boot partition.

But the crypttab generated by systemd-repart ends up in the root partition, not in the initrd.
Also the Passphrase file is not copied at all.
Is there a way to copy them into the initrd?

[starkmarkus]

I would not copy the generated crypttab and passphrase file into the initrd by default. If the initrd or ESP is not part of your trust boundary, that can undercut the point of root encryption.

For mkosi, the cleaner path is usually to customize the initrd itself. The mkosi docs describe building a separate initrd and passing it with --initrd or Initrd=, and the initrd customization lives under /usr/lib/mkosi-initrd with local overrides in /etc/mkosi-initrd. That is a better place to add unlock plumbing than moving files out of the final root filesystem after repart has already run.

So I would first clarify which unlock mode you actually want: interactive passphrase, TPM-bound unlock, or a shipped key file or credential. If you share the exact Encrypt= or repart setup, the supported mkosi path can be narrowed down more precisely.

[Dragonink]

Not copying the passphrase I can understand.
But why not copy the crypttab? It is just a configuration file and does not contain any sensitive data, isn't it?

I can only use Encrypt=key-file, my current setup (the interactive passphrase) works, so I don't really need to copy the Passphrase file.
However, because I can't copy the crypttab, I needed to add some "hard-coded" kernel parameters that I would rather avoid.

How does building a custom initrd subimage help here? The crypttab file is generated by systemd-repart after all images are built, so it wouldn't exist when building the initrd.

[starkmarkus]

Good point - I think I overstated the security concern for crypttab itself. The sensitive part is the key/passphrase file, not usually the crypttab entry as such.

And yes, you’re right about the ordering problem: if the crypttab is generated by systemd-repart only after the images/initrd have already been built, then simply “customizing the initrd” does not by itself solve the problem. That only helps if the unlock configuration can be known ahead of time and added to the initrd while it is being built.

So for your case, I think there are basically three paths:

1. Keep using kernel command-line parameters such as rd.luks.uuid=, rd.luks.name=, rd.luks.key= or rd.luks.options=. That is somewhat ugly, but it is the mechanism systemd-cryptsetup-generator explicitly supports for the initrd phase.

2. Make the unlock configuration deterministic enough that you can provide an equivalent static crypttab entry in the initrd before repart runs.I’m not sure this is possible in your exact setup if the relevant identifiers are only known after repart has formatted the LUKS volume.

3. Post-process the generated image/initrd/UKI after systemd-repart has produced the final crypttab: extract the generated entry and rebuild or replace the initrd/UKI. I do not know whether mkosi currently has a built-in hook for that ordering, though. If not, that may indeed be the missing feature.

So I would revise my previous answer: a custom initrd is only useful if the crypttab-equivalent data is available before initrd generation. If the desired input is specifically the crypttab generated by systemd-repart after image creation, then I do not think my suggested path solves that directly. This may be a valid mkosi feature request: some way to propagate the generated crypttab into the initrd/UKI after repart has run, without manually duplicating it via kernel parameters.