Description of problem: After the upgrade from 0.6.0 to 0.7.0, system wouldn't boot. There are 2 separate encrypted partitions on my system /home and swap. Swap opens just fine, after entering password at boot time, but opening /home hangs without warning (probably asking for password, with no visible prompt). The only feedback that user gets is *very* slow progress bar. I had to boot from livecd and disable cryptsetup to be able to debug this problem. After downgrading plymouth to 0.6.0 I can boot successfully. Version-Release number of selected component (if applicable): plymouth-0.7.0-0.2009.03.06.fc11 How reproducible: Install and reboot.
I'm seeing a similar problem with 0.7.0. I get prompted for my /home key, but when I try to enter it, it's not cloaked and it never accepts the password. Result -- unable to boot machine with encrypted partition.
I tested it some more, and mkinitrd fixed it. Apparently, there is a compatibility problem between old plymouthd (0.6.0) executed from intird environment, and the new client (0.7.0). I beleive the following should be done: 1) Add plymouth-update-initrd to %postinstall of the plymouth package, to assure that the correct version of plymouthd is executed. 2) With all the fancy graphics boot options, it becomes increasingly difficult to troubleshoot boot problems, especially in cases when user input is required. 2.a) Add timeout for plymouth --ask-password, so that the boot can proceed without encrypted partitions to allow for better troubleshooting. This wouldn't help if / is encrypted, but that doesn't seem necessary, as it should contain only stuff from publicly available rpms, or otherwise encrypted content (shadow, ssh, etc.) 2.b) Add boot param for initrd to disable plymouth. I don't particularly like option a, as it can interfere with regular switch-on-go-fetch-coffee routine. It seems better coming back to password prompt, rather than fully booted machine without /home or swap. Some might argue that option b) can be solved by falling back to text/details plugin, unfortunately, I can't make it work right now, which proves that this would be a half-solution anyway, unless we can somehow keep plymouth bug-free. Current details plugin, asks for password, but doesn't accept input (some escaping is done somewhere, as all keystrokes are accepted literally). Text plugin seems even worse, as it appears to ask for password, but only echoes output to the console for everyone to see.
Just as a note, I finally made both text and details plugins work. the problem was with intrd created from chroot environment that didn't have encrypted partitions mounted. Still, plymouth should never crash living console in disabled state. Some signal trapping should be done to make sure that console stays sane and boot can proceed. Also, fade-in plugin seems to have a bug that causes it to crash after a first keystroke on password prompt.
*** Bug 489321 has been marked as a duplicate of this bug. ***
I tried updating plymouth to the most recent version and recreating the initrd afterward. I was still unable to boot the box. Same problem, the password isn't cloaked and is never accepted. Downgrading to 0.6.0-3 fixed the problem for me.
I'll also note that I get different behavior with kernel-PAE-2.6.29-0.207.rc7.fc11.i686 than with earlier kernels. Earlier kernels allow me to enter the password correctly, but it doesn't seem to do the right thing. With later kernels, it seems like the terminal echo when entering the password is broken. It also doesn't allow me to log in single-user...
So, much like jlayton, I get the same thing when I hit escape to get out of the pretty text boot. Password is not hidden and it doesn't actually unlock. Hitting enter moves it along, but then I fall into maint mode since /home is listed in fstab. When I leave it in the rhgb boot with the little bar along the bottom it acts slightly differently. I get the "/home is encrypted" message but the first key that I hit causes it to say "*error: unexpectedly disconnected from boot daemon" or something like that. It then goes on an dies and drops me into maint mode. I can't remember which (rhgb or details) but one of them will let me type my password to get into maint mode and the other won't let me type that pword either.
Regarding the fade-in crash, it is unrelated to this bug but I have fixed it upstream. http://cgit.freedesktop.org/plymouth/commit/?id=cdd49aac43e5e62d7d7ce15853cc9d0574a0a34f
plymouth-0.7.0-0.2009.03.09.1.fc11.i586.rpm + /usr/libexec/plymouth/plymouth-update-initrd worked fine with rhgb on the command line. Thanks for the quick fix to my part of the bug!
Between Charlie's fix and this one: http://cgit.freedesktop.org/plymouth/commit/?id=546fbdc0b8bff126066778ef789e00ddb47dfd49 we should be good to go. Closing, RAWHIDE, but if the problem comes back, please reopen.
It now works when I boot with "rhgb" on the command line. When I boot without that however, the terminal handling is still broken. The password is not hidden and it never unlocks. It also doesn't seem to "forget" the password after I hit return. Again, this problem goes away if I downgrade plymouth to the 0.6.0 version.
For the record, my kernel command line is: ro root=/dev/vg_hostname/lv_root nomodeset rhgb
Ok, I can recreate this but only during aboot. Do you get something along the lines of: /something is password protected: then say when you type in "password" and then backspace it all away you get: /something is password protected:password\droqssap/ When you press return you get a star for each not deleted letter plus 1. If you press Esc while entering the password and press enter it goes to a normal password entry with stars and responds correctly again including entering the correct password.
This should be fixed in tomorrow's rawhide by this commit: http://cgit.freedesktop.org/plymouth/commit/?id=9e3324a465e1d2d971b1a0a6a2ad4432ef239f82 If not, reopen yet one more time :-)