device-mapper: reload ioctl ... failed: No such file or directory

device-mapper: reload ioctl ... failed: No such file or directory

[David J Iannucci]

Hello,

I'm using cryptsetup 2.7.5 on Gentoo to try to open an old TrueCrypt volume that I haven't
looked at in at least a few years. Yes, I have the passphrase :=)  Below is a trace of what's
happening. Without --debug, all I see is the error message:

  device-mapper: reload ioctl on coreswp (254:0) failed: No such file or directory

Any help in figuring this out would be much appreciated.

Dave

------
root# cryptsetup open --debug --type tcrypt /mnt/disk1/core.swp coreswp
# cryptsetup 2.7.5 processing "cryptsetup open --debug --type tcrypt /mnt/disk1/core.swp coreswp"
# Verifying parameters for command open.
# Running command open.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating context for crypt device /mnt/disk1/core.swp.
# Trying to open and read device /mnt/disk1/core.swp with direct-io.
# Direct-io is supported and works.
# Initialising device-mapper backend library.
# Interactive passphrase entry requested.
Enter passphrase for /mnt/disk1/core.swp: 
# Trying to load TCRYPT crypt type from device /mnt/disk1/core.swp.
# Crypto backend (OpenSSL 3.3.2 3 Sep 2024 [default][legacy][threads][argon2]) initialized in cryptsetup library version 2.7.5.
# Detected kernel Linux 5.15.167-gentoo x86_64.
# Reading TCRYPT header of size 512 bytes from device /mnt/disk1/core.swp.
# TCRYPT: trying KDF: pbkdf2-ripemd160-2000.
# TCRYPT:  trying cipher aes-xts-plain64
# TCRYPT: Signature magic detected.
# TCRYPT: Magic: TRUE, Header version: 5, req. 1792, sector 512, mk_offset 131072, hidden_size 0, volume size 107373920256
# TCRYPT: Header cipher aes-xts-plain64, key size 64
# Activating volume coreswp [keyslot -1] using key.
# dm version   [ opencount flush ]   [16384] (*1)
# dm versions   [ opencount flush ]   [16384] (*1)
# Detected dm-ioctl version 4.45.0.
# Detected dm-crypt version 1.23.0.
# Device-mapper backend running with UDEV support enabled.
# dm status coreswp  [ opencount noflush ]   [16384] (*1)
# Allocating a free loop device (block size: 512).
# Trying to open and read device /dev/loop0 with direct-io.
# Direct-io is supported and works.
# Attached loop device block size is 512 bytes.
# Calculated device size is 209714688 sectors (RW), offset 256.
# Trying to activate TCRYPT device coreswp using cipher aes-xts-plain64.
# DM-UUID is CRYPT-TCRYPT-coreswp
# Udev cookie 0xd4dfe53 (semid 65598) created
# Udev cookie 0xd4dfe53 (semid 65598) incremented to 1
# Udev cookie 0xd4dfe53 (semid 65598) incremented to 2
# Udev cookie 0xd4dfe53 (semid 65598) assigned to CREATE task(0) with flags DISABLE_LIBRARY_FALLBACK         (0x20)
# dm create coreswp CRYPT-TCRYPT-coreswp [ opencount flush ]   [16384] (*1)
# dm reload   (254:0) [ opencount flush securedata ]   [16384] (*1)
device-mapper: reload ioctl on coreswp (254:0) failed: No such file or directory
# Udev cookie 0xd4dfe53 (semid 65598) decremented to 1
# Udev cookie 0xd4dfe53 (semid 65598) incremented to 2
# Udev cookie 0xd4dfe53 (semid 65598) assigned to REMOVE task(2) with flags DISABLE_LIBRARY_FALLBACK       (0x20)
# dm remove coreswp  [ opencount flush securedata ]   [16384] (*1)
# Uevent not generated! Calling udev_complete internally to avoid process lock-up.
# Udev cookie 0xd4dfe53 (semid 65598) decremented to 1
# DM create task failed, dm_task errno: 0.
# dm versions   [ opencount flush ]   [16384] (*1)
# dm status coreswp  [ opencount noflush ]   [16384] (*1)
# Device status returned -19.
# Data device /mnt/disk1/core.swp is OK.
# No referenced device missing, some device in use.
# Udev cookie 0xd4dfe53 (semid 65598) decremented to 0
# Udev cookie 0xd4dfe53 (semid 65598) waiting for zero
# Udev cookie 0xd4dfe53 (semid 65598) destroyed
# Releasing crypt device /mnt/disk1/core.swp context.
# Releasing device-mapper backend.
# Closing read only fd for /mnt/disk1/core.swp.
# Closed loop /dev/loop0 (/mnt/disk1/core.swp).
Command failed with code -5 (device already exists or device is busy).

