Bug 530896 - Password entry of an encrypted volume is broken in text mode
Summary: Password entry of an encrypted volume is broken in text mode
Alias: None
Product: Fedora
Classification: Fedora
Component: plymouth
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
Whiteboard: https://fedoraproject.org/wiki/Common...
: 530991 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2009-10-25 22:11 UTC by Thomas Meyer
Modified: 2009-11-15 11:39 UTC (History)
10 users (show)

Fixed In Version: 0.8.0-0.2009.29.09.19.fc12
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-11-11 14:57:41 UTC

Attachments (Terms of Use)

Description Thomas Meyer 2009-10-25 22:11:46 UTC
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):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 Thomas Meyer 2009-11-08 22:15:59 UTC
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?

Comment 2 Thomas Meyer 2009-11-08 22:33:02 UTC
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?

Comment 3 Scott Dowdle 2009-11-10 19:24:13 UTC
I'm testing the media of the RC4 build of Fedora 12 x86_64 found here:


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:


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.

Comment 4 Scott Dowdle 2009-11-10 19:30:58 UTC
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.

Comment 5 Scott Dowdle 2009-11-10 19:40:03 UTC
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.

Comment 6 Fedora Update System 2009-11-10 20:38:18 UTC
plymouth-0.8.0-0.2009.29.09.19.fc12 has been submitted as an update for Fedora 12.

Comment 7 Bradley 2009-11-11 07:44:04 UTC
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.

Comment 8 Adam Williamson 2009-11-11 10:31:37 UTC
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

Comment 9 Ray Strode [halfline] 2009-11-11 14:31:11 UTC
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.

Comment 10 Fedora Update System 2009-11-11 14:57:36 UTC
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.

Comment 11 James Laska 2009-11-11 20:04:35 UTC
Tagging for addition to the Common_F12_Bugs wiki page.  Adding link to existing documentation

Comment 12 Bradley 2009-11-12 08:04:48 UTC
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...

Comment 13 James Laska 2009-11-12 13:41:36 UTC
(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.


Comment 14 James Laska 2009-11-12 13:42:09 UTC
If you can, please also provide test feedback using https://admin.fedoraproject.org/updates/F12/FEDORA-2009-11334


Comment 15 Bradley 2009-11-12 13:50:47 UTC
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)

Comment 16 Bradley 2009-11-15 11:39:15 UTC
*** Bug 530991 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.