Bug#1092968: debian-installer: LUKS encrypted installation does not use /etc/crypttab to decrypt other drives

[Ted]

Package: debian-installer
Severity: important
X-Debbugs-Cc: ***@gmail.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

* What led up to the situation?

I did a full-disk luks encrypted installation using trixie-DI-alpha1
_Trixie_ - Official Alpha amd64 NETINST with firmware 20241230-11:26.

* What exactly did you do (or not do) that was effective (or
ineffective)?

I edited my /etc/crypttab to include other encrypted drives and
partitions. The drives had keyfiles that had been added with cryptsetup
using "luksAddKey UUID=WhaEver321 /someplace/keyfile-somename" as I
normally do. However when rebooting I was dropped to an emergency shell
because the partitions had not been decrypted. Adding the partitions to
the keyfiles and double-checking the crypttab did not help. I was forced
to mark the encrypted mounts in my fstab as "noauto" in order to boot to
the GUI.

I checked /usr/lib/systemd/system-generators/ and found there was no
unit called systemd-cryptsetup-generator as there was in other Debian
installations with encrypted partitions.

I installed the package 'systemd-cryptsetup' & a couple of others that
probably were not necessary (cryptmount, pmount) and checked again and
found there was now a unit:
/usr/lib/systemd/system-generators/systemd-cryptsetup-generator

I removed the 'noauto' options from my fstab and was able to boot
normally with my drives properly mounted.

* What was the outcome of this action?

I was able to boot normally.

* What outcome did you expect instead?

Any installed system with luks encryption support should be able to read
and decrypt entries in /etc/crypttab with properly processed keyfiles
without installing additional packages.

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.12.6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

[Cyril Brulebois]

Hi Ted,

Post by Ted
Any installed system with luks encryption support should be able to
read and decrypt entries in /etc/crypttab with properly processed
keyfiles without installing additional packages.

I understand it might have been a little frustrating that it didn't work
out of the box, but adjusting a critical configuration file without
making sure the tools that are required are installed doesn't really
strike me as something that should be covered by the installer



Cheers,

[Ed Biow]

Post by Cyril Brulebois
Hi Ted,

Post by Ted
Any installed system with luks encryption support should be able to
read and decrypt entries in /etc/crypttab with properly processed
keyfiles without installing additional packages.

I understand it might have been a little frustrating that it didn't work
out of the box, but adjusting a critical configuration file without
making sure the tools that are required are installed doesn't really
strike me as something that should be covered by the installer…

Cyril, I've been using full disk luks encryption on Debian, Ubuntu, even
occasionally on Fedora, Arch & openSuse, sometimes even with a LVM for
at least 10 years, and never had a problem opening and mounting other
luks encrypted drives at boot using a keyfile referenced in
/etc/crypttab to decrypt the drives at boot and then mount them via the
fstab.

Here is a summary of the process:

https://www.cyberciti.biz/hardware/cryptsetup-add-enable-luks-disk-encryption-keyfile-linux/

https://www.redhat.com/en/blog/disk-encryption-luks

The only package that I believe was needed to be present is cryptsetup,
which is naturally already installed if you are doing a luks-encrypted
installation (although if you are using LVM you should make sure lvm2
and maybe mdadm are installed, as well). cryptsetup was indeed present
on my fresh trixie install. However on trixie/testing & sid there is a
new package called systemd-cryptsetup, which is not in the stable or
older repositories.

https://packages.debian.org/trixie/systemd-cryptsetup

I have verified that this package that is necessary to create
/usr/lib/systemd/system-generators/systemd-cryptsetup-generator which is
required to open other luks encrypted partitions at boot using the
/etc/crypttab file.

I wasn't doing anything especially weird (other than using Linux &
encryption), systemd-cryptsetup should be a dependency of cryptsetup to
make the OS work like it is designed to do.

Regards,

Post by Cyril Brulebois
Cheers,
--
D-I release manager -- Release team member -- Freelance Consultant

[Cristian Rigamonti]

Post by Ed Biow
I wasn't doing anything especially weird (other than using Linux &
encryption), systemd-cryptsetup should be a dependency of cryptsetup
to make the OS work like it is designed to do.

+1

And please note that the problem occurs not only when the user creates
an encrypted swap partition manually after the installation, but also
when partman is used to do it during the installation process, see bug #1092977

systemd-cryptsetup should always be installed, whenever the user decides to create
an encrypted partition in partman (if it's possible at that time, otherwise it
should always be installed, to err on the side of caution).

Cri