----end----

Re: device-mapper: reload ioctl ... failed: No such file or directory

[Milan Broz]

Hi,

On 10/30/24 5:12 AM, David J Iannucci wrote:
> Hello,
> 
> I'm using cryptsetup 2.7.5 on Gentoo to try to open an old TrueCrypt volume that I haven't
> looked at in at least a few years. Yes, I have the passphrase :=)  Below is a trace of what's
> happening. Without --debug, all I see is the error message:
> 
>    device-mapper: reload ioctl on coreswp (254:0) failed: No such file or directory
> 
> Any help in figuring this out would be much appreciated.

The log shows, that TrueCrypt part works, you have correct password.
The issue is only in the last step - activation through kernel dm-crypt.

I expect that you have device-mapper udev rules properly installed.

Is there anything in syslog? Kernel dm-crypt kernel module, is available?

Where it is mounted? (/mnt path) - some remote nfs/samba?

Could you try to copy the container to local fs and open it from there?
Also, try to open it read-only (-r flag).
(There were some issues with detecting direct-io, this tries to avoid them.)

Thanks,
Milan
...

> # Device-mapper backend running with UDEV support enabled.
> # dm status coreswp  [ opencount noflush ]   [16384] (*1)
> # Allocating a free loop device (block size: 512).
> # Trying to open and read device /dev/loop0 with direct-io.
> # Direct-io is supported and works.
> # Attached loop device block size is 512 bytes.
> # Calculated device size is 209714688 sectors (RW), offset 256.
> # Trying to activate TCRYPT device coreswp using cipher aes-xts-plain64.
> # DM-UUID is CRYPT-TCRYPT-coreswp
> # Udev cookie 0xd4dfe53 (semid 65598) created
> # Udev cookie 0xd4dfe53 (semid 65598) incremented to 1
> # Udev cookie 0xd4dfe53 (semid 65598) incremented to 2
> # Udev cookie 0xd4dfe53 (semid 65598) assigned to CREATE task(0) with flags DISABLE_LIBRARY_FALLBACK         (0x20)
> # dm create coreswp CRYPT-TCRYPT-coreswp [ opencount flush ]   [16384] (*1)
> # dm reload   (254:0) [ opencount flush securedata ]   [16384] (*1)
> device-mapper: reload ioctl on coreswp (254:0) failed: No such file or directory
> # Udev cookie 0xd4dfe53 (semid 65598) decremented to 1
> # Udev cookie 0xd4dfe53 (semid 65598) incremented to 2
> # Udev cookie 0xd4dfe53 (semid 65598) assigned to REMOVE task(2) with flags DISABLE_LIBRARY_FALLBACK       (0x20)
> # dm remove coreswp  [ opencount flush securedata ]   [16384] (*1)
> # Uevent not generated! Calling udev_complete internally to avoid process lock-up.
> # Udev cookie 0xd4dfe53 (semid 65598) decremented to 1
> # DM create task failed, dm_task errno: 0.
> # dm versions   [ opencount flush ]   [16384] (*1)
> # dm status coreswp  [ opencount noflush ]   [16384] (*1)
> # Device status returned -19.
> # Data device /mnt/disk1/core.swp is OK.
> # No referenced device missing, some device in use.
> # Udev cookie 0xd4dfe53 (semid 65598) decremented to 0
> # Udev cookie 0xd4dfe53 (semid 65598) waiting for zero
> # Udev cookie 0xd4dfe53 (semid 65598) destroyed
> # Releasing crypt device /mnt/disk1/core.swp context.
> # Releasing device-mapper backend.
> # Closing read only fd for /mnt/disk1/core.swp.
> # Closed loop /dev/loop0 (/mnt/disk1/core.swp).
> Command failed with code -5 (device already exists or device is busy).
> 
> ----end----
> 

