Bug#1072058: [pkg-cryptsetup-devel] Bug#1072058: Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE

[Luca Boccassi]

On Mon, 3 Jun 2024 at 00:22, Guilhem Moulin  wrote:
>
> On Mon, 03 Jun 2024 at 00:14:39 +0100, Luca Boccassi wrote:
> > On Mon, 3 Jun 2024 at 00:09, Guilhem Moulin  wrote:
> >> On Sun, 02 Jun 2024 at 23:35:57 +0100, Luca Boccassi wrote:
> >>> I gather the initramfs scripts are not calling a deferred close after
> >>> mounting the rootfs in the initrd. If you add that, the device should
> >>> be automatically cleaned up when the root filesystem is umounted.
> >>
> >> initramfs-tools doesn't take the system back on shutdown, so there is
> >> nothing src:cryptsetup can do here.
> >
> > The deferred close is given on the initrd though, immediately after
> > mounting, which I think is done by the cryptsetup initramfs hook?
> > Deferred close means that it will be closed by the kernel once the
> > last mount is gone. So if you call that from the initramfs hook,
> > things should work out automatically on shutdown.
>
> I see, thanks for the explanation.  The cryptsetup initramfs scripts are
> currently only involved at pre-mount stage and do not try to mount
> anything, but we could add another one at post-mount stage for this.

Yeah that should work, thanks.

Bug#1072058: [pkg-cryptsetup-devel] Bug#1072058: Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE

[Guilhem Moulin]

On Mon, 03 Jun 2024 at 00:14:39 +0100, Luca Boccassi wrote:
> On Mon, 3 Jun 2024 at 00:09, Guilhem Moulin  wrote:
>> On Sun, 02 Jun 2024 at 23:35:57 +0100, Luca Boccassi wrote:
>>> I gather the initramfs scripts are not calling a deferred close after
>>> mounting the rootfs in the initrd. If you add that, the device should
>>> be automatically cleaned up when the root filesystem is umounted.
>>
>> initramfs-tools doesn't take the system back on shutdown, so there is
>> nothing src:cryptsetup can do here.
> 
> The deferred close is given on the initrd though, immediately after
> mounting, which I think is done by the cryptsetup initramfs hook?
> Deferred close means that it will be closed by the kernel once the
> last mount is gone. So if you call that from the initramfs hook,
> things should work out automatically on shutdown.

I see, thanks for the explanation.  The cryptsetup initramfs scripts are
currently only involved at pre-mount stage and do not try to mount
anything, but we could add another one at post-mount stage for this.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1072058: [pkg-cryptsetup-devel] Bug#1072058: Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE

[Luca Boccassi]

On Mon, 3 Jun 2024 at 00:09, Guilhem Moulin  wrote:
>
> On Sun, 02 Jun 2024 at 23:35:57 +0100, Luca Boccassi wrote:
> > Yes, the purpose of the option is to leave that device alone, as it
> > cannot be closed from the host os, as programs will be running from
> > it.
>
> It doesn't leave the device alone though as it still tries to detach it.

Yes it will do some attempts in the shutdown binary, the purpose of
the option is to leave it alone in the transition before (when the
service is stopped)

> > I gather the initramfs scripts are not calling a deferred close after
> > mounting the rootfs in the initrd. If you add that, the device should
> > be automatically cleaned up when the root filesystem is umounted.
>
> initramfs-tools doesn't take the system back on shutdown, so there is
> nothing src:cryptsetup can do here.

The deferred close is given on the initrd though, immediately after
mounting, which I think is done by the cryptsetup initramfs hook?
Deferred close means that it will be closed by the kernel once the
last mount is gone. So if you call that from the initramfs hook,
things should work out automatically on shutdown.

Bug#1072058: [pkg-cryptsetup-devel] Bug#1072058: Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE

[Guilhem Moulin]

On Sun, 02 Jun 2024 at 23:35:57 +0100, Luca Boccassi wrote:
> Yes, the purpose of the option is to leave that device alone, as it
> cannot be closed from the host os, as programs will be running from
> it.

It doesn't leave the device alone though as it still tries to detach it.

> I gather the initramfs scripts are not calling a deferred close after
> mounting the rootfs in the initrd. If you add that, the device should
> be automatically cleaned up when the root filesystem is umounted.

