Cannot open any luks files after recent updates


I’m running Fedora 32. I have several backup disks which have all been encrypted with cryptsetup and were working fine until a few days ago. Now when I do cryptsetup luksOpen path-to-device name
I get an error that the key is invalid.

No key available with this passphrase.

This happens on all of my backup drives. They’re all different physical drives in separate enclosures. The only commonality is they use serpent-cbc-plain for the cipher. I also tried booting the last kernels in the grub list but cryptsetup luksOpen fails the same way.

When I boot the rescue image I get a message that the cipher isn’t available, I guess the kernel module is not in the rescue image. So I am not able to verify that it is related to kernel level or app level.

I did create a new luks file with the same cipher and hash and I am able to open and close it several times. It suggests some component was updated and broke access to older files.

Any help guys? I have around 3T of data offline now. Thank you. Bill

Can you try to boot with older kernel?

1 Like

Yes, as I wrote, I tried all the kernels in my grub list. It did not help.

Have you alredy tried to downgrade cryptsetup? Was there a cryptsetup update “a few days ago” as you mention or do you suspect any other updated package to break cryptsetup?

sudo dnf downgrade cryptsetup

Thank you, I just tried this. I am still getting the same error message.

I wonder if newer kernels changed the code for the serpent cipher. I don’t know what to suspect. I usually take a quick look at updates and accept them all. I do

dnf upgrade --refresh a couple times a week

Thank you

How about starting a Fedora 32 Live media and see whether you have acess to your luks containers?


Thank you! I’ll download and burn the ISO and try it!

Thanks! Ok, this works. Data is fine. What should I do now? How can I identify the differences that could cause the problem, since the Live disc works like Fedora did until a few days ago?


No idea, what’s going on there.

You may want to compare

 ls /lib/modules/$(uname -r)/kernel/crypto/

on the Live system vs. “your updated F32 system”
Does your “updated F32 system” list serpent-cbc when you run cryptsetup benchmark?


Thank you. I’ll compare them, can’t boot the live image right now. One thing I noticed is that some ciphers like blowfish, twofish have both _common and _generic.ko.xz modules but serpent only has _generic. I don’t know if this means something is missing or that the _common is not needed.

Checking dnf provides, I see it serpent is only in the kernel package and back to 5.6.6-300 there is no serpent_common listed.

Yes, the installed F32 does show serpent-cbc in the cryptsetup benchmarks.

Have you actually tried to specify the cipher when opening the container?

cryptsetup --cipher serpent-cbc-plain luksOpen path-to-device  

That is a good question. I am not familiar, so I am afraid I can’t be of much help here. If this was my machine, I would file a bug (against cryptsetup) since this is a serious regression. Something that works with the live image is supposed to be supported throughout the entire life cycle of a Fedora release.


Interestingly, when I specify the --cipher or -c it doesn’t help.

I changed it to -c dummy-abc-plain and the outcome is the same. I would expect to get an invalid cipher message but it still gives me the no key available with this passphrase message.

I’ll look into filing a bug but I’m not hopeful that I’ll be able to give enough doc to answer their questions.

By the way, I would hope this would be valid forever, some of these containers are many years old. I expect luks to be upward compatible or that would be a disaster for anybody who relied on it for archiving.

Thanks again!


It doesn’t produce anything useful, command failed with code -1 (wrong or missing parameters).

When I have time I’ll create a luks container using the live image and maybe it will fail to open on the installed system. has been down since I read your post about filing a bug. I want to try to check for anything related but getting 503 Service Unavailable. Maybe that page depends on luks :smiley:

site still broken after 3 or 4 days

This one is broken since two years, two alternative web apps have been developed, sadly none has been deployed. What is the information you were trying to look up on the Packages app? We can help you find it elsewhere…

1 Like

Oh thanks, I was looking to file a bug based on your note in one of your replies above. It linked to the broken site.

Good news, cryptsetup.x86_64 2.3.5-2.fc32 and cryptsetup-libs.x86_64 2.3.5-2.fc32 have fixed the issue.

1 Like