Since the latest update(s) to fedora Workstation 44, 8-9 days ago, I cannot open encrypted external drives anymore. I am guessing something broke the usermode workflow for doing so.
I am being prompted for the password when inserting the drive and then nothing happens. When I open Nautilus, it is still locked and when I go try access the drive, it keeps asking for the password again to then show some input/output error.
No, the drive(s) aren’t faulty. It works perfectly fine on cachy (same kernel version) and Ubuntu. As a matter of fact I even tried it on another fedora system before updating (works) and after (same as above).
I have yet to manually luksOpen and mount as root from terminal, but I am guessing that may work as the system itself sits on an encrypted drive and that unlocks perfectly fine during boot.
Unencrypted external drives mount fine, too.
Anyone else having that issue? Anyone got any ideas? How can I troubleshoot this further? How do I report this as a bug since I am certain this isn’t some obscure config error given that I have tested it on what is basically a vanilla installation and it reproducably works before and then doesn’t.
When trying to unlock the disk from gnome disks I get the slightly more verbose error “input/output error (udisks-error-quark,0)”.
Again only on fedora (after updating). Works before the updates and works on ubuntu and cachy so definitively not an issue with the drives (tried HDD, nvme and usb drives).
IO error while decrypting keyslot.
Keyslot open failed.
I mean I would believe the drive or the luks header to be broken, were it not for the fact that this happens with all my drives and only stops working after whatever got updated 8-9 days ago.
I was able to narrow it down to the kernel. On the one system where it stopped after updating a little over a week ago, the latest retained kernel i could go back to was 7.0.11-200. That one still didn’t let me access the drive. However, the other system hadn’t been updated in a while so it jumped from kernel 7.0.8 to 7.0.12. While 7.0.12 is broken, I can confirm that simply booting into 7.0.8 allows me to use the drives. I am guessing the update to 7.0.10 (?) introduced a regression.
It is possible to open the drive on the 7.0.12 kernel
Export the luks header to file: luksHeaderBackup --header-backup-file <headerfile>
Then, when opening the drive, specify the header file: cryptsetup luksOpen --header <headerfile> <device> <volume>
The implication here is that the actual bug is in the reading of the keys from header data on the drive.