initramfs-tools doesn't take the system back on shutdown, so there is
nothing src:cryptsetup can do here.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1072058: [pkg-cryptsetup-devel] Bug#1072058: Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE

[Luca Boccassi]

On Sun, 2 Jun 2024 at 23:22, Guilhem Moulin  wrote:
>
> Control: tag -1 = pending
>
> Hi,
>
> On Mon, 27 May 2024 at 23:32:13 +0100, Luca Boccassi wrote:
> > Please consider applying the same change in the initramfs-tools
> > cryptsetup scripts, so that x-initrd.attach is recognized (and no
> > warning is printed), and so that it is added if missing. Thanks.
>
> While testing this it seems adding x-initrd.attach to vda5_crypt causes
> systemd not to try to stop systemd-cryptsetup@vda5_crypt.service on
> shutdown, on this system it still tries and fail to remove the DM device
> holding the root file system (vda5_crypt):
>
>  73s [6.834893] systemd-shutdown[1]: Syncing filesystems and 
> block devices.
>  73s [6.837554] systemd-shutdown[1]: Sending SIGTERM to remaining 
> processes...
>  73s [6.845806] systemd-journald[354]: Received SIGTERM from PID 
> 1 (systemd-shutdow).
>  73s [6.884585] systemd-shutdown[1]: Sending SIGKILL to remaining 
> processes...
>  73s [6.889688] systemd-shutdown[1]: Unmounting file systems.
>  73s [6.890874] (sd-umount)[737]: Unmounting 
> '/run/credentials/systemd-cryptsetup@vda5_crypt.service'.
>  73s [6.893159] (sd-umount)[738]: Unmounting 
> '/run/credentials/systemd-journald.service'.
>  73s [6.894974] (sd-remount)[739]: Remounting '/' read-only with 
> options 'errors=remount-ro'.
>  73s [6.925739] EXT4-fs (dm-0): re-mounted 
> 8effcc46-252e-4197-8f24-79f91fc7d8ad ro. Quota mode: none.
>  73s [6.927993] systemd-shutdown[1]: All filesystems unmounted.
>  73s [6.928747] systemd-shutdown[1]: Deactivating swaps.
>  73s [6.929334] systemd-shutdown[1]: All swaps deactivated.
>  73s [6.929880] systemd-shutdown[1]: Detaching loop devices.
>  73s [6.933262] systemd-shutdown[1]: All loop devices detached.
>  73s [6.934343] systemd-shutdown[1]: Stopping MD devices.
>  73s [6.935470] systemd-shutdown[1]: All MD devices stopped.
>  73s [6.936602] systemd-shutdown[1]: Detaching DM devices.
>  73s [6.938329] systemd-shutdown[1]: Not all DM devices detached, 
> 1 left.
>  73s [6.939932] systemd-shutdown[1]: Detaching DM devices.
>  73s [6.941675] systemd-shutdown[1]: Not all DM devices detached, 
> 1 left.
>  73s [6.943213] systemd-shutdown[1]: Detaching DM devices.
>  73s [6.944951] systemd-shutdown[1]: Not all DM devices detached, 
> 1 left.
>  73s [6.946351] systemd-shutdown[1]: Cannot finalize remaining DM 
> devices, continuing.
>  73s [6.948555] systemd-shutdown[1]: Unable to finalize remaining 
> DM devices, ignoring.
>  73s [6.950748] systemd-shutdown[1]: Syncing filesystems and 
> block devices.
>  73s [6.952441] systemd-shutdown[1]: Powering off.
>
> Is that expected?

Yes, the purpose of the option is to leave that device alone, as it
cannot be closed from the host os, as programs will be running from
it.

I gather the initramfs scripts are not calling a deferred close after
mounting the rootfs in the initrd. If you add that, the device should
be automatically cleaned up when the root filesystem is umounted.

Bug#1072058: [pkg-cryptsetup-devel] Bug#1072058: Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE

[Guilhem Moulin]

Control: tag -1 = pending

Hi,

On Mon, 27 May 2024 at 23:32:13 +0100, Luca Boccassi wrote:
> Please consider applying the same change in the initramfs-tools
> cryptsetup scripts, so that x-initrd.attach is recognized (and no
> warning is printed), and so that it is added if missing. Thanks.

