search

r0b0 / debian-installer

Opinionated Debian Installer - alternative debian installer for laptops and desktop PCs
GNU General Public License v3.0
34 stars 3 forks source link

fix: prefix luks kernel params with rd #79

Closed romangg closed 4 months ago

romangg commented 4 months ago

With the prefix other devices in /etc/crypttab won't get ignored on boot. See Arch wiki.

r0b0 commented 4 months ago

Hi Roman,

I don't quite understand this - according to upstream docs, the rd. parameters are only applied only in initrd and the ones without rd. are applied both in initrd and in the main system.

So to me, it doesn't make sense that adding rd. would in fact prevent them from being ignored in your tests.

These settings have been in the installer for quite some time actually and I never had any problems with them.

romangg commented 4 months ago

In my test system I tried adding after installation another encrypted hard disk for data. This disk is supposed to be opened at boot through an entry in /etc/crypttab and a key-file stored on the encrypted root system.

But when trying it with the rd-less parameters this didn't work and dmesg logged the message:

Not creating device 'devicename' because it was not specified on the kernel command line.

The Arch wiki says about luk. and rd.luks. parameters in combination with /etc/crypttab usage:

If you are using /etc/crypttab or /etc/crypttab.initramfs together with luks.* or rd.luks.* parameters, only those devices specified on the kernel command line will be activated.

So there is a blocking mechanism that makes the system ignore entries in the crypttab files when parameters on the command line are set. There is a workaround though:

To activate all devices in /etc/crypttab do not specify any luks. parameters and use rd.luks..

I think usage of /etc/crypttab is common enough to warrant usage of the rd prefix, especially because there is no downsides of using it as far as I know and according to my tests.

r0b0 commented 4 months ago

Aha, understood, yes, we definitely don't want to stop crypttab from working.

I'll test this and merge, hopefully over the weekend

romangg commented 4 months ago

I'll test this

Just a heads-up: I currently installing on another machine that has TPM support. The install did mention it being enrolled but I still have to insert the encryption password at boot.

I don't think it's related to the change here as manually removing the rd suffix again didn't fix it. But if you got a TPM-enabled test setup, double-check it anyway.

romangg commented 4 months ago

I had to issue again from the installed system:

systemd-cryptenroll --tpm2-device=auto /dev/disk/by-uuid/<my-disk-uuid> --tpm2-pcrs="7+14"

Now it works. I don't think this problem is related.