Gsettings and dconf issues

I’m chrooting to our TX2’s L4T image based on # R32 (release), REVISION: 3.1 with qemu-aarch64 static. This allows reasonable control over the image and tweaking of settings that are stored in configuration files. However, I have a number of modifications that are gsettings and it’s not possible to update said settings since the system isn’t booted (dconf isn’t running). The Ubuntu documentation on dconf mentions that gsettings controlled variables can be set in a key file (a text file) placed in ‘/etc/dconf/db/database.d’. L4T doesn’t have a /db/database.d directory and the dconf database contained in the /db directory isn’t using any nomenclature I’ve seen from googling around. What is contained there is an ‘ibus’ database and an ‘ibus.d/’ directory. I’ve put my key file into the ibus.d/ directory next to another key file, ‘00-upstream-settings’. Additional googling has mentioned that both the ‘databasename.d/’ directory and the key file itself need to be touched (thus updating their modified date/time) before running ‘dconf update’ (by a script run at boot). This procedure runs without any complaints, but it also doesn’t make any of the changes included in the newly added key file.

The basic goal here is to be able to manipulate the image in place as opposed to taking a TX2, flashing it with the image, changing the settings while logged in then snapshotting the image again.

Any insight into why this process isn’t working?

I do not know enough to answer directly for gsettings, but if strace can be used (probably not installed by default, so that might be yet another difficulty), then you could run your command under strace to produce a log. The log would be fairly large, but you would be able to skim through it and find out what directories and files it is looking at. For example, if your normal command is:
sudo gsettings set org.gnome....
…then you could:

sudo -s
strace -oTraceLog.txt gsettings set org.gnome....
# Examine TraceLog.txt

Perhaps this would offer information about a directory location. Basically that log is a C-like way of describing system calls to the kernel.

Thanks, that’s good advice. It’s providing a bit more insight into what’s going on. Still no smoking gun though…

In my poking around I just nuked the ‘/home/user_name/.config/dconf/user’ file. Doing this got rid of the customized Nvidia wall paper and login screen (loaded up Ubuntu’s default user settings). Since that user dconf database was customized somehow one of you folks at Nvidia should be able to tell me how it was done.

If you have installed through SDKManager, there is a tool in


You may refer to it for replacing the boot logo.

1 Like

FYI, this deletes all keys when you delete that one file. You’d only need to change that single key. I found this:
gsettings list-recursively | less -i
…then searched for “nvidia”. I found this single entry:

org.gnome.desktop.background picture-uri 'file:///usr/share/backgrounds/NVIDIA_Wallpaper.jpg'

You could then be more specific:
gsettings list-keys org.gnome.desktop.background
…which shows one key is “picture-uri”.

There are also commands to set values, get values, or reset values.

There is also a GUI front end to this, “dconf-editor” ("sudo apt-get install dconf-editor").

1 Like

Thanks @linuxdev & @DaneLLL
The main issue that’s been surrounding this problem is that both ‘gsettings set’ and ‘dconf load’ are required to be run by the user account without sudo permissions. If either command is run as sudo it fails. The ways around this particularly pesky problem is to run ‘dbus-launch gsettings set’ which doesn’t fail when run with sudo privileges. My solution was to park all of those gsettings in an autostart script that sets them at login. Not a particularly great solution and inelegant but effective.

Interesting…I would think that once a single gsettings has set a value, then you would not have to repeat this each login unless something else is setting it back to some other value.

Dbus is itself rather restrictive for security reasons, but if you change how you use sudo, then you might still be able to use sudo. An example is probably the best way to explain. The following two commands both allow you to become user “root” in a shell if you are user “nvidia”, but the result is actually quite different:

sudo -s
sudo su -

When you use just sudo, then the system is set to mark this as an sudo session. When your argument terminates with a “-”, this becomes a full regular login session, and not an sudo shell. You have to become root to before sudo can be used to become another user, but if you are root (even as sudo), then you can use “su -” or “su - nvidia”. gsettings should always accept becoming user nvidia via:

sudo -s
su - nvidia

…and if dbus is involved, then this should usually fail:
sudo -s nvidia