Bug#1098221: systemd: systemd-cryptsetup-generator freaks out on debian specific options in crypttab

[Luca Boccassi]

On Tue, 18 Feb 2025 14:10:59 +0100 =?utf-8?Q?=C5=81ukasz?= Stelmach
<steelman at post.pl> wrote:
> Luca Boccassi <bluca at debian.org> writes:
> 
> > On Mon, 17 Feb 2025 22:27:15 +0100 =?utf-8?Q?=C5=81ukasz_Stelmach?=
> > <steelman at post.pl> wrote:
> > Instead, please send a PR upstream to make the generator skip
> > parameters starting with 'x-' as it is customary in other
configuration
> > settings, and then change the Debian-specific scripts to use that
> > prefix for Debian-specific options. This is something that is very
> > likely to be accepted upstream.
> 
> I am afraid this isn't viable solution as the options in question
have
> long been documented in Debian's crypttab(5) from the cryptsetup
> package and renaming them would break running configurations.

They are debianisms, and as such they can be changed. Not saying it
would be easy, but merely that it would be doable to migrate them via
maintainer scripts from old format to new.

> There are ways to work around these problems, I know, but they are
> just
> that (documenting them may be a solution). IMHO
> systemd-cryptsetup-generator provided in a Debian package should not
> produce bogus output from a configuration file that is valid for the
> other package that doesn't conflict with systemd. That is why I
> believe
> my patch should be added to those ./debian/patches/debian directory
> of
> the systemd package. If you think the patch isn't the right solution
> (I
> don't insist), can you suggest a different one I could implement.

Sorry, but again, out-of-tree patches are not going to happen, I worked
way way too hard for way way too long to get rid of the gigantic pile
of technical debt and out-of-tree patches that were present, to let
them slid back in through the backdoor.

If you want to try and solve this problem, what I mentioned above is
one possible solution. You could also split these initrd scripts in a
different package, and then I'd be fine with adding a conflict against
the new package in the systemd-cryptsetup package so that they cannot
be coinstalled. Or you could change such scripts to mask the generator
in /run/ in case unsupported options are used, that would be fine too,
as long as it's in an optional package that doesn't stop the upstream
cryptsetup binaries and libraries from being installed and used with
sd-cryptsetup.