Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 578633 - Unable to enter passphrase to unlock encrypted disk partitions
Summary: Unable to enter passphrase to unlock encrypted disk partitions
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: plymouth
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 577836 578196 579709 (view as bug list)
Depends On:
Blocks: F13Beta, F13BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2010-03-31 21:13 UTC by James Laska
Modified: 2013-09-02 06:47 UTC (History)
15 users (show)

Fixed In Version: plymouth-0.8.1-3.fc13
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-04-07 21:50:44 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)
Screenshot.png (deleted)
2010-03-31 21:13 UTC, James Laska 		no flags Details
View All

Description James Laska 2010-03-31 21:13:55 UTC 
Created attachment 403830 [details]
Screenshot.png

Description of problem:

After a fresh install (autopart+encryption) of F-13-Beta-RC3, I'm unable to enter passphrase to unlock encrypted disk partitions.

Version-Release number of selected component (if applicable):

 * plymouth-0.8.1-1.fc13

How reproducible:

 * 3 of 3 attempts failed so far

Steps to Reproduce:

 1. Follow instructions at https://fedoraproject.org/wiki/QA:Testcase_Anaconda_autopart_(encrypted)_install
  
Actual results:

 * Keypresses not accepted, unable to enter passphrase.  See attached screenshot.

Expected results:

 * Enter my passphrase, unlock the encrypted partitions and boot the system

Additional info:

 * Ray indicated this may be due to http://cgit.freedesktop.org/plymouth/commit/?id=92cc20f82fbd0f650d8065204198b292b2f8153a
 * Adding to F13Beta for consideration as a blocker bug.  Encrypted installs are part of the Alpha release criteria - https://fedoraproject.org/wiki/Fedora_13_Alpha_Release_Criteria
Comment 1 Jesse Keating 2010-04-01 01:02:25 UTC 
This does seem to trigger only for text mode passphrase entry.  A graphical entry succeeds.
Comment 2 Fedora Update System 2010-04-01 05:25:13 UTC 
plymouth-0.8.1-3.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/plymouth-0.8.1-3.fc13
Comment 3 Adam Williamson 2010-04-01 06:05:50 UTC 
just for the record, note that we hit an exactly analogous issue in F12 - https://bugzilla.redhat.com/show_bug.cgi?id=530896 - and actually decided to ship F12 Final with it broken and documented in CommonBugs. Yay for higher standards!



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 4 Matt Bernstein 2010-04-01 08:29:36 UTC 
I have /home and swap encrypted. In graphical mode, the passphrase (which used to unlock both) now only unlocks /home--so I think both modes are broken. I guess the common case is to encrypt the PV containing everything, but my legs are hot enough and I'm personally not too fussed about /etc/shadow.

Haven't yet tried 0.8.1-3, hope to do so later today.
Comment 5 He Rui 2010-04-01 10:49:34 UTC 
In virt-install, both graphical and text mode contain this issue. But on bare metal, only text mode has it.
Comment 6 Fedora Update System 2010-04-01 19:32:29 UTC 
plymouth-0.8.1-3.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update plymouth'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/plymouth-0.8.1-3.fc13
Comment 7 Matt Bernstein 2010-04-02 09:15:22 UTC 
(In reply to comment #4)
> Haven't yet tried 0.8.1-3, hope to do so later today.    

That's sorted it. Thanks!
Comment 8 Kamil Páral 2010-04-02 10:21:42 UTC 
Is there some way to work around the issue to test the new plymouth version? When I can't boot to the system, I can't upgrade plymouth. (I'm using KVM, so I have only text boot mode available).
Comment 9 Jesse Keating 2010-04-02 16:54:17 UTC 
I had to start an install, let it unlock the filesystem, then go to a tty and chroot into it to download the new plymouth and install it.  Kind of a hard workaround.  I think this is because rescue mode broke for me with encrypted FS.

Another alternative is to do another install but enable the updates-testing repo since this plymouth is in updates testing.
Comment 10 Ray Strode [halfline] 2010-04-05 14:06:42 UTC 
booting with vga=0x318 on kernel command line in grub should make things boot (as a workaround)
Comment 11 Ray Strode [halfline] 2010-04-05 15:22:40 UTC 
*** Bug 578196 has been marked as a duplicate of this bug. ***
Comment 12 Ray Strode [halfline] 2010-04-05 15:29:04 UTC 
*** Bug 577836 has been marked as a duplicate of this bug. ***
Comment 13 He Rui 2010-04-06 07:13:17 UTC 
Verified fix in plymouth-0.8.1-3.fc13 of F13 beta rc4
Comment 14 Kamil Páral 2010-04-06 09:10:21 UTC 
Verified fix in plymouth-0.8.1-3.fc13 by updating.
Comment 15 Charlie Brej 2010-04-06 11:38:33 UTC 
*** Bug 579709 has been marked as a duplicate of this bug. ***
Comment 16 James Laska 2010-04-06 14:31:49 UTC 
Marking VERIFIED based on feedback from rhe and kparal.  Thanks!
Comment 17 Adam Williamson 2010-04-06 16:32:07 UTC 
since it's in RC4, can't this be CLOSED now?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 18 Jesse Keating 2010-04-06 18:06:42 UTC 
It'll get closed by bodhi when it gets pushed to stable, which I couldn't do last week because nobody would give it karma.
Comment 19 Fedora Update System 2010-04-07 21:50:38 UTC 
plymouth-0.8.1-3.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 20 Martin Kho 2010-04-08 08:55:56 UTC 
Hi,

I don't want to be unfriendly, but for me version 0.8.1-3 gives in VirtualBox still an assertion failure (bug marked as duplicate in comment #12). Sorry.

Martin Kho
Comment 21 Andrew Jones 2010-04-08 10:05:33 UTC 
I'm also still hitting the assert with F13 Xen guests. Even with vga=0x318 on the command line.

plymouthd: ply-event-loop.c:707: ply_event_loop_watch_fd: Assertion `fd >= 0' failed.
Comment 22 Michael Monreal 2010-04-08 10:48:36 UTC 
To make things complete, I still see the same problem on KVM using plymouth-0.8.1-3.fc13 :)
Comment 23 Charlie Brej 2010-04-08 11:45:30 UTC 
I think the old version of plymouth is still in the initrd.
Could you update the kernel or rebuild the initrd?
Comment 24 Martin Kho 2010-04-08 12:33:45 UTC 
Hi,

Yes, rebuilding initramfs solved it. :-)

Thanks,

Martin Kho
Comment 25 Michael Monreal 2010-04-08 13:25:42 UTC 
what is the "right" way to rebuild the initramfs? I mean, in a way that will not break updates etc?
Comment 26 Charlie Brej 2010-04-08 13:47:26 UTC 
The command is this:
dracut -f /boot/initramfs-$(uname -r).img $(uname -r)

Although I can never remember that one so I usually just run:
plymouth-set-default-theme charge --rebuild-initrd
Comment 27 Kamil Páral 2010-04-08 13:54:06 UTC 
Running /usr/libexec/plymouth/plymouth-update-initrd fixed this. But I have other question - why wasn't this run automatically? Is that a bug?
Comment 28 Ray Strode [halfline] 2010-04-08 20:28:11 UTC 
it's a design decision that was decided early on.

At some point plymouth will have it's own initrd layered on top of the main initrd (see plymouth-generate-initrd) that we can rebuild automatically on updates.

I added support to grubby to handle multiple initrds a few releases ago, but we just haven't pulled the switch to change things over yet.  It won't happen for f13.
Note You need to log in before you can comment on or make changes to this bug.