Hide Forgot
Description of problem: 1-run virt-manager or gnome-boxes (import from system broker). 2-press on Cancel in polkit window. 3-restart virt-manager or try connect to qemu:///system Connection . 4-polkit window fail to launch. Error: Unable to connect to libvirt qemu:///system. error from service: CheckAuthorization: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Libvirt URI is: qemu:///system Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/connection.py", line 1036, in _do_open self._backend.open(self._do_creds_password) File "/usr/share/virt-manager/virtinst/connection.py", line 144, in open open_flags) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 105, in openAuth if ret is None:raise libvirtError('virConnectOpenAuth() failed') libvirtError: error from service: CheckAuthorization: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Version-Release number of selected component (if applicable): virt-manager-1.5.1-1.fc28.noarch virt-manager-common-1.5.1-1.fc28.noarch gnome-boxes-3.28.2-1.fc28.x86_64 libvirt-daemon-driver-storage-scsi-4.1.0-2.fc28.x86_64 libvirt-daemon-driver-storage-logical-4.1.0-2.fc28.x86_64 libvirt-daemon-driver-storage-core-4.1.0-2.fc28.x86_64 libvirt-glib-1.0.0-5.fc28.x86_64 python2-libvirt-4.1.0-1.fc28.x86_64 libvirt-daemon-driver-storage-4.1.0-2.fc28.x86_64 libvirt-daemon-4.1.0-2.fc28.x86_64 libvirt-daemon-driver-storage-iscsi-4.1.0-2.fc28.x86_64 libvirt-daemon-kvm-4.1.0-2.fc28.x86_64 libvirt-daemon-driver-nodedev-4.1.0-2.fc28.x86_64 libvirt-daemon-driver-qemu-4.1.0-2.fc28.x86_64 libvirt-daemon-driver-storage-sheepdog-4.1.0-2.fc28.x86_64 libvirt-gobject-1.0.0-5.fc28.x86_64 libvirt-bash-completion-4.1.0-2.fc28.x86_64 libvirt-daemon-driver-storage-disk-4.1.0-2.fc28.x86_64 libvirt-daemon-driver-storage-zfs-4.1.0-2.fc28.x86_64 libvirt-daemon-driver-network-4.1.0-2.fc28.x86_64 libvirt-daemon-config-network-4.1.0-2.fc28.x86_64 libvirt-daemon-driver-storage-rbd-4.1.0-2.fc28.x86_64 libvirt-libs-4.1.0-2.fc28.x86_64 libvirt-daemon-driver-nwfilter-4.1.0-2.fc28.x86_64 libvirt-client-4.1.0-2.fc28.x86_64 libvirt-daemon-driver-interface-4.1.0-2.fc28.x86_64 libvirt-daemon-driver-storage-mpath-4.1.0-2.fc28.x86_64 libvirt-daemon-driver-secret-4.1.0-2.fc28.x86_64 libvirt-gconfig-1.0.0-5.fc28.x86_64 libvirt-daemon-driver-storage-gluster-4.1.0-2.fc28.x86_64 polkit-pkla-compat-0.1-12.fc28.x86_64 polkit-libs-0.114-1.fc28.x86_64 polkit-0.114-1.fc28.x86_64 dbus-1.12.0-1.fc28.x86_64
I tried with virt-manager, seems to work fine for me. I'm using gnome-shell, and my user is an admin so it's only asking for user password, not root. What desktop env are you using?
(In reply to Cole Robinson from comment #1) > I tried with virt-manager, seems to work fine for me. I'm using gnome-shell, > and my user is an admin so it's only asking for user password, not root. > > What desktop env are you using? gnome shell on wayland (fedora 28 workstation 64bit) my user is an admin to .
Okay I managed to reproduce. It's not virt specific. This is with up to date f28, gnome-shell, X session, though user reports wayland as well. User is an admin Simplify open the control center users panel, click Unlock, polkit dialog pops up asking for user password, click cancel. Click unlock again, nothing happens. Other polkit using apps have the same issue: firewall-config just freezes, system-config-print Unlock doesn't do anything. virsh --connect qemu:///system will hang and eventually report the CheckAuthorization timeout error. Looks like this is a gnome-shell issue, since alt+f2 'r' will get out of this state. I did try downgrading f28 polkit to the latest 113 version build and it didn't fix the issue. Reassigning to gnome-shell
Proposing as a freeze exception since this issue is pretty gnarly and can break a bunch of apps
To clarify: once it's in the 'broken' state, is it broken for *all* apps? Or is this a per-app thing - if you cancel for virt-manager, future virt-manager dialogs fail, but future dialogs from other apps still work, etc?
Breaking it in one app breaks it in all apps. I'm also interested to know if it reproduces this reliably for other people... it didn't trigger for me on my first attempt but today it's happening 100% for me across multiple reboots
Just tried it on my main desktop (which runs 28), reproduced first time for me.
I think we should also at least consider this as a blocker, criteria to consider are "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use" (as you can get to at least Users and maybe other affected things through the panel) 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" (configuring the firewall is pretty 'basic functionality' for firewall-config, creating users is 'basic functionality' for Users, etc.)
<halfline> adamw: we already have a fix for that gnome-shell upstream <adamw> well, that's good news <adamw> can someone backport it sharpish? :P <halfline> sure i can do it right now <adamw> what's the commit? <halfline> it's gnome-shell bug <halfline> one sec <mcatanzaro> https://gitlab.gnome.org/GNOME/gnome-shell/commit/7c9dbc66d9ab1f3adad29c827fac2d7d3ee05fae.patch <halfline> yup
I'm definitely +1 FE for this, having reproduced it and seen the upstream report and fix, which is pretty clear and simple.
+1 blocker
I guess +1 blocker.
+1 Blocker
That's enough votes to accept as blocker at least for now (if we changed our minds we could always re-vote at go/no-go, if the fix somehow doesn't work or causes problems).
+1 blocker, +1 FE
gnome-shell-3.28.1-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-4d7b3e68ad
gnome-shell-3.28.1-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.
thank you all, the problem was resolved in gnome-shell-3.28.1-2.fc28