Bug 975521

Summary: unable to change settings using dconf
Product: [Fedora] Fedora Reporter: Matus Marhefka <mmarhefk>
Component: dconfAssignee: Matthias Clasen <mclasen>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 19CC: awilliam, dan.mashal, dominick.grift, dwalsh, emmanuel.pacaud, esandeen, fedora, jbastian, kparal, mclasen, mgrepl, mmarhefk, pschindl, rhughes, robatino, rth, satellitgo, stefano, tflink, tomkarger, walters
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: AcceptedBlocker
Fixed In Version: glib2-2.36.3-2.fc19 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-06-23 06:25:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 834090    
Attachments:
Description Flags
journalctl -b
none
~/.config/dconf/user none

Description Matus Marhefka 2013-06-18 16:53:12 UTC
Created attachment 762551 [details]
journalctl -b

Description of problem:
After install of Fedora 19 TC5 from DVD, it is impossible to change
settings using dconf.
Related bug: https://bugzilla.gnome.org/show_bug.cgi?id=702574


Version-Release number of selected component (if applicable):
dconf-0.16.0-1.fc19.x86_64

How reproducible:


Steps to Reproduce:
1. Install Fedora 19 TC5 from DVD.
2. Try to remove icons from GNOME Shell favourites launcher or
   change background or any other changes requiring dconf.

Actual results:
dconf does not apply changes

Expected results:
dconf applies changes

Additional info:

Comment 1 Emmanuel Pacaud 2013-06-18 21:07:35 UTC
Hi,

I've tried to downgraded dconf to 0.15.3, but it didn't fix the issue.

Comment 2 Adam Williamson 2013-06-19 01:33:57 UTC
Proposing as a final blocker: "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in common use".

Comment 3 Dan Mashal 2013-06-19 02:06:52 UTC
You are using dconf-editor?

Comment 4 Adam Williamson 2013-06-19 02:15:31 UTC
I can't reproduce this on a simple install / boot installed system / try and reproduce / install updates / reboot / try and reproduce cycle on a live image, but it would be good to look into various recent reports of dconf issues more closely before dismissing this.

Comment 5 Adam Williamson 2013-06-19 02:16:14 UTC
dan: no, the bug seems to be that the user's dconf database gets corrupted somehow; after that, any action at all which requires updating the database will fail (and on the next boot, the user's settings will probably fail to load).

Comment 6 Dan Mashal 2013-06-19 02:27:40 UTC
We noticed this with MATE  when a user ran emcas as root, permissions in .config got screwed up. See IRC if you're around.

Comment 7 Dan Mashal 2013-06-19 02:33:57 UTC
Just noticed this on TC5 .xsession-errors:

(mate-settings-daemon:1273): dconf-WARNING **: failed to commit changes to dconf: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code17: Cannot open dconf database: invalid gvdb header

(mate-settings-daemon:1273): dconf-WARNING **: failed to commit changes to dconf: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code17: Cannot open dconf database: invalid gvdb header
** Message: applet now removed from the notification area

