check-new-release-gtk crashed with GError in on_button_dont_upgrade_clicked()

[Daniel Richard G.]

Binary package hint: update-manager

I just wanted the window to go away!

ProblemType: Crash
DistroRelease: Ubuntu 10.10
Package: update-manager 1:0.142.23
ProcVersionSignature: Ubuntu 2.6.35-28.50-generic 2.6.35.11
Uname: Linux 2.6.35-28-generic x86_64
NonfreeKernelModules: openafs
Architecture: amd64
Date: Tue May 17 12:35:05 2011
ExecutablePath: /usr/lib/update-manager/check-new-release-gtk
InterpreterPath: /usr/bin/python2.6
PackageArchitecture: all
ProcCmdline: /usr/bin/python2.6 /usr/lib/update-manager/check-new-release-gtk
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
PythonArgs: ['/usr/lib/update-manager/check-new-release-gtk']
SourcePackage: update-manager
Title: check-new-release-gtk crashed with GError in on_button_dont_upgrade_clicked()
Traceback:
 Traceback (most recent call last):
   File "/usr/lib/update-manager/check-new-release-gtk", line 106, in on_button_dont_upgrade_clicked
     self.new_dist.name)
 GError: No database available to save your configuration: Unable to store a value at key '/apps/update-manager/check_new_release_ignore', 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
UserGroups: adm audio cdrom dialout floppy plugdev video

[RedSingularity (redsingularity)]

Thanks for reporting this. Are you able to reproduce this error?

[Daniel Richard G. (skunk)]

Many, many more times than I would like.

[RedSingularity (redsingularity)]

Ok, what happens if you run it as root like this:

gksu update-manager

Does the problem persist?

[Daniel Richard G. (skunk)]

The problem is not with the update-manager application itself, but with the check-new-release-gtk dialog. See bug #785296.

[Brian Murray (brian-murray)]

Based off the error message it seems that check-new-release-gtk is trying to write a key (check_new_release_ignore) to your gconf database and is failing because there is an issue with gconf on your system. Your bug description actually has some detailed information about this:

No database available to save your configuration: Unable to store a value at key '/apps/update-manager/check_new_release_ignore', 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

[Daniel Richard G. (skunk)]

It's not clear that there is anything wrong with gconf itself (no lockfiles are present, and e.g. "gconftool -R /" prints out numerous settings and exits with status 0), though I'm now working on a Natty system with the same home directory.

Aside from tweaking the program to handle this error case more gracefully, however, I think it would be sensible to save the user's upgrade decision in ~/.config/update-notifier/ (a directory which exists on my system, albeit empty) rather than rely on the GConf infrastructure. In my case, because the program was unable to save my "Don't upgrade" choice, the window kept popping up again and again throughout the day, causing great annoyance.