Re: systemd-cryptsetup

[Vincent Lefevre]

On 2024-07-14 13:17:45 +0200, Lists wrote:
> On 2024-07-14 11:00, Nicolas George wrote:
> > Hi.
> > 
> > In case you are running unstable or testing and it recently started
> > blocking at boot waiting for encrypted swap or something to do with
> > encrypted disks:
> > 
> > Check if systemd-cryptsetup is installed.
> > 
> > HtH
> 
> Thanks for the confirmation!
> 
> I downloaded debian-installer for testing yesterday a got exactly this
> problem when setting up a new system with encrypted / and /home partitions.
> When I researched the problem I encountered some posts stating that systemd
> had its own implementation for cryptsetup and that there were compatibility
> issues. The x-initrd.attach notices were my first queue to start thinking in
> the direction of systemd.
> 
> 
> Why the *&^%#@! it is necessary to have this borg-like behaviour of systemd
> is beyond me. This is not the first time it is causing problems. TBH, this
> is more an ommission of d-i than of systemd. But then again, it would not
> have happened if there was just one implementation of cryptsetup.
> 

systemd has "Recommends: [...] systemd-cryptsetup [...]".

So this is the following bug:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931283

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: systemd-cryptsetup

[Nicolas George]

Lists (12024-07-16):
> In that case you were correct. I had found posts online where people were
> pointing in the direction of systemd and due to the problem with
> systemd-cryptsetup you warned us about I was inclined to take those posts at
> face value. It seems that was not "fair".

That happens.

Note that the systemd-cryptsetup I had is not the fault of systemd
either:

Package: systemd-cryptsetup
Source: systemd

It happened because Debian chose to split it into a separate package,
probably to avoid pulling libcryptsetup and its dependencies into the
core system.

Regards,

-- 
  Nicolas George

Re: systemd-cryptsetup

[Lists]

On 2024-07-16 12:51, Nicolas George wrote:

Lists (12024-07-16):

That referred to a warning I got after booting up after d-i finished
installing the system. The exact message shown was this:

cryptsetup: WARNING nvme1n1p3_crypt: ignoring unknown option
'x-initrd.attach'



This message comes from /usr/lib/cryptsetup/functions, a file added by
the Debian packaging. Nothing to do with systemd.


In that case you were correct. I had found posts online where people 
were pointing in the direction of systemd and due to the problem with 
systemd-cryptsetup you warned us about I was inclined to take those 
posts at face value. It seems that was not "fair".


Grx HdV

Re: systemd-cryptsetup

[Nicolas George]

Lists (12024-07-16):
> That referred to a warning I got after booting up after d-i finished
> installing the system. The exact message shown was this:
> 
> cryptsetup: WARNING nvme1n1p3_crypt: ignoring unknown option
> 'x-initrd.attach'


This message comes from /usr/lib/cryptsetup/functions, a file added by
the Debian packaging. Nothing to do with systemd.

Regards,

-- 
  Nicolas George

Re: systemd-cryptsetup

[Lists]

On 2024-07-16 11:52, Nicolas George wrote:


I do not know what you are referring to when you talk about
x-initrd.attach, you were too terse. But I notice that you talked about
it in the same paragraph that you reported the inaccurate information
that systemd has its own implementation of cryptsetup, so I suggest you
might want to check if what you read about is is not inaccurate too.


That referred to a warning I got after booting up after d-i finished 
installing the system. The exact message shown was this:


cryptsetup: WARNING nvme1n1p3_crypt: ignoring unknown option 
'x-initrd.attach'


> Anyway, remember that x- means that it is a non-standard option.

I know.

Grx HdV

Re: systemd-cryptsetup

[Nicolas George]

Lists (12024-07-15):
> For the most part I understand your point of view. As a matter of fact I am
> not even opposed to systemd as such [1], but over the years I have had my
> share of problems that in the end proved to be caused by some transition to
> systemd. This has made me a bit wary of it.