While testing this it seems adding x-initrd.attach to vda5_crypt causes
systemd not to try to stop systemd-cryptsetup@vda5_crypt.service on
shutdown, on this system it still tries and fail to remove the DM device
holding the root file system (vda5_crypt):

 73s [6.834893] systemd-shutdown[1]: Syncing filesystems and block 
devices.
 73s [6.837554] systemd-shutdown[1]: Sending SIGTERM to remaining 
processes...
 73s [6.845806] systemd-journald[354]: Received SIGTERM from PID 1 
(systemd-shutdow).
 73s [6.884585] systemd-shutdown[1]: Sending SIGKILL to remaining 
processes...
 73s [6.889688] systemd-shutdown[1]: Unmounting file systems.
 73s [6.890874] (sd-umount)[737]: Unmounting 
'/run/credentials/systemd-cryptsetup@vda5_crypt.service'.
 73s [6.893159] (sd-umount)[738]: Unmounting 
'/run/credentials/systemd-journald.service'.
 73s [6.894974] (sd-remount)[739]: Remounting '/' read-only with 
options 'errors=remount-ro'.
 73s [6.925739] EXT4-fs (dm-0): re-mounted 
8effcc46-252e-4197-8f24-79f91fc7d8ad ro. Quota mode: none.
 73s [6.927993] systemd-shutdown[1]: All filesystems unmounted.
 73s [6.928747] systemd-shutdown[1]: Deactivating swaps.
 73s [6.929334] systemd-shutdown[1]: All swaps deactivated.
 73s [6.929880] systemd-shutdown[1]: Detaching loop devices.
 73s [6.933262] systemd-shutdown[1]: All loop devices detached.
 73s [6.934343] systemd-shutdown[1]: Stopping MD devices.
 73s [6.935470] systemd-shutdown[1]: All MD devices stopped.
 73s [6.936602] systemd-shutdown[1]: Detaching DM devices.
 73s [6.938329] systemd-shutdown[1]: Not all DM devices detached, 1 
left.
 73s [6.939932] systemd-shutdown[1]: Detaching DM devices.
 73s [6.941675] systemd-shutdown[1]: Not all DM devices detached, 1 
left.
 73s [6.943213] systemd-shutdown[1]: Detaching DM devices.
 73s [6.944951] systemd-shutdown[1]: Not all DM devices detached, 1 
left.
 73s [6.946351] systemd-shutdown[1]: Cannot finalize remaining DM 
devices, continuing.
 73s [6.948555] systemd-shutdown[1]: Unable to finalize remaining 
DM devices, ignoring.
 73s [6.950748] systemd-shutdown[1]: Syncing filesystems and block 
devices.
 73s [6.952441] systemd-shutdown[1]: Powering off.

Is that expected?

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE

[Luca Boccassi]

On Sun, 2 Jun 2024 at 20:04, Cyril Brulebois  wrote:
>
> Luca Boccassi  (2024-05-27):
> > I'll upload a D-I fix that adds x-initrd.attach to crypttab by default
> > shortly. Yes you can ignore the "unknown option" message, as the
> > Debian-specific initramfs-tools scripts do not know about it, but
> > that's fine, it's for the shutdown path anyway. And the finalize
> > messages can also be ignored.
>
> Having a cryptsetup warning about an unknown option on the very first
> line seen by users after the bootloader step doesn't feel appropriate
> at all to me. Telling users to just ignore it neither.
>
> For the record, on a fresh install, that means:
>
> cryptsetup: WARNING: sda5_crypt: ignoring unknown option 'x-initrd.attach'
> Please unlock disk sda5_crypt: _
>
> Looping in the cryptsetup team.

See #1072058

Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE

[Cyril Brulebois]

Luca Boccassi  (2024-05-27):
> I'll upload a D-I fix that adds x-initrd.attach to crypttab by default
> shortly. Yes you can ignore the "unknown option" message, as the
> Debian-specific initramfs-tools scripts do not know about it, but
> that's fine, it's for the shutdown path anyway. And the finalize
> messages can also be ignored.

