After typing passphrase for encryption at the disk encryption screen, the boot is forever stuck on the Fedora logo splash screen with the spinner. Hitting Esc to hide the splash screen shows that systemd-cryptseup fails.
The weird thing is, this only happens sometimes, once for every few successful boots. I have no idea what’s going wrong when this happens.
Cause
This issue only started popping up after I upgraded from Fedora 41 to Fedora 42 Workstation. Other than that, I don’t know what’s going wrong.
Workarounds
The only ‘workaround’ I found against this is to restart my PC and try entering the passphrase again.
Does anyone have any idea on why this is happening or how to prevent this?
So I had this same issue and finally got it fixed.
What was happening for me is I noticed that cryptsetup was trying to decrypt my home partition twice (not sure why because the the initramfs should do that) but on the second time it tried to decrypt it the partition was busy.
Looking further I noticed that right before cryptsetup tried for the second time a fsck was triggered and was actively running on my home partition which seemed to cause cryptsetup to error out and halt the boot.
So I ended up booting into a live session and mounted all my partitions and chrooted into it, then i updated my /etc/crypttab for the home partition and at the end added “,noauto”, then in my /etc/fstab i removed the flag to run a fsck at boot.
When I rebooted i still got dropped into emergency mode but this time cryptsetup didnt try to access the partition again, but the journal log said that i needed to run a manual fsck.
So I booted back into a live session, decrypted the partition and ran a manual fsck then rebooted and I was able to hit the login screen.
Thanks for replying! I haven’t encountered that issue after some of Fedora’s recent system updates, so I’m assuming it got fixed. I’ll mark your answer as the solution anyway in case I or someone else has this issue again.
I recently starting having the cryptsetup issue again, and I want to try your solution. I wanted to ask if having to boot into a USB live session is really needed or if I can edit the files after i successfully booted into my PC?
Hi. I have the same issue on two installations of fedora 42, on separate devices. As far as I can tell the behaviour is as follows:
If I enter the decryption password correctly, the issue does not occur.
If I enter no password and hit Enter, I am prompted to re-enter my password. I can repeat this an arbitrary number of times.
If I enter a wrong password, I am prompted to re-enter my password once. If I enter a wrong password again, then the issue described above occurs.
I have tried to inspect logs for the failed boots, but I cannot obtain these with journalctl -b -1. The boot messages for the failed boots are not written to the journal—this is unsurprising since the journal is stored on the partition which does not get decrypted. After reaching basic.system, how can I get to a shell and read boot messages?
I have removed the rhgb and quiet options from my grub command line. While this does lead to many more messages before the password prompt is shown, it does not show anything helpful after the wrong passwords are entered, as far as I can tell.
I’m not sure whether this is relevant, but my root and home partitions are on separate subvolumes of the same encrypted btrfs partition. This encrypted btrfs partition is the only entry in crypttab, and there is one entry for each partition in fstab. All this was setup automatically by the fedora installation process.
The post above mentioning fsck will not apply here, since btrfs does not use fsck. The fs_passno flag in fstab is set to 0 for both partitions in my fstab. This again was set up automatically by the fedora installation process, and it follows the recommendation in man 8 fsck.btrfs according to which:
…Traditional filesystems need to run their respective fsck utility in case the filesystem was not unmounted cleanly and the log needs to be replayed before mount. This is not needed for BTRFS. You should set fs_passno to 0.
@theta-sigma Is the behaviour similar on your system? And is your partition setup similar to mine?
Huh. What a strange design choice. Are you aware of any setting to increase the number of permitted attempts?
For clarity: what I’m seeing is even more extreme than what you describe in the RFE. In my case only one failed password is accepted. Upon entering a wrong password on the second, not third prompt, I already see the behaviour described above.
I’m guessing that this is to prevent automated attacks against the system.
It is a common security practice to slow down the rate that password/passphrases can be be tried.
Thank you for the link to the original discussion. Interestingly, I still see the same behaviour when booting without the rhgb option, which makes me question whether plymouth really is the cause on my machine. Do you know whether removing rhgb actually disables plymouth, or is it still somehow active? I might try to disable the service entirely, and will report here if I do.
EDIT: I have just tried to boot without rhgb and with rd.plymouth=0 plymouth.enable=0 and am still seeing the same behaviour. systemd-cryptsetup fails after two wrong passwords
It might also be worth noting that I use debian on another computer, with plymouth and encrypted LVM partitions (but not btrfs and subvolumes). I do not see the same behaviour there. Of course that’s an entirely different distribution, so perhaps this is not relevant.
I understand this practice when attacks can take place over a network. Please correct me if I’m wrong, but in this case, wouldn’t an attacker have to gain physical access to the machine before they can attempt to crack the encryption? At which point they may as well remove the drive and use a separate machine for the attack, effectively bypassing any limitation on number of password attempts.
After a bit of digging in the man pages, I have found a simple way of preventing the behaviour above and just have the boot process prompt for passwords without any limit on the number of attempts.
In /etc/crypttab, locate the line corresponding to the root partition / LVM containing the root partition / btrfs partition containing the root subvolume. Add ,tries=0 at the end of this line to allow unlimited attempts. (Adjust if you want a different max number of allowed attempts.)
Regenerate the initramfs for the current kernel with sudo dracut --force, or for all installed kernels with sudo dracut --regenerate-all --force
Here is the relevant passage from man 5 crypttab:
tries=
Specifies the maximum number of times the user is queried for a password. The default is 3. If set to 0, the user is queried for a password indefinitely.
if you need to run a fsck on your home or root partition then yes u would need to live boot. it’s not recommended to run a fsck on a mounted file system as it can lead to corruption and data loss. the home and root partition aren’t partitions u can safely unmount while linux is actively running thus the need for a live boot session. theres also ways to run fscks at boot, but this actually seems to be the problem to start with (for my issue) so thats not really an option because the fsck would fail.
if you can boot into your system successfully then you do not need to live boot and chroot the broken system to edit the options i made in my crypttab/fstab. for me i got totally brick walled and could not boot at all so it forced me to go the live boot route.
just remember after changing ur options in fstab and crypttab to regen the initramfs with dracut.
i’ll drop some links on how to chroot (if needed) and to regenerate your initramfs:
also, since your problem seems more intermittent i think i would suggest permanently disabling rhgb and quiet in the grub options so that when it does happen u can see what exactly is going on when it does happen. if you see the same behavior i noticed with the fsck issue then my solution will probably work for you, if not it may require some more digging.
@theta-sigma To add to what @bjhazelwood says: if the issue is related to fsck, you should indeed follow their solution (and in that case, I apologise for hijacking this thread!). If however the issue happens when you enter multiple wrong passwords—your mentioning that restarting the PC helps makes me think this might be the case—you can try following my last post. Thought I would mention this in case you are having trouble knowing what suggestion to pick.
Hi, I decided to test the wrong password theory. It turns out, that was the issue this whole time. It would’ve helpful if the devs added a clear message that said something about password attempts running out (the failed dependency thing made me think something was wrong with my system or an update).
In /etc/crypttab, locate the line corresponding to the root partition / LVM containing the root partition / btrfs partition containing the root subvolume. Add ,tries=0 at the end of this line to allow unlimited attempts. (Adjust if you want a different max number of allowed attempts.)
Regenerate the initramfs for the current kernel with sudo dracut --force, or for all installed kernels with sudo dracut --regenerate-all --force
Adding ,tries=0 fixed the issue. Thank you for the help, @ivandx!
@theta-sigma , @ivandx , since you both consider that a message to the user would have been helpful, if you consider appropriate, you could add a comment to the Bugzilla RFE linked above.
For those requiring added security, I would recommend against using the tries=0 flag, but increase the number of accepted tries instead.
