I wanted to give Fedora a test, Gnome is not my fav desktop so I grabbed the latest (RELEASE DATE: Tuesday, April 28, 2026) iso. In live install setup I enabled my local keyboard and removed English keyboard, Selected to ‘use entire disk’ of the nvme and enabled encryption. it installed fine, but when try to boot this system I get a second password prompt after I already unlocked the partition once. It is possibly a LUKS & Plymouth problem? It’s hard to get textual logs from a system in this state but I got some photos showing where it gets stuck. Or if someone tries to reproduce the issue? Meanwhile I installed kde-desktop on the Workstation edition (not recommended). Edit: I have no special characters in my password. Currently using built-in AMD graphics.
Have you tried entering the password with both layouts, your local layout and English? I had seen problems before when trying to switch keyboard layout for plymouth/LUKS prompt.
Sounds similar to this thread: First reboot after Install the Fedora 44 KDE
What happens if you boot the live system again and try a cryptsetup luksOpen from there? This would rule out issues with the passphrase.
I have not tried this, but for reference I have never had a problem booting 44 Workstation with the same exact initial setup (same keyboard (Swedish, removal of English), same password, encryption, use entire disk.) My password is only alphanumerical.
I once locked myself out of a laptop BIOS by making the same typo when tpying an admin password and confirming it. And I couldn’t reproduce this typo to get back in. 
This is an easy thing to exclude, simply by unlocking the LUKS volume from a live system.
Also, by default, Fedora gives you only two tries to mount a filesystem. So if a typo snuck into your passphrase when setting it up, after trying twice with what you think is the passphrase, it would simply stop with an error. (This behavior can be changed by adding something like “tries=5” to the fourth field in /etc/crypttab and regenerating your initramfs.)
I appreciate your support Lars. However this simple password I am testing with is well known to me and I use it much too often. It is alphanumeric with only one capitalized letter. Shift key ought to be a universal qualifier across any keyboard map. I no longer run 44 KDE on this pc since I am testing 44 Workstation with kde-desktop right now. I attempted numerous boots to try and re-enter the password (and multiple re-installs) and failed in the same way every time, so I have 100% ruled out mistyping passphrase. The very same passphrase that I have zero issues getting to work with 44 Workstation install. TLDR: The exact same install procedure works with ‘Fedora 44 Workstation’ but fails with ‘Fedora 44 KDE Plasma’.
I am glad you solved your issue.
From your response, I feel like we aren’t talking about the same thing. I understand that your passphrase isn’t overly complex. But I wasn’t trying to say that you keep entering the passphrase wrong when unlocking. My suspicion was that you had a typo when setting up the system. So, as an example, instead of test123 as LUKS passphrase, you accidentally hit a 4 instead of 3, and the passphrase in the volume ended up test124. At this point, your computer and you would disagree what the “correct” passphrase ist. And no matter how often you try to unlock this volume with a correctly typed test123, it can never work, unless you accidentally reproduce the same typo that you made when setting it up.
In any case, I set up a quick Fedora 44 KDE test VM from the KDE Live system (i.e., using the new Anaconda installer). I followed the standard steps, no advanced partitioning, just “use the whole disk” and a LUKS passphrase test123 set in step 3. It unlocks and boots fine, so at this point, if it is a bug in the installer, I would say there must have been additional factors on your system to trigger it.
This discussion brings back a thought I have often had in the past: I wish the installer had a second checkbox “enroll a recovery key (recommended)” (which would only become available after selecting “encrypt”). When checking this, it would generate a random key and show it to you as a QR code, from where you could scan it with your phone and store it in a password manager. Like what systemd-cryptenroll --recovery-key /dev/nvme0n1p3 does and what I do on every new encrypted installation. This would help in the case of typos, forgotten passphrases, or even if a person passes away: their next of kin get access to the password manager (if they had the foresight to set this up) and can then unlock the contents of the disk.
My issue is not solved. I am -testing- the wrong solution now: ‘Fedora 44 Workstation’ with kde-desktop, which is not recommend from Fedora. I am quite new to Linux but not new to computers. If it cannot reproduces with a VM, maybe it’s something with my hardware? My current setup is quite new, quite simple. I am building a new Linux computer and so far I only connected Cpu, Ram, Nvme. AMD Ryzen9 9900X, 2x16 DDR5 sticks, the Samsung ssd you can see in the photos. I use the built-in graphics right now just for testing. Mainboard is “Gigabyte X870E AORUS ELITE WIFI 7” if it matters.
So far I have installed Fedora maybe 6 times, First 44-WS (worked, then I tried 44-KDE 3-4 times with the same setup and setting and it never worked to unlock the encrypted partition. and then I tested 44-WS again and no issues with passphrase. That means that something is different between these 2 releases of Fedora. And that difference does not work on my hardware.
Edit: I have Secure boot enabled in UEFI, not that it should matters since 44-WS works.
I don’t see how this could be hardware related, as long as we trust the CPU to produce correct computation results and data is correctly written to and read from RAM and flash. Since you don’t get constant data corruption on Workstation, this seems like a reasonable assumption.
From the symptoms you are describing, I can see this failing in two places (which is why the test I suggested would have given us some valuable insight):
- During setup: somehow, the volume key is written incorrectly
DuringluksFormat,cryptsetupgenerates a volume encryption key (which never changes, as it would require decrypting and encrypting every bit of data on the volume), then derives a key encryption key from your passphrase, encrypts the volume key with it, and stores the result in one of the key slots (slot 0 when setting it up for the first time).
(When adding another passphrase/recovery key/etc., it has to retrieve the volume key from another slot, which is why you need to enter an existing passphrase, then derives a new key encryption key from this new passphrase/… and stores the volume key encrypted with this key encryption key in an empty slot.) - During unlock: somehow, the volume key fails to decrypt correctly
During unlock,cryptsetuptakes your passphrase and the stored key derivation parameters like salt, derives the key encryption key again, decrypts the stored volume key with it, and uses the resulting volume key to access the actual data on the volume. If this doesn’t produce the same key encryption key that was originally used to write the data in the slot, the resulting volume key is incorrect and will not work for the volume.
I used the F44 KDE release ISO Fedora-KDE-Desktop-Live-44-1.7.x86_64.iso for my test, I don’t know which ISO you used. But you could also try the latest respin, which contains updated packages, in case there was a bug that was fixed:
https://dl.fedoraproject.org/pub/alt/live-respins/F44-KDE-x86_64-LIVE-20260731.iso
Or if you already used the respin, you could try the release ISO instead. This would give us another data point.
I decided to give the newer iso a try, just to have another data point (I was using the older one before as stated in my first post).
This time I paid extra careful attention to what I entered when i choose my passphrase in the setup. I tried to enter the same password as I’ve been using before with 44-WS and other attempts.
I was quite shocked to find out that no matter if I held the Shift key down OR used Caps-Lock, I could not get capital letters. All letters were lowercase in my entered password. Fine, I am just testing so I accepted my all lowercase password and moved on. After the initial boot I at least knew what to enter, so I entered the configured passphrase and it worked. This KDE version finally booted into the desktop.
I guess maybe we figured out whats going on now? Any ideas why Capital letters are auto converted to lowercase when entering into the passphrase prompt on KDE live?
Edit: I have isolated the problem to the Swedish keyboard in KDE Live setup. When this keyboard is chosen, it is not possible to enter Capital letters into the passphrase field. This could explain why this issue is not that common?
At least in a test VM, it doesn’t reproduce for me:
If the VM result is anything to go by, it is not just the Swedish keyboard layout that’s causing this. It might be related to some aspect of your hardware, maybe the keyboard itself (there was a thread recently where the keyboard itself behaved very weirdly).
But I am glad you figured out the root cause.
Lets look at the facts. It only happens in Fedora 44 KDE, not Fedora 44 Workstation. The Anaconda? installer when run from KDE Live does indeed behave a little differently than when run on Workstation Live, there is some small dialog that flashes by before the Anaconda UI opens. My keyboard is a wireless Logitech K400.
I have not yet tested if it makes a difference if I boot the KDE Live environment or start it from inside a KDE installation, that could be a difference.
Something else that I noticed is that When the wrong passphrase is entered (which it truly was) the response we get was unexpected.
The way the passphrase dialog closes completely and then reopens like nothing happened.
And what happens after is even stranger, the system tries to do something for 6 minutes or more before giving up and nowhere does it say that the wrong passphrase has been entered?
Lots of room for improvement here.
Edit: I noticed that you tested with Swedish language in the installer, no need for that. I use English (American) language and Only Swedish keyboard (I remove English).
I agree, the user experience isn’t great. The main issue I have is that it is limited to two tries. I think the input field going away, a ~1s computation, and then the input field reappearing, most people would interpret that as “wrong passphrase”. But then you get just one more try before the boot process unceremoniously dumps you into rescue mode, with a message that it wasn’t able to mount the rootfs. Someone without the background info on how cryptsetup/LUKS work probably won’t make the connection to “wrong passphrase”.
I am going to test that again later. I was just on the first step, where it asks the language, and then sets the keyboard to match. So I just selected Swedish, the input field was already selected and I am lazy. (And then proceeded through the next steps from memory, because I don’t read Swedish. I probably should have done what you do. 
)
As long as Anaconda is not super buggy, it should be possible to test using KDE Live. You shouldn’t need to run tests in a VM, but you can ofc not access your normal system while testing and booting KDE Live.
I have just performed numerous test with both the Logitech K400 keyboard and an old Microsoft USB keyboard. With the Microsoft keyboard I could not trigger the issue.
I have concluded that the problems are exclusive to Anaconda. The rest of the system does not seem to be affected by this keyboard issue.
I did one experiment that was quite interesting, I left Language and keyboard as default, tried caps lock with passphrase, worked, I went back to start screen of Anaconda, removed US keyboard and added Swedish instead, now when I tried caps lock with passphrase, I only got lowercase letters.
There is a clear correlation between K400 keyboard and a different keyboard language (maybe only Swedish, probably not). What I just don’t get is why I never had this issue with Workstation edition. I will do some more tests later. Here is my testing sequence, straight from fresh boot into KDE Live using K400 as mouse also: https://youtu.be/EPHvD-yGFYc
Edit: I just tried 44-WS, I had forgotten this, but the keyboard handling in “Gnome Live” is completely different from KDE Live (Gnome calls System keyboard to make changes), so probably the reason why no issues there.