Comment 8 Emmanuel Pacaud 2013-06-19 05:49:31 UTC
(In reply to Adam Williamson from comment #5)
> dan: no, the bug seems to be that the user's dconf database gets corrupted
> somehow; after that, any action at all which requires updating the database
> will fail (and on the next boot, the user's settings will probably fail to
> load).

It happened to me after my latop got stuck, and I forced a power down using the hardware power button.

After the reboot, all my settings were lost, and can't be changed.

Comment 9 Dan Mashal 2013-06-19 06:14:01 UTC
I believe this is an SELinux / gvfs bug:

    Jun 18 20:14:11 Fedora19 kernel: [    9.834251] type=1400 audit(1371611643.411:4): avc:  denied  { relabelfrom } for  pid=281 comm="systemd-tmpfile" name="lock" dev="tmpfs" ino=13096 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:iscsi_lock_t:s0 tclass=file
    Jun 18 20:21:55 Fedora19 kernel: [   16.658571] type=1400 audit(1371612107.319:4): avc:  denied  { relabelfrom } for  pid=257 comm="systemd-tmpfile" name="lock" dev="tmpfs" ino=14133 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:iscsi_lock_t:s0 tclass=file
    Jun 18 20:36:30 Fedora19 systemd-tmpfiles[1993]: stat(/run/user/1000/gvfs) failed: Permission denied
    Jun 18 21:00:03 Fedora19 kernel: [   27.164783] type=1400 audit(1371614396.756:4): avc:  denied  { relabelfrom } for  pid=251 comm="systemd-tmpfile" name="lock" dev="tmpfs" ino=11761 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:iscsi_lock_t:s0 tclass=file
    Jun 18 21:14:29 Fedora19 systemd-tmpfiles[2509]: stat(/run/user/1001/gvfs) failed: Permission denied
    Jun 18 22:11:11 Fedora19 kernel: [  284.019727] type=1400 audit(1371618668.763:4): avc:  denied  { relabelfrom } for  pid=280 comm="systemd-tmpfile" name="lock" dev="tmpfs" ino=12797 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:iscsi_lock_t:s0 tclass=file
    Jun 18 22:21:24 Fedora19 systemd-tmpfiles[1426]: stat(/run/user/1001/gvfs) failed: Permission denied
    Jun 18 22:49:52 Fedora19 kernel: [   10.533060] type=1400 audit(1371620988.504:4): avc:  denied  { relabelfrom } for  pid=275 comm="systemd-tmpfile" name="lock" dev="tmpfs" ino=9028 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:iscsi_lock_t:s0 tclass=file
    Jun 18 23:04:38 Fedora19 systemd-tmpfiles[2112]: stat(/run/user/1000/gvfs) failed: Permission denied

Comment 10 Miroslav Grepl 2013-06-19 06:37:34 UTC
#============= systemd_tmpfiles_t ==============

#!!!! This avc is allowed in the current policy
allow systemd_tmpfiles_t iscsi_lock_t:file relabelfrom;


commit da84df01a4f2967a9766e496b0396f7578a7741a
Author: Miroslav Grepl <mgrepl>
Date:   Tue Jun 18 08:30:55 2013 +0200

    Allow systemd-tmpfiles to relabel also lock files

Comment 11 Dan Mashal 2013-06-19 06:38:50 UTC
Please advise on gvfs.

Comment 12 Adam Williamson 2013-06-19 06:54:01 UTC
Is the selinux issue really all there is to this, or could there be more?

Comment 13 Miroslav Grepl 2013-06-19 07:00:12 UTC
Well, it could be more. What does

# ls -lZ /run/user/1001/

Comment 14 Dan Mashal 2013-06-19 07:01:57 UTC
# ls -lZ /run/user/1001/
ls: cannot access /run/user/1001/gvfs: Permission denied
drwx------. dan2 dan2 unconfined_u:object_r:config_home_t:s0 dconf
?---------  ?    ?                                     gvfs
drwx------. dan2 dan2 unconfined_u:object_r:user_tmp_t:s0 keyring-0Pd395
drwx------. dan2 dan2 unconfined_u:object_r:user_tmp_t:s0 keyring-4obl7j
drwx------. dan2 dan2 unconfined_u:object_r:user_tmp_t:s0 pulse
lrwxrwxrwx. root root system_u:object_r:user_tmp_t:s0  X11-display -> /tmp/.X11-unix/X0

Comment 15 Miroslav Grepl 2013-06-19 07:59:33 UTC
Dan,
does it work in permissive mode?

Comment 16 Dan Mashal 2013-06-19 08:08:44 UTC
Yes permissive mode helps out big time. Instead of the 10 x-caja-desktop I was getting on first login I get one now. 

[root@Fedora19 dan3]# cat /var/log/messages |grep denied
Jun 18 20:14:11 Fedora19 kernel: [    9.834251] type=1400 audit(1371611643.411:4): avc:  denied  { relabelfrom } for  pid=281 comm="systemd-tmpfile" name="lock" dev="tmpfs" ino=13096 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:iscsi_lock_t:s0 tclass=file
Jun 18 20:21:55 Fedora19 kernel: [   16.658571] type=1400 audit(1371612107.319:4): avc:  denied  { relabelfrom } for  pid=257 comm="systemd-tmpfile" name="lock" dev="tmpfs" ino=14133 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:iscsi_lock_t:s0 tclass=file
Jun 18 20:36:30 Fedora19 systemd-tmpfiles[1993]: stat(/run/user/1000/gvfs) failed: Permission denied
Jun 18 21:00:03 Fedora19 kernel: [   27.164783] type=1400 audit(1371614396.756:4): avc:  denied  { relabelfrom } for  pid=251 comm="systemd-tmpfile" name="lock" dev="tmpfs" ino=11761 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:iscsi_lock_t:s0 tclass=file
Jun 18 21:14:29 Fedora19 systemd-tmpfiles[2509]: stat(/run/user/1001/gvfs) failed: Permission denied
Jun 18 22:11:11 Fedora19 kernel: [  284.019727] type=1400 audit(1371618668.763:4): avc:  denied  { relabelfrom } for  pid=280 comm="systemd-tmpfile" name="lock" dev="tmpfs" ino=12797 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:iscsi_lock_t:s0 tclass=file
Jun 18 22:21:24 Fedora19 systemd-tmpfiles[1426]: stat(/run/user/1001/gvfs) failed: Permission denied
Jun 18 22:49:52 Fedora19 kernel: [   10.533060] type=1400 audit(1371620988.504:4): avc:  denied  { relabelfrom } for  pid=275 comm="systemd-tmpfile" name="lock" dev="tmpfs" ino=9028 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:iscsi_lock_t:s0 tclass=file
Jun 18 23:04:38 Fedora19 systemd-tmpfiles[2112]: stat(/run/user/1000/gvfs) failed: Permission denied
Jun 19 01:01:34 Fedora19 kernel: [    6.529689] type=1400 audit(1371628888.856:3): avc:  denied  { relabelfrom } for  pid=253 comm="systemd-tmpfile" name="lock" dev="tmpfs" ino=10621 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:iscsi_lock_t:s0 tclass=file
Jun 19 01:01:34 Fedora19 kernel: [    6.529689] type=1400 audit(1371628888.856:4): avc:  denied  { relabelto } for  pid=253 comm="systemd-tmpfile" name="lock" dev="tmpfs" ino=10621 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:iscsi_lock_t:s0 tclass=file
[root@Fedora19 dan3]# cat .xsession-errors 
touch: cannot touch ‘/home/dan3/.cache/imsettings/log’: No such file or directory

** (abrt:1660): WARNING **: Couldn't register with accessibility bus: 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.

** (nm-applet:1676): WARNING **: Couldn't register with accessibility bus: 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.
vmware-user: could not open /proc/fs/vmblock/dev
W: [pulseaudio] authkey.c: Failed to open cookie file '/home/dan3/.config/pulse/cookie': No such file or directory
W: [pulseaudio] authkey.c: Failed to load authorization key '/home/dan3/.config/pulse/cookie': No such file or directory
W: [pulseaudio] authkey.c: Failed to open cookie file '/home/dan3/.pulse-cookie': No such file or directory
W: [pulseaudio] authkey.c: Failed to load authorization key '/home/dan3/.pulse-cookie': No such file or directory
abrt-applet: Can't access '/var/tmp/abrt/ccpp-2013-06-18-22:23:06-1336': Permission denied

** (nm-applet:1676): WARNING **: Can't load fallback CSS resource: Failed to import: The resource at '/org/gnome/adwaita/gtk-fallback.css' does not exist

** (nm-applet:1676): WARNING **: Can't load fallback CSS resource: Failed to import: The resource at '/org/gnome/adwaita/gtk-fallback.css' does not exist

** (mate-power-manager:1662): WARNING **: levels is 0!

** (abrt:1660): WARNING **: Can't load fallback CSS resource: Failed to import: The resource at '/org/gnome/adwaita/gtk-fallback.css' does not exist

** (abrt:1660): WARNING **: Can't load fallback CSS resource: Failed to import: The resource at '/org/gnome/adwaita/gtk-fallback.css' does not exist

** (caja:1677): WARNING **: Failed to get the current CK session: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ConsoleKit was not provided by any .service files
** Message: applet now removed from the notification area
** Message: applet now embedded in the notification area

Comment 18 Dan Mashal 2013-06-19 08:33:14 UTC
Turned on enforcing and seems to be showing 0 denials now. Will do a clean install tomorrow and test with this policy.

Thanks Miroslav!!!!

Comment 19 Petr Schindler 2013-06-19 10:34:12 UTC
Hi,

I have this problem too. I can't change any settings in GNOME. Also the processes tracker-miner-fs and dconf-service take about 250-300% of processor time (on 4 cores). Also systemd-journal and dbus-daemon takes about 50%.

I've updated lot of things yesterday, but this happens after second restart (after update I restarted immediately and no problem occure). gvfs was in updates.

I'm +1 for blocker, because system with this bug is quite unusable.

Comment 20 Miroslav Grepl 2013-06-19 12:02:12 UTC
Do we have more bugs in this bug?

Petr,
is your problem SELinux issue?

Comment 21 Kamil Páral 2013-06-19 12:50:27 UTC
I talked to Petr before and he said permissive selinux hadn't helped.

I'm a bit confused, could SELinux really cause dbus errors as in comment 7 and the upstream reports, like this?

(mate-settings-daemon:1273): dconf-WARNING **: failed to commit changes to dconf: > GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code17: Cannot open dconf database: invalid gvdb header

I tried to do a clean F19 TC5 DVD installation and haven't seen this issue, so it really looks like a dconf database corruption that happens just sometimes.

Maybe we should have two separate bugs, one for selinux and one for dbus?

Comment 22 Adam Williamson 2013-06-19 15:26:39 UTC
Yeah, that's what I meant with c#12, I'm worried Dan hijacked the bug for a different problem.

Comment 23 Dan Mashal 2013-06-19 17:22:53 UTC
There are 2 bugs, yes. I thought that fixing the SElinux ones might help. And it seems that they did, but we should file a separate bug on dbus I guess.

Comment 24 Adam Williamson 2013-06-19 17:26:37 UTC
The OP's journalctl output does have a line:

Jun 18 12:23:46 localhost.localdomain systemd-tmpfiles[2038]: stat(/run/user/1000/gvfs) failed: Permission denied

But that's well *after* the first dconf error:

Jun 18 12:10:15 localhost.localdomain /etc/gdm/Xsession[1174]: (gnome-settings-daemon:1354): dconf-WARNING **: failed to commit changes to dconf: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code17: Cannot open dconf database: invalid gvdb header

That error appears to happen just one second after the user logs in:

Jun 18 12:10:14 localhost.localdomain gdm-password][1162]: pam_unix(gdm-password:session): session opened for user matt by (unknown)(uid=0)