A complex transition will always have bugs. Even when the target of the
transition is undoubtedly the best, which is not the case here.

> That might be, but to me notices about things like x-initrd.attach not being
> recognized do point in the direction of incompatibility or at least
> differences in the way cryptsetup is handled that shouldn't happen for
> something that is relied upon by so many.

I do not know what you are referring to when you talk about
x-initrd.attach, you were too terse. But I notice that you talked about
it in the same paragraph that you reported the inaccurate information
that systemd has its own implementation of cryptsetup, so I suggest you
might want to check if what you read about is is not inaccurate too.

Anyway, remember that x- means that it is a non-standard option.

> To be clear: I wasn't aiming to restart the heated discussions on systemd on
> this list again! That is long behind us. It was just a personal feeling of
> someone who has been bitten once again by changes with systemd involved. In
> this case it was more of a d-i thing than a systemd thing anyway.

There is little doubt that along with the enhancement compared to the
bunch of unreliable shell scripts, systemd brought its own set of
trouble in the form of a resolute break from the Unix tradition and
habits.

It is a tragedy that modern boot and monitoring systems that respect the
tradition were not mature enough at the right time.

Regards,

-- 
  Nicolas George

Re: systemd-cryptsetup

[Lists]

Hi Nicolas,

Thanks for the explanation.

For the most part I understand your point of view. As a matter of fact I 
am not even opposed to systemd as such [1], but over the years I have 
had my share of problems that in the end proved to be caused by some 
transition to systemd. This has made me a bit wary of it.


On 2024-07-15 11:24, Nicolas George wrote:

Lists (12024-07-14):

When I researched the problem I encountered some posts stating that systemd
had its own implementation for cryptsetup


This is not true. systemd-cryptsetup uses libcryptsetup, it is mostly
only glue.


That might be, but to me notices about things like x-initrd.attach not 
being recognized do point in the direction of incompatibility or at 
least differences in the way cryptsetup is handled that shouldn't happen 
for something that is relied upon by so many.


To be clear: I wasn't aiming to restart the heated discussions on 
systemd on this list again! That is long behind us. It was just a 
personal feeling of someone who has been bitten once again by changes 
with systemd involved. In this case it was more of a d-i thing than a 
systemd thing anyway.


[1] Although I have to admit that, as an old fart, I still do adhere to 
the UNIX adagio of KISS. systemd is definitely not to be found in that 
department. Not even close. But I do understand why a change was needed 
and that systemd is a step forward in an ever more complex environment.


Grx HdV

Re: systemd-cryptsetup

[Nicolas George]

Lists (12024-07-14):
> When I researched the problem I encountered some posts stating that systemd
> had its own implementation for cryptsetup

This is not true. systemd-cryptsetup uses libcryptsetup, it is mostly
only glue.

> 
> Why the *&^%#@! it is necessary to have this borg-like behaviour of systemd
> is beyond me. This is not the first time it is causing problems. TBH, this
> is more an ommission of d-i than of systemd. But then again, it would not
> have happened if there was just one implementation of cryptsetup.
> 

It is not necessary to use systemd: you are free to use a bunch of
unreliable shell scripts to boot your system, as used to be the case, or
to use any of the other replacements for the bunch of unreliable shell
scripts that are better than systemd.

But the bunch of unreliable shell scripts had reached its limits with
hot-pluggable devices, and the other replacements are more obscure, and
usually less mature due to lack of hackerpower. That is why when Debian
decided to ditch the bunch of unreliable shell scripts, it chose
systemd: Debian developers are here to package things, not develop them.

So if you want to either go back or go forward in a different direction,
you have to do it on your own efforts.

Now, why does systemd have this “borg-like” behavior of having its own
package to handle crypptab?

Unlike the bunch of unreliable shell scripts, where there is a long list
of commands and if that list is executed in sequence it should result in
a booted system, if you are lucky, systemd has concepts of running or
failed units with dependencies, so that it knows that it must start the
database before running the web app, but mount the database storage
before starting the database, and it can notify that an unit has
suddenly failed, and so on.

