Description of problem:
If a LUKS1-encrypted USB drive or SD card is inserted the known dialog pops up which asks for the passphrase. But neither pressing <Enter> (after passphrase was entered) nor clicking "Unlock" nor clicking "Cancel" has any effect here.
Version-Release number of selected component (if applicable):
GNOME Shell 3.30.0
Boot the Beta 1.3 ISO (https://dl.fedoraproject.org/pub/alt/stage/29_Beta-1.3/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-29_Beta-1.3.iso) and insert a LUKS1-encrypted USB stick or SD card.
Steps to Reproduce:
1. Boot Beta 1.3 Workstation Live ISO
2. Insert a LUKS1-encrypted USB stick or SD card
3. Try to press "Unlock" or "Cancel"
The dialog asking for the passphrase won't go away.
The dialog should go away when pressing "Unlock" or "Cancel".
This is a F29 Workstation installation on a non-UEFI laptop which is up-to-date; updates-testing is enabled. The same problem appears when booting the Beta 1.3 Workstation Live ISO from USB.
The problem still exists when using Fedora 29 Beta 1.5.
The same problem in Arch Linux.
I'm seeing this issue on Arch Linux as well.
The mounting succeeds when clicking unlock, by the way. It's just that there's no way to get rid of the dialog afterwards. It also only seems to happen with newly plugged in devices. Unlocking a device that has been plugged in for a while appears to work as expected.
Disabling extensions has no effect. I can't see any obvious error messages in the journal related to this, only messages about the successful unlocking and mounting. The messages below do appear when tracker-miner-fs is running, but after killing the process they both disappear. The behavior stays the same either way.
sep 23 19:55:14 pachacuti tracker-miner-f: Could not set mount point in database 'urn:nepomuk:datasource:XXX', GDBus.Error:org.freedesktop.Tracker1.SparqlError.Internal: UNIQUE constraint failed: nie:DataObject.nie:url
sep 23 19:55:14 pachacuti gnome-shell: Error from MountOpReply2(): GDBus.Error:org.gtk.Private.RemoteVolumeMonitor.NotFound: No outstanding mount operation
I'm seeing the same issue on F29 [upgraded from F28]
If I enable 'save passwd' in the check box - the next time I plug-in an external drive - it gets auto-mounted [ without this dialog box - i.e no frozen gnome-shell]
Currently with gnome-shell-3.30.0-7.fc29.x86_64
This was reported upstream already:
I think we should at least consider this as a Final blocker, with reference to the criteria "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use" and its footnote, and "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test." It's arguable that 'desktop session gets irretrievably stuck if you attach an encrypted disk' violates at least the intent of those criteria.
(In reply to Satish Balay from comment #5)
> If I enable 'save passwd' in the check box - the next time I plug-in an
> external drive - it gets auto-mounted [ without this dialog box - i.e no
> frozen gnome-shell]
BTW: I don't know how to remove the saved passwd in the future (when this issue gets fixed). If anyone can point to the process or tool I should use to query/delete saved passwds - that would be great! Thanks!
I'm seeing this, the only way I can get rid of the dialog box is to go to a text tty and login as the user and do "killall -HUP gnome-shell" which, when in Xorg mode doesn't kill the entire session.
Proposed as a Freeze Exception for 29-final by Fedora user pbrobinson using the blocker tracking app because:
Encrypted removal media is completely unusable within Workstation and it locks up the session. Potentially SMB shares are also affected
As a work-around, lock your desktop before plugging in the drive. Then wait for a bit to make sure everything has had the time to initialize. After that you can unlock the disk using GNOME Disks (or maybe even nautilus).
It is better to simply disable automounting as a workaround:
Then you can use Nautilus, GNOME Disks, "gio mount -d [device]", cryptsetup...
Discussed during the 2018-10-08 blocker review meeting: 
The decision to classify this bug as an AcceptedBlocker was made:
"Accepted as a blocker under the "default panel functionality" and "application basic functionality test" criteria, per comment #6"
mutter-3.30.1-1.fc29 gnome-shell-extensions-3.30.1-1.fc29 gnome-shell-3.30.1-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-9e1f9f945d
gnome-shell-3.30.1-1.fc29, gnome-shell-extensions-3.30.1-1.fc29, mutter-3.30.1-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-9e1f9f945d
Can some of you who were affected by this please confirm whether this is now working fine with the updates mentioned above? Thanks.
(In reply to Kamil Páral from comment #15)
> Can some of you who were affected by this please confirm whether this is now
> working fine with the updates mentioned above? Thanks.
I did, I confirmed it in the karma comment when I provided karma. It still needs to go stable though.
Sorry, I forgot to check the Bodhi update comments. Marking as verified.
(In reply to Satish Balay from comment #7)
> BTW: I don't know how to remove the saved passwd in the future (when this
> issue gets fixed). If anyone can point to the process or tool I should use
> to query/delete saved passwds - that would be great! Thanks!
I figured this out.
- Run 'Passwords and Keys' - aka 'seahorse'
- switch 'View' to 'Show Any'
- Now the saved passphrase for the USB disk shows up in the 'Login' section - so it can be deleted
gnome-shell-3.30.1-1.fc29, gnome-shell-extensions-3.30.1-1.fc29, mutter-3.30.1-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.