Right after user login, a Bunch Of Stuff happens:

Jun 18 12:10:14 localhost.localdomain /usr/bin/dbus-launch[960]: g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.
Jun 18 12:10:14 localhost.localdomain /usr/bin/dbus-launch[960]: ** (gnome-settings-daemon:985): WARNING **: Name taken or bus went away - shutting down
Jun 18 12:10:14 localhost.localdomain /usr/bin/dbus-launch[960]: (gnome-settings-daemon:985): GLib-GIO-WARNING **: Error releasing name org.gnome.SettingsDaemon.Power: The connection is closed
Jun 18 12:10:14 localhost.localdomain gdm-launch-environment][952]: pam_unix(gdm-launch-environment:session): session closed for user gdm
Jun 18 12:10:14 localhost.localdomain /usr/bin/dbus-launch[960]: (gnome-settings-daemon:985): GLib-GIO-WARNING **: Error releasing name org.gnome.SettingsDaemon.XRANDR: The connection is closed
Jun 18 12:10:14 localhost.localdomain /usr/bin/dbus-launch[960]: (gnome-settings-daemon:985): GLib-GIO-WARNING **: Error releasing name org.gnome.SettingsDaemon.Keyboard: The connection is closed
Jun 18 12:10:14 localhost.localdomain polkitd[478]: Unregistered Authentication Agent for unix-session:c1 (system bus name :1.31, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
Jun 18 12:10:14 localhost.localdomain /usr/bin/dbus-launch[960]: g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.

which seems odd.

Overall we're fairly sure the selinux stuff was a hijack, so sending this back to dconf for now. We still want the selinux fix, obviously, but it's really not this bug; perhaps a new one should be opened.

Comment 25 Adam Williamson 2013-06-19 17:29:46 UTC
Dan: you should file a new bug for selinux-policy, as this one was filed against dconf in the first place and you hijacked it.

Comment 26 Adam Williamson 2013-06-19 17:36:19 UTC
Did who's been affected by the 'corrupted file' version of this bug *not* see it after an unclean shutdown/restart?

Comment 27 Adam Williamson 2013-06-19 17:39:00 UTC
In particular, Matus, was there an unclean shutdown/restart in your test that you didn't mention? Or was this really a straightforward 'install F19, run g-i-s, now dconf is broken'?

Comment 28 Adam Williamson 2013-06-19 17:40:55 UTC
Matus: if you still have the affected VM and you didn't 'fix' it, I suspect we'd very much like you to attach the ~/.config/dconf/user file.

Comment 29 Adam Williamson 2013-06-19 17:47:54 UTC
Discussed at 2013-06-19 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-19/f19final-blocker-review-7.2013-06-19-16.01.log.txt . We agreed to delay the decision on this until we're clearer on the causes here.

So far the desktop team is at least confident that the dconf database seems to be getting overwritten with all zeroes on unclean shutdown fairly often, and is inclined to blame this on some kind of kernel change. There has been some discussion about whether dconf can mitigate this by backing the database up periodically and restoring the last backup if the 'active' file gets zapped. We are not sure if there is some further issue that can cause problems with the database even without any kind of unclean shutdown.

Comment 30 Adam Williamson 2013-06-19 17:49:56 UTC
Eric, can you comment if there have been any recent kernel changes which may explain why we're suddenly seeing the dconf database (which is just a file, ~/.config/dconf/user ) get overwritten with all zeroes on unclean shutdowns? Some discussion from #fedora-desktop:

<desrt> mjg59: do you actually have a corrupted db?
 so far the only thing people have been able to provide me with are size-zero files and files filled with zeros
<mjg59> Yeah, it's a (large) empty file
<desrt> sigh
<mjg59> Perhaps you have some more fine-grained definition of corrupt
<desrt> what filesystem, and are you using any weird block-layer stuff (lvm, luks, etc)?
<mjg59> ext4, no
<desrt> so afaik, replace-by-rename is supposed to be a 'safe' operation on ext4, even across crashes/power-loss
<mjg59> Ted probably broke it again
 But I'd gladly blame Ted for basically anything, so you shouldn't base any behaviour on my feelings here
<desrt> ya.... the fact that we suddenly get all of these reports after no recent changes in dconf sort of points at changing kernel behaviour...
<adamw> mjg59: yup, that's pretty much what happened to me

Comment 31 Dan Mashal 2013-06-19 18:12:39 UTC
OK, if I do a reset on my VM I can reproduce the dconf corruption:

(mate-panel:1226): dconf-WARNING **: failed to commit changes to dconf: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code17: Cannot open dconf database: invalid gvdb header

(mate-panel:1226): dconf-WARNING **: failed to commit changes to dconf: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code17: Cannot open dconf database: invalid gvdb header

(mate-panel:1226): dconf-WARNING **: failed to commit changes to dconf: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code17: Cannot open dconf database: invalid gvdb header

And yes .config/dconf/user is filled with junk.

Comment 32 Tim Flink 2013-06-19 22:25:43 UTC
I did an install with the F19 TC5 live desktop x86_64 to a VM with two vdisks in RAID1. I had no problems changing dconf settings before forcing an unclean shutdown.

After doing the unclean shutdown, I can't change my desktop and any changes I make to the overview's favourites are not persistent across reboot.

.config/dconf/user is full of junk on this VM, all of a sudden, I keep getting crashes in tracker-miner which abrt is identifying as https://bugzilla.redhat.com/show_bug.cgi?id=975687

There are several log messages of the form:

Jun 19 18:21:19 localhost /etc/gdm/Xsession[1165]: (tracker-miner-fs:1370): dconf-WARNING **: failed to commit changes to dconf: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code17: Cannot open dconf database: invalid gvdb header

Comment 33 Adam Williamson 2013-06-20 02:56:29 UTC
Yes, as mentioned above we're already pretty clear there's an issue with the file getting nerfed across unclean shutdowns. What's not quite certain at this point is whether there's a cause which doesn't involve an unclean shutdown.

Comment 35 Colin Walters 2013-06-20 21:03:19 UTC
Fixed upstream, backported the patch, F19 candidate build started here:

http://koji.fedoraproject.org/koji/taskinfo?taskID=5525795

Comment 36 Fedora Update System 2013-06-20 21:21:30 UTC
glib2-2.36.3-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/glib2-2.36.3-2.fc19

Comment 37 Adam Williamson 2013-06-21 01:52:06 UTC
Discussed at 2013-06-20 blocker: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-20/f19final-blocker-review-7.1.2013-06-20-15.01.html . Accepted as a blocker per criterion "All known bugs that can cause corruption of user data must be fixed or documented at Common F19 bugs".

This seems to be solidifying around 'it suddenly got much more likely that dconf database would get nerfed on an unclean shutdown'. Let's say this bug covers that. If we find some other cause, we'd better track that in another bug.

Comment 38 Matus Marhefka 2013-06-21 08:27:36 UTC
Created attachment 763701 [details]
~/.config/dconf/user

Comment 39 Matus Marhefka 2013-06-21 08:29:32 UTC
~/.config/dconf/user contains only junk.

Comment 40 Adam Williamson 2013-06-21 19:10:35 UTC
Can those who are able to reproduce this easily please test with https://admin.fedoraproject.org/updates/glib2-2.36.3-2.fc19 and confirm the fix? Thanks!

Comment 41 Fedora Update System 2013-06-21 19:16:05 UTC
Package glib2-2.36.3-2.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing glib2-2.36.3-2.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-11439/glib2-2.36.3-2.fc19
then log in and leave karma (feedback).

Comment 42 Adam Williamson 2013-06-21 22:53:56 UTC
OK, I verified this myself - did a TC5 live install, twiddled with a couple of dconf settings, forced a shut down of the VM, booted it up, and the problem was reproduced. Did the same thing with a live image I built with glib2-2.36.3-2 included, and it survived the hard shutdown/reboot OK. So setting VERIFIED.

Comment 43 Fedora Update System 2013-06-23 06:25:29 UTC
glib2-2.36.3-2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 44 Jeff Bastian 2013-06-25 13:11:30 UTC
*** Bug 975523 has been marked as a duplicate of this bug. ***

Comment 45 Jeff Bastian 2013-06-25 13:12:27 UTC
Just a note, even updating the glib2 package didn't fix it for me.  I had to start with a fresh ~/.config/dconf/user database.  Mine was full of null bytes:

~]$ od ~/.config/dconf/user
0000000 000000 000000 000000 000000 000000 000000 000000 000000
*
0077300 000000
0077302

Comment 46 Kamil Páral 2013-06-25 13:41:02 UTC
Jeff, AFAIU, the new glib2 package should prevent this problem from happening, but doesn't fix the corrupted database if it already happened to you. You need to remove the file in this case, yes.

Comment 47 Tomas Karger 2013-08-17 21:46:17 UTC
I'm experiencing this bug on fully updated F19 right now. I did an unclean shutdown and the ~/.config/dconf/user database is corrupted. When I delete it and make changes using dconf-editor, even the database that appears right away is corrupted. So the changes only persist on the session they were made on. Logging out returns everything to default. 
I have glib2-2.36.3-3.fc19.x86_64.

Comment 48 Tomas Karger 2013-08-17 22:15:14 UTC
Sorry for the false alarm! I tried to test some other settings and they persist just fine. Also, I guess I tried to open the dconf database the wrong way and so I thought it is corrupt. Nevertheless, when I disable animations in org.gnome.desktop.interface.enable-animations - this does not persist. But it is probably not related to this bug.