Re: device-mapper: reload ioctl ... failed: No such file or directory

[David J Iannucci]

On Wed, Oct 30, 2024, at 01:10, Milan Broz wrote:
>> I'm using cryptsetup 2.7.5 on Gentoo to try to open an old TrueCrypt
>> volume that I haven't looked at in at least a few years. Yes, I have
>> the passphrase :=)  Below is a trace of what's happening. Without --
>> debug, all I see is the error message:
>> 
>>    device-mapper: reload ioctl on coreswp (254:0) failed: No such file or directory
>> 
>> Any help in figuring this out would be much appreciated.
>
> The log shows, that TrueCrypt part works, you have correct password.
> The issue is only in the last step - activation through kernel dm-crypt.

Thank you for the response. I have tried again after copying the TC file
to local (SSD) disk per your suggestion (I had been accessing it on an
external spinning USB HDD before), and also adding --readonly.
The same error occurs.

It seems I do have dm-crypt:
# lsmod | grep crypt
dm_crypt               49152  0
dm_mod                139264  1 dm_crypt


> I expect that you have device-mapper udev rules properly installed.

I'm not sure - how can I check this? This is a fairly bare-bones Gentoo
install and I'm not a big expert on everything that I should be, so that
might have slipped through the cracks.

But...! I just found something... it seems I am running a systemd-udevd,
which would not have been my choice... I have taken steps to keep
systemd completely off my machine, so this is a surprise. Will consult
Gentoo forums about this.

> Is there anything in syslog?

This is what comes out in /var/log/messages:

Nov  2 16:31:36 linux kernel: loop0: detected capacity change from 0 to 209715200
Nov  2 16:31:36 linux kernel: device-mapper: table: 254:0: crypt: Error allocating crypto tfm
Nov  2 16:31:36 linux kernel: device-mapper: ioctl: error adding target to table


> Where it is mounted? (/mnt path) - some remote nfs/samba?

As mentioned, it was on external drive, but now in my home dir.

Thanks again,
Dave

p.s. I note that simple reply on this list goes only to the sender
     rather than back to the list, which is maybe the way the list
     prefers it? Though in my experience most tech lists like to keep
     this kind of discussion on the list so that more eyes are on
     things, and solutions are documented, but if that's not the case
     here, kindly let me know and I'll use simple reply to individuals
     from now on.


