On 14/01/2025 at 02:51, Dave wrote:
(Possible dupe of 1092968)
I installed Debian testing from a live CD.(...)
During the installation process, I set up 2 encrypted partitions:
- btrfs on LVM on LUKS for the root file system
- swap on an encrypted partition with a random key
The encrypted partition for the root file system correctly prompted(...)
for the passphrase when booting, and worked completely normally.
systemd-cryptsetup package should be installed.
systemd-cryptsetup is a new package split from systemd. systemd
recommends it but it may not be available when the base system is
installed and/or recommends are ignored.
I am quite puzzled how the resulting system was able to decrypt one
partition, but not the other.
The LUKS volume containing the root filesystem is decrypted by the
initramfs which does not need systemd-cryptsetup.
systemd-cryptsetup is included in netinst images but d-i does not
install it. I guess Recommends: are ignored by debootstrap.
The LUKS volume containing the root filesystem is decrypted by the initramfs which does not need systemd-cryptsetup.
systemd-cryptsetup is required to open encrypted volumes other than those which are already opened by the initramfs (/, /usr, hibernation swap). I believe this bug should be fixed before Trixie release so added it to the wiki wishlist.
And I'm only spotting one place where cryptsetup makes its way into
/target, via partman-crypto's finish.d/crypto_aptinstall:
if grep -q " device-mapper$" /proc/misc; then
# We can't check the root node directly because root could be
# on an LVM LV on top of an encrypted device
if type dmsetup >/dev/null 2>&1 && \
dmsetup table | cut -d' ' -f4 | grep -q "crypt" 2>/dev/null; then
apt-install cryptsetup-initramfs || true
fi
fi
If we were to pull systemd-cryptsetup in the mix, should there by any restrictions/checks before deciding to do so?
How are things between systemd-cryptsetup and cryptsetup itself? Is that
a peaceful cohabitation/cooperation, or is that going to look like some competition, with race conditions and the like?
IMHO an ideal fix would be to install cryptsetup-initramfs only when
some device needs to be unlocked by initramfs-tools, and only install systemd-cryptsetup if there are remaining encrypted devices.
I recall suggesting that before in https://bugs.debian.org/930228 , but apparently never opened a follow-up bug to track that let alone suggest
a patch for it… Anyway that's probably too late at this point of the release cycle.
AFAIK d-i won't allow setting up a system *requiring* systemd-cryptsetup
out of its menu, so perhaps echoing systemd's NEWS entry in the release
notes would be enough? If not, then installing systemd-cryptsetup
alongside cryptsetup-initramfs would solve the issue (after all systemd's cryptsetup integration used be included in the systemd binary package up
to bookworm).
I have both installed on many systems and AFAIK they cohabit well. cryptsetup's init scripts are inert and takes care of unlocking
remaining devices past initramfs stage.
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?
IMHO an ideal fix would be to install cryptsetup-initramfs only when
some device needs to be unlocked by initramfs-tools, and only install systemd-cryptsetup if there are remaining encrypted devices.
AFAIK d-i won't allow setting up a system *requiring* systemd-cryptsetup
out of its menu
How are things between systemd-cryptsetup and cryptsetup itself? Is that
a peaceful cohabitation/cooperation, or is that going to look like some
competition, with race conditions and the like?
I have both installed on many systems and AFAIK they cohabit well. cryptsetup's init scripts are inert
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 ?
IMHO an ideal fix would be to install cryptsetup-initramfs only when
some device needs to be unlocked by initramfs-tools, and only
install systemd-cryptsetup if there are remaining encrypted devices.
It depends which criteria are used to define "ideal", e.g. minimal set
of installed packages vs maximum versatility.
Queuing cryptsetup-initramfs was convenient because it pulled all
other cryptsetup packages at once.
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.
How are things between systemd-cryptsetup and cryptsetup itself? Is that a peaceful cohabitation/cooperation, or is that going to look like some competition, with race conditions and the like?
I have both installed on many systems and AFAIK they cohabit well. cryptsetup's init scripts are inert
They are masked by systemd. I tried to unmask them but the passphrase
prompt is not displayed.
Pascal Hambourg <pascal@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.
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.
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.
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?
(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…)
I subscribed to debian-boot in 2021.
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.
Quoting Guilhem, "after all, systemd-cryptsetup used to be included in
the systemd binary package up to bookworm".
Pascal Hambourg <pascal@plouf.fr.eu.org> (2025-05-24):
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.
OK, thanks for confirming. I'm not sure if the logic around the cryptsetup-initramfs installation did or would pick up that use case.
Was cryptsetup-initramfs installed?
I'm not sure how to best spot the need for systemd-cryptsetup in those
cases, I'm really just familiar with the usual guided encrypted LVM scenario… If someone wants to propose some logic, I'm all ears.
What do /etc/fstab and /etc/crypttab look like?
Yes:
May 24 10:12:30 apt-install: Queueing package cryptsetup-initramfs for later installation
ACK. Modified the hook to pull both packages (and pushed master).
Modified debian-cd to ensure it's available (see kibi/for-master).
This seems to work fine.
You can experiment with:
https://people.debian.org/~kibi/bug-1092977+intel/
If tests look good to you, I'll upload partman-crypto.
Just for my own education, how come systemd-cryptsetup was already
included in netinst ? As a Recommends: of other included packages ?
Tested successfully with the two following use cases:
- manual partitioning with encrypted /home -> bug fixed
- guided partitioning with encrypted LVM -> no regression
Note: users who install without any encryption and later add an
encrypted volume will still need to install systemd-cryptsetup in
addition to cryptsetup, so Trixie's behaviour will not be the same as previous releases. The only way to keep the same behaviour would be
to always install systemd-cryptesetup.
Things change over time, we can't install the exact same system all the
time. I'm not entirely sure about what to do with this particular
package… to me it kind of looks like “I want to use LVM all of sudden
and now I have to install lvm2?!”.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 489 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 14:02:23 |
| Calls: | 9,665 |
| Files: | 13,712 |
| Messages: | 6,167,660 |