| View previous topic :: View next topic |
| Author |
Message |
genzolan
n00b
Joined: 14 May 2024
Posts: 5
|
 Posted: Tue May 14, 2024 9:40 pm Post subject: cryptsetup luksOpen can't create device [RESOLVED] |
 |
|
New system. Kernel: 6.6.21-gentoo
Mostly default desktop/OpenRC settings.
cryptographic API settings look fine.
cryptsetup 2.6.1 was rebuilt after booting under this kernel.
| Code: | | cryptsetup --debug luksOpen /dev/sda5 z1 |
initial steps look fine, then
| Code: | # dm create z1 CRYPT-LUKS1-bab50bd97c244463a47e6e5b95a9513c-z1 [ opencount flush ] [16384] (*1)
# dm reload (253:0) [ opencount flush securedata ] [16384] (*1)
device-mapper: reload ioctl on z1 (253:0) failed: No such file or directory |
cleanup includes
| Code: | # dm remove z1 [ opencount flush securedata ] [16384] (*1)
# Uevent not generated! Calling udev_complete internally to avoid process lock-up. |
cleanup concludes
| Code: | | Command failed with code -4 (wrong device or file specified). |
It looks like z1 is not created at all, but I don't see why.
What should I check for clues?
-- edit --
I successfully created a luksFormat test file, but luksOpen failed the same way.
-- edit --
I can `mknod /dev/dm-0 b 253 0` and `ln -s /dev/dm-0 /dev/mapper/z1` as root. (Confirming things can be created)
Debug output for luksOpen is exactly the same with pre-created link and device, not even complaining that they already exist.
-- edit --
Comparing debug outputs vs (very old) working cryptsetup 2.1.0 under kernel 4.14.83. (Same machine)- The old system could not use userspace crypto wrapper, and the new one does.
But both continue after this (with different wording), and I'm not sure it's relevant for this step.
- They also use different flags, which may just be system differences:
| Code: | #old system
# Udev cookie 0xd4d9e10 (semid 0) assigned to CREATE task(0) with flags DISABLE_SUBSYSTEM_RULES DISABLE_DISK_RULES DISABLE_OTHER_RULES DISABLE_LIBRARY_FALLBACK (0x2e)
#new system
# Udev cookie 0xd4d55f1 (semid 0) assigned to CREATE task(0) with flags DISABLE_LIBRARY_FALLBACK (0x20)
|
Last edited by genzolan on Fri May 24, 2024 5:50 am; edited 1 time in total |
|
| Back to top |
|
 |
genzolan
n00b
Joined: 14 May 2024
Posts: 5
|
| Posted: Tue May 21, 2024 6:59 am Post subject: |
|
|
I have been improving the original post with any tests I could think of over the past week, and ask that people give it another look in case it makes a difference.
I have not found or thought of any more actions to get more clues. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21794
|
| Posted: Tue May 21, 2024 2:14 pm Post subject: |
|
|
| Please luksFormat a test file, verify it fails top luksOpen, then provide us with the luksDump of that test file. Check that the version, cipher, and hash shown there are supported by your chosen kernel configuration. If in doubt, pastebin the kernel configuration, so that we can review it. |
|
| Back to top |
|
|
genzolan
n00b
Joined: 14 May 2024
Posts: 5
|
| Posted: Thu May 23, 2024 6:17 am Post subject: |
|
|
Test file luksFormatted successfully and failed luksOpen.
luksDump output here (seemed rude to post directly)
Summary:
| Code: | luksDump kernel .config
version 2
cipher aes-xts-plain64 CONFIG_CRYPTO_AES=y (Rijndael)
hash sha256 CONFIG_CRYPTO_SHA256=y |
I think I have understood well enough not to bother you with kernel config, but am happy to do so if there's some value in it I missed.
One detail I noticed is the luksDump Cipher key is 512bit, whereas kernel config help for AES lists only 128,192,256.
But I can't see how Format would create what it can't Open. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21794
|
| Posted: Thu May 23, 2024 3:11 pm Post subject: |
|
|
Format can create what it cannot open, because open requires that the kernel support the parameters you want to use, but format can write parameters without the kernel's help.
You did not show your kernel configuration, so I cannot check this, but I notice that the kernel has a configuration option CONFIG_CRYPTO_XTS, which seems relevant since your format is aes-xts-plain64. Do you have XTS enabled in your kernel? |
|
| Back to top |
|
|
genzolan
n00b
Joined: 14 May 2024
Posts: 5
|
| Posted: Fri May 24, 2024 5:49 am Post subject: |
|
|
CONFIG_CRYPTO_XTS was not set. I have set it and everything now works without complaint. Thank you.
In fact, XTS help explicitly names 'aes-xts-plain' and the needed key sizes.
The take-away for me is to just text-search every term instead of assuming I know what is significant.
XTS was in a sub-category I didn't even think was relevant to me, and never even looked at. |
|
| Back to top |
|
|
|
Kernel & Hardware