> Could you try to copy the container to local fs and open it from there?
> Also, try to open it read-only (-r flag).
> (There were some issues with detecting direct-io, this tries to avoid them.)
>
> Thanks,
> Milan
> ...
>
>> # Device-mapper backend running with UDEV support enabled.
>> # dm status coreswp  [ opencount noflush ]   [16384] (*1)
>> # Allocating a free loop device (block size: 512).
>> # Trying to open and read device /dev/loop0 with direct-io.
>> # Direct-io is supported and works.
>> # Attached loop device block size is 512 bytes.
>> # Calculated device size is 209714688 sectors (RW), offset 256.
>> # Trying to activate TCRYPT device coreswp using cipher aes-xts-plain64.
>> # DM-UUID is CRYPT-TCRYPT-coreswp
>> # Udev cookie 0xd4dfe53 (semid 65598) created
>> # Udev cookie 0xd4dfe53 (semid 65598) incremented to 1
>> # Udev cookie 0xd4dfe53 (semid 65598) incremented to 2
>> # Udev cookie 0xd4dfe53 (semid 65598) assigned to CREATE task(0) with flags DISABLE_LIBRARY_FALLBACK         (0x20)
>> # dm create coreswp CRYPT-TCRYPT-coreswp [ opencount flush ]   [16384] (*1)
>> # dm reload   (254:0) [ opencount flush securedata ]   [16384] (*1)
>> device-mapper: reload ioctl on coreswp (254:0) failed: No such file or directory
>> # Udev cookie 0xd4dfe53 (semid 65598) decremented to 1
>> # Udev cookie 0xd4dfe53 (semid 65598) incremented to 2
>> # Udev cookie 0xd4dfe53 (semid 65598) assigned to REMOVE task(2) with flags DISABLE_LIBRARY_FALLBACK       (0x20)
>> # dm remove coreswp  [ opencount flush securedata ]   [16384] (*1)
>> # Uevent not generated! Calling udev_complete internally to avoid process lock-up.
>> # Udev cookie 0xd4dfe53 (semid 65598) decremented to 1
>> # DM create task failed, dm_task errno: 0.
>> # dm versions   [ opencount flush ]   [16384] (*1)
>> # dm status coreswp  [ opencount noflush ]   [16384] (*1)
>> # Device status returned -19.
>> # Data device /mnt/disk1/core.swp is OK.
>> # No referenced device missing, some device in use.
>> # Udev cookie 0xd4dfe53 (semid 65598) decremented to 0
>> # Udev cookie 0xd4dfe53 (semid 65598) waiting for zero
>> # Udev cookie 0xd4dfe53 (semid 65598) destroyed
>> # Releasing crypt device /mnt/disk1/core.swp context.
>> # Releasing device-mapper backend.
>> # Closing read only fd for /mnt/disk1/core.swp.
>> # Closed loop /dev/loop0 (/mnt/disk1/core.swp).
>> Command failed with code -5 (device already exists or device is busy).
>> 
>> ----end----
>>

Re: device-mapper: reload ioctl ... failed: No such file or directory

[Milan Broz]

On 11/2/24 11:53 PM, David J Iannucci wrote:
> On Wed, Oct 30, 2024, at 01:10, Milan Broz wrote:
...

>> I expect that you have device-mapper udev rules properly installed.
> 
> I'm not sure - how can I check this? This is a fairly bare-bones Gentoo
> install and I'm not a big expert on everything that I should be, so that
> might have slipped through the cracks.
> 
> But...! I just found something... it seems I am running a systemd-udevd,
> which would not have been my choice... I have taken steps to keep
> systemd completely off my machine, so this is a surprise. Will consult
> Gentoo forums about this.

It is ok, udev is part of systemd project now, but can run without system
(I have it on my testing non-systemd Gentoo too - it is expected.)

>> Is there anything in syslog?
> 
> This is what comes out in /var/log/messages:
> 
> Nov  2 16:31:36 linux kernel: loop0: detected capacity change from 0 to 209715200
> Nov  2 16:31:36 linux kernel: device-mapper: table: 254:0: crypt: Error allocating crypto tfm
> Nov  2 16:31:36 linux kernel: device-mapper: ioctl: error adding target to table

Ok, *this* is the issue. Some kernel module is perhaps missing or misconfigured.

According to log, aes-xts-plain64 should be your image cipher.

Do you have aes, xts (and ecb, which xts internally use) kernel crypto modules compiled
and available?

Does "cryptsetup benchmark --cipher aes-xts" work?

If so, please send me tcryptDump "cryptsetup tcryptDump <your image>".

