I recently moved to Tumbleweed, and am currently trying to unlock and mount my LUKS-encrypted data partition during boot like I did previously on recent Ubuntu LTS versions.
While Ubuntu’s boot waited for me to enter the partition’s password before login, Tumbleweed shows the password prompt for only a spit-second before displaying the login screen, with no obvious way back to the prompt. After login, I can manually unlock the partition and mount it using sudo mount -a.
I could reproduce the issue on two Tumbleweed systems with system role “Desktop with KDE Plasma” selected during installation, but a VirtualBox VM with system role “Generic Desktop” actually does wait for me to enter the password. All 3 installations boot via UEFI.
I am intentionally using the nofail option in crypttab and fstab. Using a keyfile instead of a password would be an acceptable fallback/workaround if the actual issue cannot be fixed, but I have not tested that yet.
Here’s what I did in detail:
Add cr_data UUID=f43ac9f2-0826-4ee4-837b-26fbf521b087 none nofail to /etc/crypttab
Add /dev/mapper/cr_data /home/brs/data ext4 defaults,nofail 0 0 to /etc/fstab
mkdir /home/brs/data
sudo dracut -fv
I’ve tried adding the x-initrd.attach crypttab option (which my encrypted root partition already has), but that left the system waiting indefinitely for the data partition to be unlocked (visible after hitting Esc during the boot process’s spinning circle stage) while there was no prompt for me to actually enter the password. I needed an installer USB stick and chroot to undo this attempt.
It has nothing to do with Ubuntu vs. Tumbleweed (besides, there is more than one Ubuntu LTS version).
nofail mount points are intentionally not added as dependency during boot by the upstreamsystemd project. The system boots without waiting for these mount points.
You can search systemd project issue tracker for this.
If you need this device (mount point), do not mark it as nofail.
Did you try to enter your password in that stage (i.e. did the system accept key strokes)?
I did not due to lack of any visible prompt, but will try. I’ll use the VM though in order to not put my system into an un-bootable state once more, and because of the keyboard issue following below.
It has nothing to do with Ubuntu vs. Tumbleweed (besides, there is more than one Ubuntu LTS version).
Therefore I wrote “recent LTS versions”: Based on backups I can confirm that both Ubuntu 22.04 and 24.04 did wait for me to enter the password, but earlier versions might already have as well. Just like Tumbleweed when installed with the system role “Generic Desktop” instead of “Desktop with KDE Plasma” does btw.
Thanks for the systemd hint, which has proven quite helpful in an unexpected way:
I did not find my problem in their tracker, but its options x-systemd.device-timeout and x-systemd.mount-timeout. These did not solve my problem either, but at least kept my system bootable when removing the nofail crypttab option:
Then, the login screen does not yet appear that split-second after the password prompt, but instead the prompt’s screen resolution changes (proprietary Nvidia G06 driver + Wayland). At exactly that point my keyboard became temporarily unresponsive (not even num lock toggleable) until the timeout was reached and the login screen appeared. So I did have time to view the password prompt but could not complete it.
This is one more reason for my intentional use of nofail wherever possible.
Anyway, by now I’ve set up the keyfile fallback/workaround and it works just fine.