Having a cryptsetup warning about an unknown option on the very first
line seen by users after the bootloader step doesn't feel appropriate
at all to me. Telling users to just ignore it neither.

For the record, on a fresh install, that means:

cryptsetup: WARNING: sda5_crypt: ignoring unknown option 'x-initrd.attach'
Please unlock disk sda5_crypt: _

Looping in the cryptsetup team.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1072058: Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE

[Luca Boccassi]

On Mon, 27 May 2024 22:44:21 +0100 Luca Boccassi 
wrote:
> On Fri, 30 Sep 2022 23:34:46 -0300 ng  wrote:
> > Now, I think is worth mentioning that:
> > 
> > Adding 'x-initrd.attach' to the device holding root at
> /etc/crypttab,  
> > does in fact solve systemd-cryptsetup@vda5_crypt.service failing.  
> But, 
> > on reboots and shutdowns I still get 'Failed to finalize DM
devices, 
> > ignoring'.    I wonder if it can be ignored. Using dracut doesn't
> change 
> > this behavior.
> > 
> > And on my other machine,  I get at boot: "cryptsetup: WARNING: 
> > vda5_crypt: ignoring unknown option 'x-initrd.attach.".  Even
though
> the 
> > option does work as expected,  this I suppose because I'm using 
> > initramfs-tools/busybox this time?    I still haven't tried with
> dracut 
> > since the warning seems a false positive.
> 
> I'll upload a D-I fix that adds x-initrd.attach to crypttab by
default
> shortly. Yes you can ignore the "unknown option" message, as the
> Debian-specific initramfs-tools scripts do not know about it, but
> that's fine, it's for the shutdown path anyway. And the finalize
> messages can also be ignored.

Hi cryptsetup maintainers,

Please consider applying the same change in the initramfs-tools
cryptsetup scripts, so that x-initrd.attach is recognized (and no
warning is printed), and so that it is added if missing. Thanks.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE

[Luca Boccassi]

On Fri, 30 Sep 2022 23:34:46 -0300 ng  wrote:
> Now, I think is worth mentioning that:
> 
> Adding 'x-initrd.attach' to the device holding root at
/etc/crypttab,  
> does in fact solve systemd-cryptsetup@vda5_crypt.service failing.  
But, 
> on reboots and shutdowns I still get 'Failed to finalize DM devices, 
> ignoring'.    I wonder if it can be ignored. Using dracut doesn't
change 
> this behavior.
> 
> And on my other machine,  I get at boot: "cryptsetup: WARNING: 
> vda5_crypt: ignoring unknown option 'x-initrd.attach.".  Even though
the 
> option does work as expected,  this I suppose because I'm using 
> initramfs-tools/busybox this time?    I still haven't tried with
dracut 
> since the warning seems a false positive.

I'll upload a D-I fix that adds x-initrd.attach to crypttab by default
shortly. Yes you can ignore the "unknown option" message, as the
Debian-specific initramfs-tools scripts do not know about it, but
that's fine, it's for the shutdown path anyway. And the finalize
messages can also be ignored.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1017542: Systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE

[ng]

Hello,

Just wanted to report that this bug is somewhat still in debian testing, 
this happens every time I shutdown this virtual machine


>systemd-shutdown[1]: Failed to finalize DM devices, ignoring.


linux 6.1.0-7-amd64
systemd 252.6-1
cryptsetup 2:2.6.1-3

partitons:

/boot ext4
/ luks2+ext4
/home luks2+ext4

efi enabled secure boot enabled.

Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE

[ng]

This was reported 4 years ago btw. 
https://github.com/systemd/systemd/issues/8472


El 30/9/22 a las 23:34, ng escribió:

Now, I think is worth mentioning that:

Adding 'x-initrd.attach' to the device holding root at /etc/crypttab,  
does in fact solve systemd-cryptsetup@vda5_crypt.service failing.   
But, on reboots and shutdowns I still get 'Failed to finalize DM 
devices, ignoring'.    I wonder if it can be ignored. Using dracut 
doesn't change this behavior.


And on my other machine,  I get at boot: "cryptsetup: WARNING: 
vda5_crypt: ignoring unknown option 'x-initrd.attach.".  Even though 
the option does work as expected,  this I suppose because I'm using 
initramfs-tools/busybox this time?    I still haven't tried with 
dracut since the warning seems a false positive.



