This issue began this morning. I update everything daily, so I assume that an update from yesterday (Nov 21) broke something, possibly with Plymouth. I have 5 partitions / drives that are encrypted, all with the same password. Under normal circumstances, I am only prompted via Plymouth a single time and all drives are unlocked.
This morning, Plymouth prompted me and I entered the password. After a 30 seconds, I hit “escape” to see what the delay was. I was greeted with a flashing cursor that was unresponsive to input. I used ctl>alt>F1 to go to a terminal session and rather than being prompted to log in, I was being prompted to enter the crypt password again. Once entered, I was taken directly to the SDDM login screen.
On a reboot, I hit “escape” to bypass Plymouth when entering the password. The password was accepted, but I was once again left with a flashing cursor. Switching to a terminal again greeted me with another request for the password, but for a specific drive. Once entered, it again went directly to SDDM login.
On the rare occasion I do a typo when entering the password in Plymouth, I was always re-prompted in Plymouth to re-enter the password. I am sure that I am entering the password correctly. I am not sure if this is Plymouth related or even initrd or system related. I now understand the workaround, but would like to fix the problem. fstab and crypttab both appear to be correct. All partitions other than root have the “nofail” parameter set in fstab, as has been the case for years with multiple versions of Leap prior to Tumbleweed.
I would add that this morning, the problem persists, but the second password requested was for a different drive than last time. That would possibly clear drive initialization as a problem since the password requested today was for my home partition, which resides on the same drive as root. Root was already decrypted.
Is “/boot” part of your root file system, or is it a separate partition?
If it is part of the root file system, then you should be asked for the encryption key by grub.
Here’s my experience when “/boot” is part of the root file system:
I am prompted for the key by grub2. And it now hands over the key to the kernel.
I have another encrypted partition. I used to be prompted by the kernel to unlock both the LVM with root and that other partition. I was prompted once. But now I am not prompted for the LVM. But I am still prompted for that other partition. The prompt comes a lot later, possible after plymouth has finished. (I do not normally show the plymouth screen, so I see the prompt on the console).
Hmm. I did not even get prompted for entering my passphrase. Hitting escape showed in the top-left the cursor blinking and trying to switch with CTRL+ALT+F1 did not do anything. I rolled back to the previous snapshot. I have a separate boot partition and a separated root.
I have the exact same behavior on my machine (/boot on a separate partition). I will look into that issue but if I cannot find a solution I will roll back to a snapshot for the time being.
I’ve disabled Plymouth and set splash=verbose and now I am openly prompted a second time for the drive password. My Plymouth workaround is no longer necessary. It seems that the core of the problem is that the system is no longer unlocking all encrypted drives / partitions during boot after the original password entry, thus prompting a second time for the password. I does seem to only miss one single drive / partition when first unlocking drives. I am only prompted for a single missed drive during the second password prompt, but the missed drive is not constant. Sometimes it is my “home” partition and sometimes it is another encrypted drive. The “root” partition never fails to unlock the first time.
I have 4 locked drives / partitions. All are EXT4 and all have identical fstab and crypttab entries. 3 are always unlocked with the first password entry and I am always prompted for the 4th, regardless of which ends up as being number 4. In other words, there now seems to be a limit of how many can be automounted with a single password entry.
Interesting. I use an encrypted LVM, so that root, home and swap are all managed the one time. I do have a second encrypted partition. But that only makes two rather than the four that you have.
Now this is one of those examples where you see that the community really works well and problems are solved quickly and appropriately.
Partly for this reason I am very happy with openSUSE and the active community!
P.S…
Given the low number of reports of this problem, it is quite clear that very few openSUSE users are exploiting the encryption capabilities. In itself, that can be considered as risky & troublesome. However, that is another topic and not for this thread.
Disk/partition encryption only protects data on a machine that is not running. If bad guy get into a running machine all the data has been unencrypted buy the person starting the machine.
Disk encryption works as long as the disk or partition is not decrypted, also on a running laptop I keep several partitions encrypted and decrypt n;y when needed. As for the /home partition, you guys are right. Downright clumsy to keep that encrypted on a booted system
In any case, encrypted partitions increase security and it is important to use the security features in openSUSE as well as possible and to configure them properly. You are also right when you mean to say that there are many more security enhancing options within openSUSE besides LUKS disk encryption. However without disk encryption I won’t go out with my laptop.
If real security is required nowadays QUBES OS is really the only workable and reliable option left (nothing more has been heard of SUBGRAPH OS and it seems to be bleeding to death), although I would like to see QUBES OS with KVM and a KDE desktop instead of Xi and XFCE (the larger attack surface of KDE desktop compared to XFCE I gladly take for granted). With QUBES OS you do take a big downgrade on the ease of work compared to what openSUSE under KDE offers. openSUSE Tumbleweed with KDE desktop offers for me the everyday standard, which with proper configuration is also secure enough. I regard the LUKS disk encryption as an essential part of that configuration, as far as my laptops are concerned.
The proper configuration I am referring to also serves to keep bad guys out of the running machines.
We all know that convenience is preferred over security by most users. Convenience and security are opposites.
