Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Unable to enter passphrase to unlock encrypted disk partitions|
|Product:||[Fedora] Fedora||Reporter:||James Laska <jlaska>|
|Component:||plymouth||Assignee:||Ray Strode [halfline] <rstrode>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||13||CC:||awilliam, dcantrell, drjones, fedora, jturner, kparal, lmacken, maurizio.antillon, mb--redhat, mclasen, michael.monreal+bugs, rh-bugzilla, rhe, rstrode, thomasj|
|Fixed In Version:||plymouth-0.8.1-3.fc13||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-04-07 17:50:44 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description James Laska 2010-03-31 17:13:55 EDT
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-03-31 21:02:25 EDT
This does seem to trigger only for text mode passphrase entry. A graphical entry succeeds.
Comment 2 Fedora Update System 2010-04-01 01:25:13 EDT
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 02:05:50 EDT
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 04:29:36 EDT
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 06:49:34 EDT
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 15:32:29 EDT
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 05:15:22 EDT
(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 06:21:42 EDT
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 12:54:17 EDT
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 10:06:42 EDT
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 11:22:40 EDT
*** Bug 578196 has been marked as a duplicate of this bug. ***
Comment 12 Ray Strode [halfline] 2010-04-05 11:29:04 EDT
*** Bug 577836 has been marked as a duplicate of this bug. ***
Comment 13 He Rui 2010-04-06 03:13:17 EDT
Verified fix in plymouth-0.8.1-3.fc13 of F13 beta rc4
Comment 14 Kamil Páral 2010-04-06 05:10:21 EDT
Verified fix in plymouth-0.8.1-3.fc13 by updating.
Comment 15 Charlie Brej 2010-04-06 07:38:33 EDT
*** Bug 579709 has been marked as a duplicate of this bug. ***
Comment 16 James Laska 2010-04-06 10:31:49 EDT
Marking VERIFIED based on feedback from rhe and kparal. Thanks!
Comment 17 Adam Williamson 2010-04-06 12:32:07 EDT
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 14:06:42 EDT
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 17:50:38 EDT
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 04:55:56 EDT
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 06:05:33 EDT
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 06:48:36 EDT
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 07:45:30 EDT
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 08:33:45 EDT
Hi, Yes, rebuilding initramfs solved it. :-) Thanks, Martin Kho
Comment 25 Michael Monreal 2010-04-08 09:25:42 EDT
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 09:47:26 EDT
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 09:54:06 EDT
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 16:28:11 EDT
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.