0

I've got a system with LUKS partitions. I'd like to convert them to LUKS2 to see if I can simplify my setup using partition labels.

When I run cryptsetup convert <partitionNode> --type LUKS2 it seems to work correctly

# cryptsetup convert <partitionNode> --type luks2 WARNING! ======== This operation will convert <partitionNode> to LUKS2 format. Are you sure? (Type uppercase yes): YES

But then when I attempt to unlock the volume it breaks:

# /usr/local/bin/unlock_password.sh | cryptsetup -v luksOpen <partitionNode> PartB Command failed with code -1 (wrong or missing parameters).

Converting back to LUKS 1 fixes it

# cryptsetup convert <partitionNode> --type luks1 WARNING! ======== This operation will convert <partitionNode> to LUKS1 format. Are you sure? (Type uppercase yes): YES # /usr/local/bin/unlock_password.sh | cryptsetup -v luksOpen <partitionNode> PartB Key slot 0 unlocked. Command successful.

Does anyone know why this could happen? It looks like the conversion didn't run correctly on the keyslot, or maybe the input handler is different for LUKS2 and it can't accept my (large, base64) password.

My old version of cryptsetup is 2.0.4 if that matches up with known bugs.

PS. I have also added a second key-slot with a new random key file. It also stops working when I convert to LUKS2 so it looks like, with my current environment, I cannot convert to LUKS2.

Improve this question
7
  • 1
    Did you try to unlock manually also? Is there the same error message? Also you could have a look at the output of cryptsetup luksDump before and after conversion... Commented Nov 5, 2024 at 21:53
  • @U.Windl this is pretty manual already (the password is not human readable so i can't really type it), but yes, I tried to copy and paste the password into the prompt in the terminal. Notably cryptsetup was using /dev/tty to directly print to the terminal and capture I/O so I couldn't see what I was pasting. That might have had an effect but I think it did the same thing for both formats. I luksDumped it both ways and there weren't any complaints about errors. The format and structure was obviously different but that was about it. Commented Nov 5, 2024 at 21:58
  • You could also add a second key slot for the time of transition. Using the second slot you could re-create the first slot in LUKS2 and the see whether it works then. If so you could remove the additional slot again. Commented Nov 5, 2024 at 22:04
  • @U.Windl Luks 2 adds a "Digest" and has different fields for the keyslot. The fields that exist in both ( Salt, iterations, AF stripes) are the same. Fields that went from global to per-slot ( Ciper/Mode, hash, KDF) seem to be the same. Ther'es a new area offset that worries me a little because 32768 is either a default or a misplaced error flag. I'll look at adding a separate key. If it works it's still a problem, but a workaround is available at least. Commented Nov 5, 2024 at 22:12
  • 1
    Assuming you used a different passphrase for the second slot, I conclude that your original setup has some kind of problem. Also I think using non-printable-ASCII characters in passphrases (as you seem to have) is a bad idea. Commented Nov 5, 2024 at 22:51

0

Reset to default

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.