El 28/9/22 a las 17:38, ng escribió:
Well, I added that to my crypttab, and everything is fine again on my 
side :)


what happens next is up to you,  thank you for your help

El 26/9/22 a las 13:16, Michael Biebl escribió:


Am 20.09.22 um 06:47 schrieb ng:

https://github.com/systemd/systemd/issues/24758

Done,  I hope I did it right.



Thanks for forwarding this issue upstream.

It turns out, that adding "x-initrd.attach" to /etc/crypttab for the 
device holding the root fs does fix the issue.


This is nicely documented in systemd's man crypttab. Unfortunately 
we don't install this man page atm due to [1] which appears to go 
nowhere.


I guess we should do two things:
a/ dpkg-divert the cryptsetup provided man page and install the man 
page which we currently remove [2]


b/ clone this bug report and reassign it to d-i/partman so the 
debian installer adds the x-initrd.attach option when creating the 
luks+lvm setup.


Thoughts?

Michael

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981405
[2] 
https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/rules#L219

Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE

[ng]

Now, I think is worth mentioning that:

Adding 'x-initrd.attach' to the device holding root at /etc/crypttab,  
does in fact solve systemd-cryptsetup@vda5_crypt.service failing.   But, 
on reboots and shutdowns I still get 'Failed to finalize DM devices, 
ignoring'.    I wonder if it can be ignored. Using dracut doesn't change 
this behavior.


And on my other machine,  I get at boot: "cryptsetup: WARNING: 
vda5_crypt: ignoring unknown option 'x-initrd.attach.".  Even though the 
option does work as expected,  this I suppose because I'm using 
initramfs-tools/busybox this time?    I still haven't tried with dracut 
since the warning seems a false positive.



El 28/9/22 a las 17:38, ng escribió:
Well, I added that to my crypttab, and everything is fine again on my 
side :)


what happens next is up to you,  thank you for your help

El 26/9/22 a las 13:16, Michael Biebl escribió:


Am 20.09.22 um 06:47 schrieb ng:

https://github.com/systemd/systemd/issues/24758

Done,  I hope I did it right.



Thanks for forwarding this issue upstream.

It turns out, that adding "x-initrd.attach" to /etc/crypttab for the 
device holding the root fs does fix the issue.


This is nicely documented in systemd's man crypttab. Unfortunately we 
don't install this man page atm due to [1] which appears to go nowhere.


I guess we should do two things:
a/ dpkg-divert the cryptsetup provided man page and install the man 
page which we currently remove [2]


b/ clone this bug report and reassign it to d-i/partman so the debian 
installer adds the x-initrd.attach option when creating the luks+lvm 
setup.


Thoughts?

Michael

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981405
[2] 
https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/rules#L219

Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE

[ng]

Well, I added that to my crypttab, and everything is fine again on my 
side :)


what happens next is up to you,  thank you for your help

El 26/9/22 a las 13:16, Michael Biebl escribió:


Am 20.09.22 um 06:47 schrieb ng:

https://github.com/systemd/systemd/issues/24758

Done,  I hope I did it right.



Thanks for forwarding this issue upstream.

It turns out, that adding "x-initrd.attach" to /etc/crypttab for the 
device holding the root fs does fix the issue.


This is nicely documented in systemd's man crypttab. Unfortunately we 
don't install this man page atm due to [1] which appears to go nowhere.


I guess we should do two things:
a/ dpkg-divert the cryptsetup provided man page and install the man 
page which we currently remove [2]


b/ clone this bug report and reassign it to d-i/partman so the debian 
installer adds the x-initrd.attach option when creating the luks+lvm 
setup.


Thoughts?

Michael

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981405
[2] 
https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/rules#L219

Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE

[Michael Biebl]

Am 20.09.22 um 06:47 schrieb ng:

https://github.com/systemd/systemd/issues/24758

Done,  I hope I did it right.



Thanks for forwarding this issue upstream.

It turns out, that adding "x-initrd.attach" to /etc/crypttab for the 
device holding the root fs does fix the issue.


