* device-mapper: reload ioctl ... failed: No such file or directory [not found] <1730260948-20104-mlmmj-67cc752c@lists.linux.dev> @ 2024-10-30 4:12 ` David J Iannucci 2024-10-30 7:10 ` Milan Broz 0 siblings, 1 reply; 6+ messages in thread From: David J Iannucci @ 2024-10-30 4:12 UTC (permalink / raw) To: cryptsetup 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---- ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: device-mapper: reload ioctl ... failed: No such file or directory 2024-10-30 4:12 ` device-mapper: reload ioctl ... failed: No such file or directory David J Iannucci @ 2024-10-30 7:10 ` Milan Broz 2024-11-02 22:53 ` David J Iannucci 0 siblings, 1 reply; 6+ messages in thread From: Milan Broz @ 2024-10-30 7:10 UTC (permalink / raw) To: David J Iannucci, cryptsetup 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---- > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: device-mapper: reload ioctl ... failed: No such file or directory 2024-10-30 7:10 ` Milan Broz @ 2024-11-02 22:53 ` David J Iannucci 2024-11-02 23:34 ` Milan Broz 2024-11-02 23:36 ` Michael Kjörling 0 siblings, 2 replies; 6+ messages in thread From: David J Iannucci @ 2024-11-02 22:53 UTC (permalink / raw) To: cryptsetup; +Cc: Milan Broz 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---- >> ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: device-mapper: reload ioctl ... failed: No such file or directory 2024-11-02 22:53 ` David J Iannucci @ 2024-11-02 23:34 ` Milan Broz 2024-11-09 23:31 ` David J Iannucci 2024-11-02 23:36 ` Michael Kjörling 1 sibling, 1 reply; 6+ messages in thread From: Milan Broz @ 2024-11-02 23:34 UTC (permalink / raw) To: David J Iannucci, cryptsetup 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: device-mapper: reload ioctl ... failed: No such file or directory 2024-11-02 23:34 ` Milan Broz @ 2024-11-09 23:31 ` David J Iannucci 0 siblings, 0 replies; 6+ messages in thread From: David J Iannucci @ 2024-11-09 23:31 UTC (permalink / raw) To: cryptsetup 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: device-mapper: reload ioctl ... failed: No such file or directory 2024-11-02 22:53 ` David J Iannucci 2024-11-02 23:34 ` Milan Broz @ 2024-11-02 23:36 ` Michael Kjörling 1 sibling, 0 replies; 6+ messages in thread From: Michael Kjörling @ 2024-11-02 23:36 UTC (permalink / raw) To: cryptsetup 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-11-09 23:33 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1730260948-20104-mlmmj-67cc752c@lists.linux.dev>
2024-10-30 4:12 ` device-mapper: reload ioctl ... failed: No such file or directory David J Iannucci
2024-10-30 7:10 ` Milan Broz
2024-11-02 22:53 ` David J Iannucci
2024-11-02 23:34 ` Milan Broz
2024-11-09 23:31 ` David J Iannucci
2024-11-02 23:36 ` Michael Kjörling
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox