Description of problem: Installing and running virt-manager on a beaker provisioned test system in the lab results in a spectacular D-BUS error & python backtrace, when trying to install a RHEL6 guest. Presumably this is due to virt-manager depending on some package from the GNOME Desktop group, without the RPM containing a dependency. Version-Release number of selected component (if applicable): virt-manager-0.9.5-1.fc18.noarch Steps to Reproduce: 1. reserve a system in Beaker, provision with Fedora 18 2. install virt-manager 3. try to install a guest Actual results: Uncaught error validating install parameters: Configuration server couldn't be contacted: D-BUS error: Unable to store a value at key '/apps/virt-manager/urls/media', as the configuration server has no writable databases. There are some common causes of this problem: 1) your configuration path file /etc/gconf/2/path doesn't contain any databases or wasn't found 2) somehow we mistakenly created two gconfd processes 3) your operating system is misconfigured so NFS file locking doesn't work in your home directory or 4) your NFS client machine crashed and didn't properly notify the server on reboot that file locks should be dropped. If you have two gconfd processes (or had two at the time the second was launched), logging out, killing all copies of gconfd, and logging back in may help. If you have stale locks, remove ~/.gconf*/*lock. Perhaps the problem is that you attempted to use GConf from two machines at once, and ORBit still has its default configuration that prevents remote CORBA connections - put "ORBIIOPIPv4=1" in /etc/orbitrc. As always, check the user.* syslog for details on problems gconfd encountered. There can only be one gconfd per home directory, and it must own a lockfile in ~/.gconfd and also lockfiles in individual storage locations such as ~/.gconf Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/create.py", line 1491, in validate return self.validate_install_page(oldguest=oldguest) File "/usr/share/virt-manager/virtManager/create.py", line 1643, in validate_install_page self.get_config_url_info(store_media=True) File "/usr/share/virt-manager/virtManager/create.py", line 1000, in get_config_url_info self.config.add_media_url(media) File "/usr/share/virt-manager/virtManager/config.py", line 564, in add_media_url self._url_add_helper(self.conf_dir + "/urls/media", url) File "/usr/share/virt-manager/virtManager/config.py", line 561, in _url_add_helper self.conf.set_list(gconf_path, gconf.VALUE_STRING, urls) GError: Configuration server couldn't be contacted: D-BUS error: Unable to store a value at key '/apps/virt-manager/urls/media', as the configuration server has no writable databases. There are some common causes of this problem: 1) your configuration path file /etc/gconf/2/path doesn't contain any databases or wasn't found 2) somehow we mistakenly created two gconfd processes 3) your operating system is misconfigured so NFS file locking doesn't work in your home directory or 4) your NFS client machine crashed and didn't properly notify the server on reboot that file locks should be dropped. If you have two gconfd processes (or had two at the time the second was launched), logging out, killing all copies of gconfd, and logging back in may help. If you have stale locks, remove ~/.gconf*/*lock. Perhaps the problem is that you attempted to use GConf from two machines at once, and ORBit still has its default configuration that prevents remote CORBA connections - put "ORBIIOPIPv4=1" in /etc/orbitrc. As always, check the user.* syslog for details on problems gconfd encountered. There can only be one gconfd per home directory, and it must own a lockfile in ~/.gconfd and also lockfiles in individual storage locations such as ~/.gconf Expected results: Required dependencies are installed when typing "yum install virt-manager", and things work :)
Hmm, this sounds like it's entirely gconf. Maybe dbus isn't autostarted or gconf is missing a dep (virt-manager does depend on GConf2). Reassigning
I managed to resolve this error by creating the "/root/.config" directory. I then logged out and back in as root and the error went away. I believe the issue is that gconf will create $USERCONFIGDIR/gconf but won't recursively create the $USERCONFIGDIR. $USERCONFIGDIR seems to default to "~/.config". My guess is when you install a full blown FC 18 Desktop something else creates this. I do agree there are some dependencies missing for virt-manager to operate correctly. In order to get virt-manager to work via remote x11 I had to install the following additional packages on my test system (Installed without Desktop GUI): xauth PackageKit-gtk3-module libcanberra-gtk3 libcanberra-devel xorg-x11-fonts* libvirt-daemon-kvm Hope this helps, James.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.