> p.s. I note that simple reply on this list goes only to the sender
>       rather than back to the list, which is maybe the way the list
>       prefers it? Though in my experience most tech lists like to keep
>       this kind of discussion on the list so that more eyes are on
>       things, and solutions are documented, but if that's not the case
>       here, kindly let me know and I'll use simple reply to individuals
>       from now on.

Yes, please always copy reply to list (unless it contain some private info).
This is default config for maillist server, just use reply to all.

Milan

Re: device-mapper: reload ioctl ... failed: No such file or directory

[David J Iannucci]

On Sat, Nov 2, 2024, at 17:34, Milan Broz wrote:
>> Nov  2 16:31:36 linux kernel: loop0: detected capacity change from 0 to 209715200
>> Nov  2 16:31:36 linux kernel: device-mapper: table: 254:0: crypt: Error allocating crypto tfm
>> Nov  2 16:31:36 linux kernel: device-mapper: ioctl: error adding target to table
>
> Ok, *this* is the issue. Some kernel module is perhaps missing or misconfigured.
>
> According to log, aes-xts-plain64 should be your image cipher.
>
> Do you have aes, xts (and ecb, which xts internally use) kernel crypto
> modules compiled and available?

Apparently I didn't. I added those modules to my kernel, and then I was
able to open the volume, no problem. Thanks much :=)

> Does "cryptsetup benchmark --cipher aes-xts" work?

It does now!

I was putting together a new message here to ask for help with yet
another old TC volume, but I eventually figured out that I had the
wrong passphrase, and found that passphrase, so we're all good :=}
Seems strange to me that if the passphrase doesn't work, that it
doesn't simply tell you that... or maybe there's something about the
decrypting process that means that even cryptsetup can't necessarily
tell the difference between a wrong phrase and some other problem....
Anyway, no worries.

Thanks again,
Dave

Re: device-mapper: reload ioctl ... failed: No such file or directory

[Michael Kjörling]

On 2 Nov 2024 16:53 -0600, from pelcgfrghczy@punchcutter.ml1.net (David J Iannucci):
>> I expect that you have device-mapper udev rules properly installed.
> 
> I'm not sure - how can I check this? This is a fairly bare-bones Gentoo
> install and I'm not a big expert on everything that I should be, so that
> might have slipped through the cracks.
> 
> But...! I just found something... it seems I am running a systemd-udevd,
> which would not have been my choice... I have taken steps to keep
> systemd completely off my machine, so this is a surprise. Will consult
> Gentoo forums about this.
> 
>> Is there anything in syslog?
> 
> This is what comes out in /var/log/messages:
> 
> Nov  2 16:31:36 linux kernel: loop0: detected capacity change from 0 to 209715200
> Nov  2 16:31:36 linux kernel: device-mapper: table: 254:0: crypt: Error allocating crypto tfm
> Nov  2 16:31:36 linux kernel: device-mapper: ioctl: error adding target to table

Just to rule out the possibility of this being caused by something
about your kernel build settings etc., would you be willing to try
booting a binary, general-purpose distribution like a recent Debian or
Fedora and unlocking the volume from within there, and let us know how
that goes?

The error that shows up in your logs certainly matches Milan Broz's
conclusion earlier: that the problem is during the actual mapping
setup, which happens after passphrase validation.


> p.s. I note that simple reply on this list goes only to the sender
>      rather than back to the list, which is maybe the way the list
>      prefers it? Though in my experience most tech lists like to keep
>      this kind of discussion on the list so that more eyes are on
>      things, and solutions are documented, but if that's not the case
>      here, kindly let me know and I'll use simple reply to individuals
>      from now on.

Overriding the preferences of the original sender as well as making
life more difficult for the person replying is generally not a good
idea. "Reply-To munging considered harmful" was an argument made,
what, two decades ago, or more? Use the "group reply" / "reply to all"
or list reply feature provided by your mail client if you want your
reply to go to the list; use the sender reply function if you want
your reply to go only to the sender of the message you're replying to.

-- 
Michael Kjörling
🔗 https://michael.kjorling.se