Created attachment 403830 [details]
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):
* 3 of 3 attempts failed so far
Steps to Reproduce:
1. Follow instructions at https://fedoraproject.org/wiki/QA:Testcase_Anaconda_autopart_(encrypted)_install
* Keypresses not accepted, unable to enter passphrase. See attached screenshot.
* Enter my passphrase, unlock the encrypted partitions and boot the system
* 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
This does seem to trigger only for text mode passphrase entry. A graphical entry succeeds.
plymouth-0.8.1-3.fc13 has been submitted as an update for Fedora 13.
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
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.
In virt-install, both graphical and text mode contain this issue. But on bare metal, only text mode has it.
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
(In reply to comment #4)
> Haven't yet tried 0.8.1-3, hope to do so later today.
That's sorted it. Thanks!
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).
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.
booting with vga=0x318 on kernel command line in grub should make things boot (as a workaround)
*** Bug 578196 has been marked as a duplicate of this bug. ***
*** Bug 577836 has been marked as a duplicate of this bug. ***
Verified fix in plymouth-0.8.1-3.fc13 of F13 beta rc4
Verified fix in plymouth-0.8.1-3.fc13 by updating.
*** Bug 579709 has been marked as a duplicate of this bug. ***
Marking VERIFIED based on feedback from rhe and kparal. Thanks!
since it's in RC4, can't this be CLOSED now?
Fedora Bugzappers volunteer triage team
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.
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.
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.
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.
To make things complete, I still see the same problem on KVM using plymouth-0.8.1-3.fc13 :)
I think the old version of plymouth is still in the initrd.
Could you update the kernel or rebuild the initrd?
Yes, rebuilding initramfs solved it. :-)
what is the "right" way to rebuild the initramfs? I mean, in a way that will not break updates etc?
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
Running /usr/libexec/plymouth/plymouth-update-initrd fixed this. But I have other question - why wasn't this run automatically? Is that a bug?
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.