Description of problem: Password entry of an encrypted volume is broken in text mode. In text mode with "quiet" option, characters are echoed to the display! Without the quiet option the password is not echoed to the display, but also no text is given, like "please enter the password:"; you just see a cursor blinking on the screen, on a cleared black screen. Version-Release number of selected component (if applicable): dracut-13.4.git8f397a9b.fc12 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
My problems seems to got fixed mostly with: Name : plymouth Architektur : i686 Version : 0.8.0 Ausgabe : 0.2009.29.09.18.fc12 But I still encounter sometimes password entry strangeness, my assumption for the erratic behaviour is: 1.) Boot kernel in text mode with option "nomodeset". 2.) wait a long time (3 min?), and not enter any password and not press any key 3.) try to enter the password after the wait period will fail, with the keys pressed echoed to the screen again. But I need to verify this. Is there maybe some hidden password entry timeout?
Sorry. This error has nothing to do with some timeout. With "nomodeset" I get sometimes the text "/dev/sda4 is password protected", i.e. luks-swap. For this text the password entry works correctly. But sometimes with "nomodeset" i get this text: "/home ist schreibgeschützt", i.e. luks-home. For this text the password entry fails, by echoing the password you enter to the screen. maybe some language/translation problem? maybe this bug is related to my other bug regarding dracut, failing to setup the luks devices by using the /etc/crypttab file?
I'm testing the media of the RC4 build of Fedora 12 x86_64 found here: http://alt.fedoraproject.org/pub/alt/stage/12-RC.4/Fedora-12-x86_64-DVD/ I'll try other media RSN. I've done two installs (to verify), using custom partitioning... and I made /home 1GB and made it encrypted. I'm installing into a KVM VM from a Fedora 11 host. When the machine is booting for the first time after boot, it uses the text-based boot because I'm in KVM and KMS does not work. After the three-color progress bar finishes it prompts me: /home is password protected: At which point I attempt to type in a password. As reported in this bug report, it echos back in plain text the password I set during the install. When I hit enter, it redraws the screen text and replaces the plain text with *'s... but fails to authenticate. It prompts me again but the *'s remain and I can't backspace over them and try again. The authentication is completely broken and there is no way to get past this. Package set was the default for the DVD install media. Next I'll try the Live media. - - - - - Ok, I did an install from the RC4 media for Fedora 12 x86_64 Live KDE media and it behaved the same way. Media here: http://alt.fedoraproject.org/pub/alt/stage/12-RC.4/Fedora-12-x86_64-Live-KDE/Fedora-12-x86_64-Live-KDE.iso Checksum verified and booting from .iso image in KVM. Setup: KVM on a Fedora 11 host Pre-existing disk setup... I fdisk'ed it so it contained no partitions. Booted Live KDE media, ran the installer, picked custom partition setup. Made a 1024MB swap, made a 1024MB /home ext4 encrypted, turned the rest of the space (on a 10GB vda) into / ext4 using existing space... checked "force primary partition" (or whatever the exact wording is). Progressed, it asked me for a password for the /home partition. I put in a password that takes the form of "blah blah blah" three words, all lowercase letters, separated by a space. Reboot after install, the text-based mode happens. It prompts me for a password... echos plain-text, I hit enter, it redraws with *'s and then fails to authenticate and is stuck.
On a few additional install attempts, where I didn't zero out the partition prior to the install, the installer prompts me for the password to access /home and it works. From that I take that the portion of the boot process that prompts for the password and tries to process it is broken... but the actual backend configuration done by the installer is probably correct.
Last comment for today... don't want to kick the horse anymore. I tried the LiveCD for GNOME i386 and it behaved the same way. Bug appears to affect all builds of RC4.
plymouth-0.8.0-0.2009.29.09.19.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/plymouth-0.8.0-0.2009.29.09.19.fc12
The koji build fixes this, but I'm going to nominate this as an F12 blocker (yes, I know its late) I just upgraded from F11 x86_64 to rawhide, with an encrypted /home LV. After the upgrade I couldn't boot any more - I kept getting prompted for the password for /home with no option to skip (I tried adding rv_NO_LUKS to the grub cmd line based on some quick googling, but that didn't help) I have an nvidia card which I've never got to work with the graphical boot (although I haven't tried too hard), so the only workarround for me was to grab the rescue image and the koji packages under windows, work-around a liveusb-creator bug, boot into rescue mode, upgrade plymouth and then rebuild the initrd using dracut. Not sure if this hits only people using encrypted partitions rather than an entire encrypted drive, but its still going to hit a lot of people.
no, this isn't a blocker. you don't need KMS to get through, just a vga= parameter. it will be documented and the recommendation will be to install with update repos enabled so you get an updated plymotuh that doesn't have the problem. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
If this bug would have materialized a week ago we could have gotten it in, but at this point it's just not possible. It's a real shame, but there are a few mitigating factors: 1) The big 3 nvidia, ati, and intel have modesetting support for most cards, so this bug doesn't affect a lion's share of users 2) The bug can be worked around with vga=0x318 on the kernel command line (not a great workaround, I know) 3) This is going to go out as a 0day update, so users doing GA installs shouldn't be affected as long as they make sure to install with updates enabled Note, the fix is just a workaround. We need to figure out what's resetting the tty settings early in boot up.
plymouth-0.8.0-0.2009.29.09.19.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
Tagging for addition to the Common_F12_Bugs wiki page. Adding link to existing documentation
The wiki page isn't quite enough - after upgrading plymouth the initrd has to be regenerated. Not sure what the 'official' wayof doing that is with dracut, else I'd edit the wiki myself...
(In reply to comment #12) > The wiki page isn't quite enough - after upgrading plymouth the initrd has to > be regenerated. Not sure what the 'official' wayof doing that is with dracut, > else I'd edit the wiki myself... Thanks for the feedback. I've updated the instructions, please advise if additional corrections are needed. https://fedoraproject.org/wiki/Common_F12_bugs#encrypted-password-for-text-boot
If you can, please also provide test feedback using https://admin.fedoraproject.org/updates/F12/FEDORA-2009-11334 Thanks!
That script uses |uname -r| so if you use the workarround to boot, and then just run |yum update| and an updated kernel package gets updated by yum before plymouth then the new kernel will still have the old plymouth. Not an issue currently (since there isn't any kernel package in the updates repo, but will presumably be an issue at some point. The fix is to 'yum update plymouth', then run the update script before any other yum update. Not sure how to say that without it being confusing, though. Already provided feedback (anonymously because I forget to log in, though)
*** Bug 530991 has been marked as a duplicate of this bug. ***