I’ve installed Endeavor last week, and enabled full disk encryption. Everything worked fine, except for a weird thing where after the installation was completed and first boot was initializing, cryptsetup (I believe) hung on executing some post-installation script and the PC needed to be rebooted. Everything worked fine afterwards though, so I don’t know if this needs to be reported, especially since I don’t have logs.
However, today, I found out that the LUKS headers generated were quite strange. First of all, they were both (main and swap partition) version 1, which seems weird to me, since most distros - to my knowledge - already moved on to LUKS2 by default. Okay, no problem, I’ll just update them myself, although it should probably be changed by default, IMO.
Now, the weirder thing: Both partitions had two keyslots generated. Only one was the actual keyslot unlockable with the passphrase, while the second was something completely random. The key derivation function on it couldn’t be changed, cryptsetup wouldn’t unlock it (unlocking keyslot 1 only unlocked keyslot 0, for some reason?), and running cryptsetup luksRemoveKey with the correct passphrase would only remove keyslot 0, keeping keyslot 1, and subsequent tries to remove it with the passphrase just threw errors about there not being any keyslots with specified phrase. In the end I had to use luksKillSlot on it for each partition.
Now, I’m not too well versed in Linux encryption, but this seems like something that shouldn’t happen? I haven’t touched cryptsetup or anything else before today, so the keyslot definitely wasn’t created by me. The only things I can think of was either the post-install script doing something weird when it hung, or a bug in the default configuration. I’m not sure if I can help beyond what I wrote, since all the header upgrade had to oblviously be done in a live enviroment, so I don’t have any logs saves, but if I can, let me know.