Package install fails with gconf-backends assertion

[Richard Theil]

I have been following dapper with regular (roughly daily) updates; I can't recall having done anything strange to the packaging system or the gconf setup, and so far it worked well. Out of a sudden, "capplets-data" refused to install, causing dependencies like "gnome-control-center" to fail as well. The installation returns with an error code 250 after an assertion in some gconf backend triggers.

IIRC, the error occured with 2.14.1-0ubuntu3_all.deb, but going back to 2.14.1-0ubuntu2_all.deb by means of a manual dpkg install didn't help either. It looks like some installation script wants to deal with gconf data and is unhappy with the state of some setup (so this might actually not be a problem of capplets, but of gconf).

Sorry for the german output (but you should get the idea anyway):

root@neon:/home/rich# apt-get install capplets-data

Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut... Fertig
capplets-data ist schon die neueste Version.
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 1 nicht aktualisiert.
4 nicht vollständig installiert oder entfernt.
Es müssen 0B Archive geholt werden.
Nach dem Auspacken werden 0B Plattenplatz zusätzlich benutzt.
Richte capplets-data ein (2.14.1-0ubuntu3) ...

GConf-Backends-ERROR **: file markup-tree.c: line 3377 (end_element_handler): assertion failed: (g_slist_length (info->local_schemas) == 1)
aborting...
dpkg: Fehler beim Bearbeiten von capplets-data (--configure):
 Unterprozess post-installation script gab den Fehlerwert 250 zurück
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von gnome-control-center:
 gnome-control-center hängt ab von capplets-data (= 1:2.14.1-0ubuntu3); aber:
  Paket capplets-data bereitstellt, ist noch nicht konfiguriert.

[Richard Theil (richard-theil)]

Over recent updates, the bug has started to affect more gnome-related packages, so it is probably nothing local to gconf-packages. I did some strace over what happened and got the following results:

...
[pid 7413] execve("/usr/sbin/gconf-schemas", ["gconf-schemas", "--register", "gnome-system-tools.schemas"], [/* 36 vars */]) = 0
...

root@neon:/home/rich# gconf-schemas --register gnome-system-tools.schemas

GConf-Backends-ERROR **: file markup-tree.c: line 3377 (end_element_handler): assertion failed: (g_slist_length (info->local_schemas) == 1)
aborting...
root@neon:/home/rich#

As we see, the failure happens as gconf-schemas is run with the same parameters as from apt-get install. This probably will not happen on a healthy system - but then something must have effected the system in a way for this to happen. I tried registering other schemas, which results in the same error. Looks like a classic "Broken Registry" from a user pov.

Also, issuing an assertion error and quitting might be a bug-to-be-fixed by itself, so I suggest relocating this bug to where gconf-schema belongs.

I drilled a bit further down, and it turned out that the breakage was caused by the "/var/lib/gconf/defaults/%gconf-tree-cy.xml" file. Moving this file out of the way (if anyone wants to have a look...) brought the system back in line. If appropriate, and broken versions of can show up out in the wild, the packagers probably should take care of it, and also, gconf-schemas might emit a somewhat better hint on what went wrong.

Temporary fix for this issue short of an upstream update: "strace -f gconf-schemas --register gnome-session.schemas", scroll up until you see what locale is being dealt with, delete that locale from /var/lib/gconf/defaults/.

[Sebastien Bacher (seb128)]

Thank you for your bug and the debug work on that. Could you attach the broken .xml? That's a system configuration so it should not have any user data

[Richard Theil (richard-theil)]

Original filename started with a '%' sign; I renamed that on moving
from /var/lib/gconf/defaults/%gconf-tree-cy.xml to a backup directory.

[Richard Theil (richard-theil)]

If you look at where the file is broken, you see what looks like some evolution config code in the middle of some screen setup. If you look at that with a hex editor, you see that the corruption occurs from about $45000 to precisely (!) $46000 in the file, which would be the VM page size of my machine (Athlon @ 1800MHz, crash free even under compiler load). Draw your conclusions...

I should note that I saw the cyclic fsck on boot reclaim something on the / partition the last time it ran. This should not happen with ext3 journaling enabled, right? (/dev/hda5 / ext3 rw,errors=remount-ro 0 0, /dev/hda7 /home ext3 rw 0 0)

[Sebastien Bacher (seb128)]

I've forwarded the issue upstream with a backtrace: http://bugzilla.gnome.org/show_bug.cgi?id=340834

Setting low priority because it happens only with corrupted xml which is not a standard case and easy to workaround