Richard Lewis wrote: > Konstantin Khomoutov <[email protected]> writes: >> 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) > > Not sure what others think of this? > > to me, it sets a bad precedent to try and support this kind of > thing. Recommends are installed by default, and should only removed by > people who know what they are doing: i think that's a policy that has > been consistently stated by debian for at least a decade? > > If people are playing with recommends of critial packages like systemd > then they should be expected to know what they are doing, including on > upgrades. > > On the other hand, not booting is obviously a bad outcome, so maybe this > is an exceptional case?
It's one of those things that people hand out bad advice about on (e.g.) debian-user, even to the point of blithely recommending APT configuration options that make it the default. This issue is a big enough risk that it seems to me we probably do want to flag it up, but it might even be worth taking the opportunity to hint that this kind of consequence is why it's not recommended. >> or the user for some reason has >> initiated the upgrade process with a call like >> >> apt dist-uprade --no-install-recommends > > this seems like a very bad, and unsupported, approach! Yes: for a start it would leave my testbed system with missing firmware (because trixie's firmware-misc-nonfree Recommends various things that used to have a direct Provides). If you've run trial dist-upgrades on sacrificial clone systems like I do, and know you *won't* get that problem, maybe it could make sense, but it's a lot of effort to avoid five minutes spent tidying every alternate year! >> 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. > >> 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 <https://wiki.debian.org/CrossGrading>`__ 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``. > > maybe we just include this part (with corrected markup), plus a > statement that the ``systemd`` package in Trixie recommends the new > package so you should check it is installed. Beefing it up a bit: .. _systemd-cryptsetup-support-moved-to-separate-package: (Shouldn't there be a visible heading here?) Support in `systemd` for opening and mounting encrypted storage devices at boot has been moved into a separate package, `systemd-cryptsetup`, which is recommended by the `systemd` package in trixie. Users of encrypted filesystems should double-check that this package is installed as intended before rebooting. This is a case where overriding standard dependency resolution in `apt` can result in an unbootable system. (Or of course "if people recommend ignoring Recommends we recommend ignoring them"...) -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
