Eu executo o Ubuntu 12.04.1 LTS x64 no VirtualBox. Depois de um clique errado muito infeliz (redefinir o estado salvo em vez de carregar o estado salvo), tive um problema muito chato.
Quase todos os aplicativos (unity, synaptic, gedit, etc.) são impressos no início:
Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications.
E todas as configurações da GUI são redefinidas após a reinicialização.
Outro sintoma:
$ GSETTINGS_BACKEND=dconf dconf-editor
(dconf-editor:2353): GLib-GIO-WARNING **: Can't find module 'dconf' specified in GSETTINGS_BACKEND
GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications
Mas /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
está presente.
O que eu tentei (e não ajudou):
sudo apt-get install -f --reinstall dconf-tools libdconf0 libdconf-dbus-1-0 dconf-service
- Construa o dconf-0.5 a partir dos fontes e
make install
ele - Crie um perfil de usuário vazio e inicie programas lá
Eu tenho que manter a instalação atual do Ubuntu, então uma reinstalação completa não é uma opção para mim.
Como posso consertar isso?
Responder1
Isso também pode acontecer se você tiver PATH
conflitos com um gerenciador de ambiente Python como o Anaconda.
Certifique-se de correr which gsettings
antes de ir muito fundo. Se isso não for impresso e, em vez disso , /usr/bin/gsettings
algo como /home/{username}/anaconda3/bin/gsettings
você provavelmente tiver algo .profile
// como: .bashrc
.zshrc
export PATH=$HOME/anaconda3/bin:$PATH
Altere para:
export PATH=$PATH:$HOME/anaconda3/bin
Aplicativoterminando em vez depréprestar atenção à PATH
variável resolverá seu problema, mas esteja ciente de que qualquer coisa em seu sistema bin
ou em outros PATH
locais substituirá seu arquivo anaconda3/bin
.
Outra opção seria alias /usr/bin/gsettings
:
alias sys-gsettings=/usr/bin/gsettings
sys-gsettings get org.gnome.todo view
Responder2
Eu encontrei a solução. Parece que obtive várias bibliotecas personalizadas /usr/local/lib
nessas bibliotecas de sistema "ocultas" do /usr/lib/x86_64-linux-gnu/
.
Eu descobri isso verificando bibliotecas dinâmicas carregadas por libdconfsettings.so
:
ldd /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
...
< several dynamic libraries from /usr/local/lib >
...
Isso aconteceu por causa da ordem dos caminhos de busca das bibliotecas dinâmicas (definida em /etc/ld.so.conf.d/
). A ordem foi a seguinte:
- /lib/i386-linux-gnu
- /usr/lib/i386-linux-gnu
- /lib/i686-linux-gnu
- /usr/lib/i686-linux-gnu
- /usr/local/lib
- /lib/x86_64-linux-gnu
- /usr/lib/x86_64-linux-gnu
Então, se por exemplo você colocar o seu próprio libc.so
arquivo, /usr/local/lib
ele será carregado em vez do padrão libc.so
from /lib/x86_64-linux-gnu
.
O conserto:
sudo mv /etc/ld.so.conf.d/libc.conf /etc/ld.so.conf.d/xuserlocal.conf
sudo ldconfig
sudo reboot
Responder3
Primeiro verifique se este comando retorna true
:
gsettings writable com.canonical.Unity.Launcher favorites
Caso contrário, instale o back-end com:
sudo apt-get install dconf-gsettings-backend
Se isso também não ajudar, redefina seu perfil com:
rm -rf ~/.gnome ~/.gnome2 ~/.gconf ~/.gconfd ~/.metacity .config/dconf/*
Depois reinicie.
Responder4
Eu experimentei a mesma coisa no Debian Jessie. Mas a solução do questionador (ele falhou) foi adequada para o meu caso:
sudo apt-get install -f --reinstall dconf-tools libdconf0 libdconf-dbus-1-0 dconf-service
Esse problema estava me matando, mas você salvou minha vida, obrigado :D