Re: Bug#1108823: trixie: mention issue with cryptsetup support having been moved to systemd-cryptsetup
Richard Lewis wrote:
> Konstantin Khomoutov <kostix@bswap.ru> 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
Reply to: