On Mon, 28 Dec 2009 19:52:06 +0100, solarg <solarg at laposte.net> wrote: > solarg wrote: >> >> On 12/28/09 04:06 PM, Brian Cameron wrote: >> >>> So, to change the background image, you should run these commands: >>> >>> $ su - >>> $ su - gdm >>> $ gconftool-2 --direct --config-source >>> xml:readwrite:/var/lib/gdm/.gconf.mandatory -t string -s >>> /desktop/gnome/background/picture_filename >>> /usr/share/pixmaps/backgrounds/opensolaris/stream.jpg >>> >>> I added the above example to the manpage. Currently the gdm manpage >>> only documents configuration options that it introduces. However, >>> this gnome-settings-daemon GConf key is likely one that users will >>> want to change, so its good to document it. >>> >> >> unfortunately not for me: >> gdm at tara:~$ gconftool-2 --direct --config-source >> xml:readwrite:/var/lib/gdm/.gconf.mandatory -t string -s >> /desktop/gnome/background/picture_filename >> /usr/share/pixmaps/backgrounds/stream.jpg >> >> (gconftool-2:10971): GConf-WARNING **: None of the resolved addresses >> are writable; saving configuration settings will not be possible >> Error setting value: Unable to store a value at key >> '/desktop/gnome/background/picture_filename', 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 >> >> i tried to do a cleanup, with gnome-cleanup, but without success. >> gdm at tara:~$ ps -ef|grep gco >> henry 10786 1 0 19:02:47 ? 0:00 /usr/lib/gconfd-2 >> root 7476 1 0 Dec 26 ? 0:00 /usr/lib/gconfd-2 >> root 7578 1 0 Dec 26 ? 0:00 /usr/lib/gconfd-2 >> >> does the problem related to my laptop, where i often suspend-resume the >> os? >> Er that's quite a huge leap of logic, suspend/resume doesn't have much to do with application behaviour. You had stray gconfd-2 processes running as root which means you accidentally ran something earlier as root, you should have killed those and fixed any directories they may have touched. If you read gconftool-2 --help: --direct Bypass server, and access the configuration database directly. Requires that gconfd is not running. It's possible that a running gconfd-2 process was preventing --direct from working; the is is also hinted in the long error message you got. > > ok, after rebooting, it works, does it mean that there is a problem with > gconf and suspend-resume? does it worth to open a bug? > but, and that's more important, even after the reboot, and the command > saying that i successfully changed the desktop background, greeter > continues to display the same original background: > gdm at tara:~$ gconftool-2 --get > /desktop/gnome/background/picture_filename > /export/home/henry/MonTheme/screenshot.png You need --direct again to read from the database since that's what you wrote the configuration to, or restart gconfd-2 and try again. > > gerard > -Albert
