[pkg-cryptsetup-devel] Bug#1092977: debian-installer: systemd-cryptsetup package not installed on encrypted system

[Pascal Hambourg]

On 24/05/2025 at 20:01, Cyril Brulebois wrote:
> Pascal Hambourg <pascal at plouf.fr.eu.org> (2025-05-24):
>> On 24/05/2025 at 18:43, Guilhem Moulin wrote:
>>> On Sat, 24 May 2025 at 17:41:42 +0200, Cyril Brulebois wrote:
>>>> If we were to pull systemd-cryptsetup in the mix, should there by
>>>> any restrictions/checks before deciding to do so?
>>
>> Is tweaking d-i to not install systemd at all (like Devuan) a
>> supported use case ?
> 
> If people feel strongly about their init system, they can do whatever
> they want to obtain a system they like. I don't see why we would care
> about that for them.

Just asking, in case Dabian had some policy about Debian derivatives.

>> Queuing cryptsetup-initramfs was convenient because it pulled all
>> other cryptsetup packages at once.
> 
> I'm not sure when you showed up but there's been some back and forth on
> that topic, with package splits and replits in different ways over the
> last few release cycles.

I subscribed to debian-boot in 2021.

>>> AFAIK d-i won't allow setting up a system *requiring* systemd-cryptsetup
>>> out of its menu
>>
>> I just did it with manual partitioning, not "out of its menu".
>> Create an encrypted volume and use it as /home, /srv or whatever is not
>> mounted in the initramfs.

(I assume your next question was about this part of the quote, so 
cutting the rest)

> So that was with current d-i, and not resorting to dropping to a shell
> and doing nasty things behind its back? Things don't work out of the
> box? But does that start working if you additionally install
> systemd-cryptsetup? If so, without any additional configuration?

Boot with debian-trixie-DI-rc1-amd64-netinst.iso, expert install, no 
hack in the shell, encrypted /home using only regular menus -> installed 
system boot: no passphrase prompt, fallback to emergency shell. Install 
systemd-cryptsetup -> it works without any additional configuration.

> (I'm not too afraid of the extra dependencies — already there — if we
> were to pull this package “blindly” alongside cryptsetup, but the amount
> of extra systemd targets and possible complexity doesn't make me
> confident about being able to sort things out if some problems start
> popping up after we start doing that. After all, we're just weeks away
> from the release, it doesn't leave a lot of time to debug regressions or
> just walk back…)

Quoting Guilhem, "after all, systemd-cryptsetup used to be included in 
the systemd binary package up to bookworm".