Description of problem: Version-Release number of selected component (if applicable): Fedora-Live-Desktop-x86_64-20-Beta-TC6.iso gnome-disk-utility-3.10.0-1.fc20.x86_64 How reproducible: Always Steps to Reproduce: 0. qemu/kvm boot Live Desktop with a qcow2 device attached that contains a default Fedora 19 installation via Guided partitioning with encryption checked. 1. Launch Disks. 2. Click on the encrypted partition, click unlock button. 3. Enter passphrase to unlock appears; I try to enter password but there is no text or bullets entered. Actual results: Unable to unlock the disk, even meticulously typing the password in the blind. Error unlocking encrypted device Error unlocking /dev/vdb2: Command-line 'cryptsetup luksOpen "/dev/vdb2" "luks-<uuid>"' exited with a non-zero exit status 1: (udisks-error-quark, 0) Expected results: I should be able to unlock the disk from live media. Additional info:
Proposed as a Blocker for 20-final by Fedora user chrismurphy using the blocker tracking app because: "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use."
cryptsetup luksOpen works. After cryptsetup luksClose and relaunching gnome-disk-utility, it now unlocks this partition. Reboot, go straight to gnome-disk-utility, it works! It's a Heisenbug!
Discussed at 2013-11-13 blocker review meeting - http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-13/f20-final-blocker-review-1.2013-11-13-17.01.log.txt . Agreed to delay determination while we attempt to reproduce it. Chris, can you try again with Beta? Others will test this too, thanks to kparal.
I can't reproduce it with Beta (RC5). I tried it 5 times and unlocking worked each time.
Discussed in 2013-11-14 Blocker Review Meeting [1]. Voted as a RejectedBlocker because currently this seems to be very hard to hit, and is therefore rejected as a blocker. Please re-propose if you find a reliable reproducer. [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-14/
I now think this is a different bug, where VNC keyboard input simply doesn't work until I click on another application window and then back to TigerVNC's window. This probably should be closed unless it can be reproduced other than with VNC.