systemd-cryptsetup

[Nicolas George]

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

[Erwan David]

Post by Nicolas George
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
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

[Nicolas George]

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,

[Erwan David]

Post by Nicolas George

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

[Michel Verdier]

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).

[Lists]

Post by Nicolas George
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
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.

<rant-mode on>
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.
</rant-mode off>

Grx HdV

[Nicolas George]

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.

<rant-mode on>
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.
</rant-mode off>

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-tempswap none swap defaults 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.

<rant>
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.
</rant>

Regards,

[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.

Post by Nicolas George

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

[Nicolas George]

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,

[Lists]

Post by Nicolas George
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'

Post by Nicolas George
Anyway, remember that x- means that it is a non-standard option.

I know.

Grx HdV

[Nicolas George]

Post by Lists
That referred to a warning I got after booting up after d-i finished
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,

[Lists]

Post by Nicolas George

Post by Lists
That referred to a warning I got after booting up after d-i finished
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

[Nicolas George]

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,

[Vincent Lefevre]

Post by Lists

Post by Nicolas George
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
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.
<rant-mode on>
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.
</rant-mode off>

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

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