systemd knows to read /etc/fstab, so when it sees:

/dev/mapper/aimlin-tempswapnoneswapdefaults 0 0

it defines an unit “swap” that depends on an unit “device”. But then it
finds the device does not exist: is it slow to initialize? is it
failing? is there a bug in the configuration? systemd cannot guess.

Installing systemd-cryptsetup teaches systemd to parse /etc/crypttab.
Now, systemd sees:

aimlin-tempswap /dev/disk/by-partlabel/aimlin_swap /dev/urandom 
swap,cipher=aes-cbc-essiv:sha256,size=256

and it knows that in order to get /dev/mapper/aimlin-tempswap it needs
/dev/disk/by-partlabel/aimlin_swap and invoke a few commands, and lo!,
/dev/disk/by-partlabel/aimlin_swap does exist, because lvm2 is an early
dependency.


If somebody is not capable of writing whatever necessary to turn a
kernel just executing init into a fully usable system, even if it is
fragile and completely specific for a particular setup, the relevance of
their criticism about systemd will be fatally limited.


Regards,

-- 
  Nicolas George

Re: systemd-cryptsetup

[Michel Verdier]

On 2024-07-14, Erwan David wrote:

> I have a "full" disk encryption as made by the installer, thus mounted in the
> initramfs, so it may be a little different

If "full disk" include /boot you should be ask for password by grub. Else
it is initramfs and you should be ask by cryptsetup
(package cryptsetup-initramfs).

Re: systemd-cryptsetup

[Lists]

On 2024-07-14 11:00, Nicolas George wrote:

Hi.

In case you are running unstable or testing and it recently started
blocking at boot waiting for encrypted swap or something to do with
encrypted disks:

Check if systemd-cryptsetup is installed.

HtH


Thanks for the confirmation!

I downloaded debian-installer for testing yesterday a got exactly this 
problem when setting up a new system with encrypted / and /home 
partitions. When I researched the problem I encountered some posts 
stating that systemd had its own implementation for cryptsetup and that 
there were compatibility issues. The x-initrd.attach notices were my 
first queue to start thinking in the direction of systemd.



Why the *&^%#@! it is necessary to have this borg-like behaviour of 
systemd is beyond me. This is not the first time it is causing problems. 
TBH, this is more an ommission of d-i than of systemd. But then again, 
it would not have happened if there was just one implementation of 
cryptsetup.



Grx HdV

Re: systemd-cryptsetup

[Erwan David]

Le 14/07/2024 à 11:44, Nicolas George a écrit :

Erwan David (12024-07-14):

You are a bit cryptic here : should it be installed or should it be removed

Sorry. For me it was not installed and installing it fixed the problem.


? I am running testing without problem and systemd-cryptsetup is not
installed. If I should install it I'd prefer to do it now rather than having
to go through a rescue system

Do you have encrypted volumes defined in crypttab?

Regards,

I have a "full" disk encryption as made by the installer, thus mounted 
in the initramfs, so it may be a little different

Re: systemd-cryptsetup

[Nicolas George]

Erwan David (12024-07-14):
> You are a bit cryptic here : should it be installed or should it be removed

Sorry. For me it was not installed and installing it fixed the problem.

> ? I am running testing without problem and systemd-cryptsetup is not
> installed. If I should install it I'd prefer to do it now rather than having
> to go through a rescue system

Do you have encrypted volumes defined in crypttab?

Regards,

-- 
  Nicolas George

Re: systemd-cryptsetup

[Erwan David]

Le 14/07/2024 à 11:00, Nicolas George a écrit :

Hi.

In case you are running unstable or testing and it recently started
blocking at boot waiting for encrypted swap or something to do with
encrypted disks:

Check if systemd-cryptsetup is installed.

HtH

You are a bit cryptic here : should it be installed or should it be 
removed ? I am running testing without problem and systemd-cryptsetup is 
not installed. If I should install it I'd prefer to do it now rather 
than having to go through a rescue system