Bugzilla – Bug 1047225
LUKS password doesn't show up when booting with nomodeset
Last modified: 2022-11-30 16:08:48 UTC
Install a TW system with the standard procedure for LVM+encrpption as suggested by installer on KVM. It works fine with the graphical LUKS password. But when you boot with nomodeset boot option, the boot process hangs without asking the LUKS password. This didn't happen on openSUSE Leap 42.2 / 42.3. And when I upgrade only plymouth packages on the Leap system, it starts showing the same problem. So, it's a regression in the recent plymouth package.
The bug was inspired by another bug report, bug 1020283, BTW. I just wanted to check the behavior, then hit this.
Reassigned to plmyouth maintainer. Also adding Scott to Cc as backup.
So many thanks for catching this. I'm wondering, Did we promised our customer to support all kernel parameter? especially like "nomodeset"? It maybe out of our work boundary. I mean any user manual or features cited about that?
The nomodeset option is very commonly used as a debugging technique. Many experienced customers/partners try it (or *we* ask at first) when something doesn't work regarding the graphics. That said, you can't treat it for justification not to fix this bug :) I reported here just because this is a regression from Leap 42.2/42.3, thus you have a better chance to catch it. A good thing is that it appears just by replacing plymouth on the formerly working system. So you can bisect the failure, too, if any. There are lots of other bugs by plymouth (e.g. bug 966255 or bug 1020283). This bug itself might be irrelevant from others, but it's easier to reproduce, at least, thus here reported individually.
Same issue after installing NVIDIA drivers (boo#1053811), although NVIDIA supports KMS meanwhile (/dev/dri/card0 being used by Xserver). So basically every customer using NVIDIA driver on a LVM/Encrypt setup is affected by that issue.
*** Bug 1053811 has been marked as a duplicate of this bug. ***
BTW, without plymouth in place I get asked for encrypt passwords for sda3 *and* sda4 But LVM also encrypts sda2. With plymouth and before NVIDIA drivers get installed I was asked only for *one* password. I also only gave one password for all partitions during installation. Is this a race or something in text mode? I could understand being asked for all three partitions, but only for two of the three?!?
(In reply to Stefan Dirsch from comment #5) > Same issue after installing NVIDIA drivers (boo#1053811), although NVIDIA > supports KMS meanwhile (/dev/dri/card0 being used by Xserver). So basically > every customer using NVIDIA driver on a LVM/Encrypt setup is affected by > that issue. I'm busy with other issues recently, so it's been delayed these days, Sorry. The point is that Nvidia's proprietary driver can not be supported, Because this driver doesn't work with KMS very well and KMS is the prerequisites of Plymouth. Which means if you are using proprietary display driver, you must disable Plymouth at same time.
(In reply to Zhao Qiang 赵强 from comment #8) > I'm busy with other issues recently, so it's been delayed these days, Sorry. > The point is that Nvidia's proprietary driver can not be supported, > Because this driver doesn't work with KMS very well and KMS is the > prerequisites of Plymouth. > Which means if you are using proprietary display driver, you must disable > Plymouth at same time. Ok. Let's uninstall plymouth when installing NVIDIA packages for TW/sle15.
(In reply to Stefan Dirsch from comment #9) > (In reply to Zhao Qiang 赵强 from comment #8) > > I'm busy with other issues recently, so it's been delayed these days, Sorry. > > The point is that Nvidia's proprietary driver can not be supported, > > Because this driver doesn't work with KMS very well and KMS is the > > prerequisites of Plymouth. > > Which means if you are using proprietary display driver, you must disable > > Plymouth at same time. > > Ok. Let's uninstall plymouth when installing NVIDIA packages for TW/sle15. Not so easy, since plymouth is required by plymouth-dracut apparently. And when obsoleting both by the nVIDIA KMP, the created initrd lacks plymouth so you get a blank screen for a pretty long time or alike. So this doesn't seem such a clever idea. Do we still have a way to specify additional kernel commandline options somewhere, so we can add "plymouth.enable=0" by default when installing nvidia?
(In reply to Stefan Dirsch from comment #10) > (In reply to Stefan Dirsch from comment #9) > > (In reply to Zhao Qiang 赵强 from comment #8) > > > I'm busy with other issues recently, so it's been delayed these days, Sorry. > > > The point is that Nvidia's proprietary driver can not be supported, > > > Because this driver doesn't work with KMS very well and KMS is the > > > prerequisites of Plymouth. > > > Which means if you are using proprietary display driver, you must disable > > > Plymouth at same time. > > > > Ok. Let's uninstall plymouth when installing NVIDIA packages for TW/sle15. > > Not so easy, since plymouth is required by plymouth-dracut apparently. > > And when obsoleting both by the nVIDIA KMP, the created initrd lacks > plymouth so you get a blank screen for a pretty long time or alike. So this > doesn't seem such a clever idea. Do we still have a way to specify > additional kernel commandline options somewhere, so we can add > "plymouth.enable=0" by default when installing > nvidia? Ok. Tried with omit_dracutmodules+="plymouth" in a dracut.conf.d snippet without uninstalling any plymouth packages. But then you still need to replace"splash=silent" with "splash=verbose" in kernel command line in addition. Otherwise you never get asked for a LUKS password. I'm currently testing with a single partition (/home) encrypted. This works with the nvidia driver installed despite having plymouth still installed and splash screen enabled ("splash=silent"). So currently I don't want to change this.
From my point of view, if customer installs proprietary software, he will lose support, especially this is not open source. proprietary software may affect the normal operation of other components, that is out of our control. I think we don't need to find the solution for this scenario.
(In reply to Stefan Dirsch from comment #11) > But then you still need to replace"splash=silent" with "splash=verbose" in > kernel command line in addition. Otherwise you never get asked for a LUKS > password. This implies that plymouth still plays a role. plymouth skips the default theme when splash=verbose option is set in the kernel command line. It's hard-coded.
Seems I've tested something stupid. I've made a clean full-encrypted LVM installation and now the combination omit_dracutmodules+="plymouth" for initrd creation and splash=silent as kernel command line parameter works for me. I've been asked for a password for the encrypted LVM partition setup.
(In reply to Stefan Dirsch from comment #15) > Seems I've tested something stupid. I've made a clean full-encrypted LVM > installation and now the combination > > omit_dracutmodules+="plymouth" > > for initrd creation and > > splash=silent > > as kernel command line parameter works for me. I've been asked for a > password for the encrypted LVM partition setup. This can be a difference between the encryption of the root fs and of the home directory, too. When a home directory is encrypted while the root fs isn't, the decrpyto password is asked after initrd, thus the system thinks it's done via plymouth.
Ok. Whatever. Nobody knows exactly, what's happening here for encrypted seperate /home partition in contrast to full LVM+encrpption. I've now covered full LVM+encrpption. Works with plymouth disabled for dracut and splish=silent. It has been tested. Packages on NVIDIA's repository have been updated. So issue has been fixed when using NVIDIA driver RPMs. ;-)
I seem to be getting this symptom both with and without nomodeset. This happened after an update and reboot with TW this morning. Neither the graphical or nongraphical password prompt is showing, working, or giving any visual feedback as I'm typing my password for my /home partition. Instead, I get to see either a HP splash screen or the last log message, and it hangs there. For all I know, it may be related to bug 1205309, which is more recent and ongoing, except I don't have a keyfile in my /etc/crypttab and grub works – I can boot in single-user mode, but this may just be because I don't have the problem of decrypting my root filesystem. https://bugzilla.opensuse.org/show_bug.cgi?id=1205309 I'm not using any proprietary drivers. I'm writing this in single-user mode, which allowed me to mount my files, switch user and run startx. Thank goodness this workaround works so well.
Uninstalling plymouth solved it for me too, but I'm not using nomodeset.