I updated to virt-manager-0.6.1-1.fc10 from updates-testing. Attempting to start virt-manager now dies with the following dialog box: Error starting Virtual Machine Manager: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://www.gnome.org/projects/gconf/ for information. (Details - 1: Failed to get connection to session: 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.) Traceback (most recent call last): File "/usr/share/virt-manager/virt-manager.py", line 368, in <module> main() File "/usr/share/virt-manager/virt-manager.py", line 299, in main icon_dir, data_dir) File "/usr/share/virt-manager/virtManager/config.py", line 51, in __init__ gconf.CLIENT_PRELOAD_NONE) GError: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://www.gnome.org/projects/gconf/ for information. (Details - 1: Failed to get connection to session: 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.) I reverted to virt-manager-0.6.0-5.fc10.x86_64 from updates, which works fine. Versions of all *virt* packages: 0:libvirt-0.6.1-1.fc10.x86_64 0:libvirt-python-0.6.1-1.fc10.x86_64 0:python-virtinst-0.400.2-1.fc10.noarch 0:virt-manager-0.6.0-5.fc10.x86_64 0:virt-top-1.0.3-2.fc10.x86_64 0:virt-viewer-0.0.3-3.fc10.x86_64
Thanks for testing this. With the older version, assuming you start running as a regular user, are you entering root credentials when the app starts or are you click 'Run Unprivileged'? Anything interesting with your setup? NFS home dir, running over ssh. Can you try running from the command line, see if it helps, possibly trying the --no-fork flag?
As far as I can tell, virt-manager-0.6.1-1.fc10 only fails to launch if I launch it from a root terminal. Adding --no-fork doesn't help. It works fine it I launch it via a regular account, either via the command line, or by picking it off of the GNOME menu. Both authenticating and running unprivileged work fine.
As asked in Comment #1, how were you launching virt-manager with the older version? With the new version, are you using sudo, su, or su -? Do you have NFS home directories or anything like that? Is there any reason why root wouldn't have access to files in your home directory?
I launch all versions of virt-manager the same way: from a root shell that I open via "su". I am not using NFS home directories. I can think of no reason why root wouldn't have access to files in my home directory.
Hmm, really not sure what the issue is. The only thing that changed that would effect this is dropping ConsoleHelper (the 'Run Unprivileged') dialog. I would think that launching virt-manager as root in both cases wouldn't yield any difference. Sorry for the pestering, but does running 'su -' as opposed to just plain 'su' make any difference?
I just tested that, and yes, it does; virt-manager-0.6.1-1.fc10 launches properly if I su to root via "su -" instead of just "su".
Hmm, looks like this is an example of: https://bugzilla.redhat.com/show_bug.cgi?id=474523
Yeah, that's it. The weird thing is, though: why did dropping ConsoleHelper trigger this problem, when previous versions ran just fine? (Feel free to close this as a dupe of bug 474523.)
ConsoleHelper probably sees if the app is launched by the root user, and makes sure that everything is run from root's environment. This prevents issues like 'su virt-manager' creating root owned log files in the original users HOME, which can understandably cause issues. Closing as dup of bug 474523. *** This bug has been marked as a duplicate of bug 474523 ***
I had this issue before, I worked around it by removing the gconf from home directory of the user with this issue, and it worked mv ~/.gconf ~/.gconf.old mv ~/.gconfd ~/.gconfd.old