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

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

<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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

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

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,

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

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

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

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

--
Vincent Lef�vre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)