Bug#1108823: trixie: mention issue with cryptsetup support having been moved to systemd-cryptsetup

[Guilhem Moulin]

Hi,

[src:cryptsetup co-maintainer here, but not involved in src:systemd]

>.. _systemd-cryptsetup-support-moved-to-separate-package:

Thanks for the suggestion!  Makes sense to add this in the release notes
indeed.

> The ``systemd`` package in Trixie recommends it, but on systems with
> the installation of recommended packages diabled it will not be automatically
> installed by the upgrade process, likely rendering the system unbootable.

I think that statement is too strong, as the issue “only” affects systems
with encrypted devices that are 1/ prerequisite for a unit file (for
instance holding a file system to automount at boot time), and 2/ not
unlocked at early boot stage (so not holding the root FS, /usr, or the
resume device).  So the “LVM-over-crypt” systems one gets out of d-i are
unaffected.

> If you have installation of recommended packages disabled,
> and have any filesystem residing on an encrypted storage device
> listed in ``/etc/fstab`` (or being mounted by a custom ``systemd`` unit file),
> be sure to install the ``systemd-cryptsetup`` package
> before rebooting the system.

Suggestion: “If you have an encrypted device which is not holding the
root FS, /usr, or a resume device, then be sure to …”.

See also the systemd NEWS entry for version 256-2.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1108823: trixie: mention issue with cryptsetup support having been moved to systemd-cryptsetup

[Konstantin Khomoutov]

Package: release-notes
Severity: normal
Tags: patch

Hi!

The support for opening and mounting encrypted storage devices (managed by
cryptsetup`) in systemd has been moved into a separate package,
systemd-cryptsetup`. If a system being upgraded to Trixie has installation of
recommended packages disabled (like does mine) or the user for some reason has
initiated the upgrade process with a call like

  apt dist-uprade --no-install-recommends

and the user has any encrypted filesystem listed in /etc/fstab or in a custom
systemd unit file of type "mount", the system may not boot properly - see,
for example, my case [1], and also [2] and [3].

I hence recommend to prominently mention this issue in the Trixie release
notes.

I've tried to come up with the text for this (patch attached) but feel free to
make arbitrary changes to it or use it merely as a reference.

 1. https://lists.debian.org/debian-devel/2025/07/msg00012.html
 2. https://bugs.debian.org/1079644
 3. https://bugs.debian.org/1076208

diff --git a/source/issues.rst b/source/issues.rst
index fea92a02..6698bb1c 100644
--- a/source/issues.rst
+++ b/source/issues.rst
@@ -41,6 +41,20 @@ possible, or retiring the hardware.
 `Cross-grading `__ without a
 reinstall is a technically possible, but risky, alternative.
 
+.. _systemd-cryptsetup-support-moved-to-separate-package:
+
+Support in ``systemd`` for opening and mounting encrypted storage devices
+at boot has been moved into a separate package, ``systemd-cryptsetup``.
+The ``systemd`` package in Trixie recommends it, but on systems with
+the installation of recommended packages diabled it will not be automatically
+installed by the upgrade process, likely rendering the system unbootable.
+
+If you have installation of recommended packages disabled,
+and have any filesystem residing on an encrypted storage device
+listed in ``/etc/fstab`` (or being mounted by a custom ``systemd`` unit file),
+be sure to install the ``systemd-cryptsetup`` package
+before rebooting the system.
+
 .. _openssh-pam-environment-removed:
 
 openssh-server no longer reads ~/.pam_environment