Hi, On Sat, 24 May 2025 at 17:41:42 +0200, Cyril Brulebois wrote: > 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?
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). > 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 and takes care of unlocking remaining devices past initramfs stage. -- Guilhem.
signature.asc
Description: PGP signature