This is nicely documented in systemd's man crypttab. Unfortunately we 
don't install this man page atm due to [1] which appears to go nowhere.


I guess we should do two things:
a/ dpkg-divert the cryptsetup provided man page and install the man page 
which we currently remove [2]


b/ clone this bug report and reassign it to d-i/partman so the debian 
installer adds the x-initrd.attach option when creating the luks+lvm setup.


Thoughts?

Michael

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981405
[2] 
https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/rules#L219


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE

[ng]

https://github.com/systemd/systemd/issues/24758

Done,  I hope I did it right.

Have a nice day.

El 12/9/22 a las 05:19, Michael Biebl escribió:
In this case, can you please try with the latest systemd version v251 
and if the problem persists, raise it at

https://github.com/systemd/systemd/issues

Regards,
Michael

Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE

[Michael Biebl]

In this case, can you please try with the latest systemd version v251 
and if the problem persists, raise it at

https://github.com/systemd/systemd/issues

Regards,
Michael
On Mon, 29 Aug 2022 02:29:30 -0300 ng  wrote:
I installed dracut,  and ran 'sudo dracut -f' more than twice, with 
reboots,  but it didn't fixed the issue.  It remains the same.


(I sent this mail over 2 weeks ago to your personal email by mistake, 
I'm sorry).



El 17/8/22 a las 16:24, Michael Biebl escribió:
> Can you try dracut as your initramfs generator?
> It supports
> http://systemd.io/INITRD_INTERFACE/
>
> Specifically this part should be relevant to you:
>
> "
> If the executable /run/initramfs/shutdown exists systemd will use it 
> to jump back into the initrd on shutdown. /run/initramfs/ should be a 
> usable initrd environment to which systemd will pivot back and the 
> shutdown executable in it should be able to detach all complex storage 
> that for example was needed to mount the root file system.

> "




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE

[ng]

I installed dracut,  and ran 'sudo dracut -f' more than twice, with 
reboots,  but it didn't fixed the issue.  It remains the same.


(I sent this mail over 2 weeks ago to your personal email by mistake, 
I'm sorry).



El 17/8/22 a las 16:24, Michael Biebl escribió:

Can you try dracut as your initramfs generator?
It supports
http://systemd.io/INITRD_INTERFACE/

Specifically this part should be relevant to you:

"
If the executable /run/initramfs/shutdown exists systemd will use it 
to jump back into the initrd on shutdown. /run/initramfs/ should be a 
usable initrd environment to which systemd will pivot back and the 
shutdown executable in it should be able to detach all complex storage 
that for example was needed to mount the root file system.

"

Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE

[Michael Biebl]

Am 17.08.22 um 19:18 schrieb Nelson G:

Package: systemd
Version: 247.3-7
Severity: normal

Dear Maintainer,

After installing debian 11 with luks2 encryption I noticed the restarting and
powering off processes took a few seconds more than the average compared to my
other debian systems without encrypted partitions,  I noticed that in the last
moment, my screen would print the following:

Detaching DM devices
Not all DM devices detached, 1 left.
Detaching DM devices
Not all DM devices detached, 1 left.
Cannot finalize remaining DM devices, continuing.
Failed to finalize DM devices, ignoring.

then I found this on my journalctl

ago 17 13:48:49 vm systemd-cryptsetup[764]: Device vda5_crypt is still in use.
ago 17 13:48:49 vm systemd-cryptsetup[764]: Failed to deactivate: Device or
resource busy
ago 17 13:48:49 vm systemd[1]: systemd-cryptsetup@vda5_crypt.service: Control
process exited, code=exited, status=1/FAILURE
ago 17 13:48:49 vm systemd[1]: systemd-cryptsetup@vda5_crypt.service: Failed
with result 'exit-code'.




Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.140


Can you try dracut as your initramfs generator?
It supports
http://systemd.io/INITRD_INTERFACE/

Specifically this part should be relevant to you:

"
If the executable /run/initramfs/shutdown exists systemd will use it to 
jump back into the initrd on shutdown. /run/initramfs/ should be a 
usable initrd environment to which systemd will pivot back and the 
shutdown executable in it should be able to detach all complex storage 
that for example was needed to mount the root file system.

"



OpenPGP_signature
Description: OpenPGP digital signature