Elusive problem related to %gconf-tree.xml after testing upgrade

classic Classic list List threaded Threaded
3 messages Options
ter
Reply | Threaded
Open this post in threaded view
|

Elusive problem related to %gconf-tree.xml after testing upgrade

ter
It may be related to a previous post about gconf not working.

I answered yes to migration during upgrade. All seemed to work fine.
Except windows would hang at various random points, sometimes crashing
the system to the point of not being able to switch to a tty.

I tried cleaning out .gconf, .gconfd, .gnome, .gnome2 in various
combinations. They all led to hangs with no consistent pattern, or
meaningful .xsession-errors. While I was thrashing around, I did another
upgrade which included certain gnome components. This did not help.

I also removed %gconf-tree.xml once, and answered yes to migration
again. It did not solve the hanging problem.

In addition, the following may offer a hint. While all audio was
working, including gnome-volume-control before upgrade and gconf
migration, the gnome-volume-control would not work with gconf migration,
even though all other audio/video worked.

Finally, I removed %gconf-tree.xml and rejected migration. I have not
had any hangs for a period of time longer than with migration. And
gnome-volume-control is working again.

The migration question did say that "certain scripts may break" when all
gconf data are combined into %gconf-tree.xml.

Even though not migrating seems to solve the hang problem for now, it is
still disturbing that I was not able to start afresh by removing .gconf*
and .gnome*.

I would be happy to do some more experiments if it would help find the
problem.

E
--


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Elusive problem related to %gconf-tree.xml after testing upgrade

Jochen Bartl
Am Mittwoch, den 18.01.2006, 18:37 -0800 schrieb Elaine Tsiang YueLien:

> It may be related to a previous post about gconf not working.
>
> I answered yes to migration during upgrade. All seemed to work fine.
> Except windows would hang at various random points, sometimes crashing
> the system to the point of not being able to switch to a tty.
>
> I tried cleaning out .gconf, .gconfd, .gnome, .gnome2 in various
> combinations. They all led to hangs with no consistent pattern, or
> meaningful .xsession-errors. While I was thrashing around, I did another
> upgrade which included certain gnome components. This did not help.
>
> I also removed %gconf-tree.xml once, and answered yes to migration
> again. It did not solve the hanging problem.
>
> In addition, the following may offer a hint. While all audio was
> working, including gnome-volume-control before upgrade and gconf
> migration, the gnome-volume-control would not work with gconf migration,
> even though all other audio/video worked.
>
> Finally, I removed %gconf-tree.xml and rejected migration. I have not
> had any hangs for a period of time longer than with migration. And
> gnome-volume-control is working again.
>
> The migration question did say that "certain scripts may break" when all
> gconf data are combined into %gconf-tree.xml.
>
> Even though not migrating seems to solve the hang problem for now, it is
> still disturbing that I was not able to start afresh by removing .gconf*
> and .gnome*.
>
> I would be happy to do some more experiments if it would help find the
> problem.
>
> E
> --
>
>
Hi.

I'm sure this problem is simlar to mine
http://lists.debian.org/debian-gtk-gnome/2006/01/msg00035.html

To solve this problem, I purged all my gnome packages and created a new
user. After reconfiguring gnome and its programs, I did a reboot. All of
the configuration was lost again. Firstly I thougt $HOME/.gconf/%
gconf-tree.xml was readonly, but it wasn't.

The errors didn't show up since yesterday, so I think my problem is
fixed. But in your case, killall -USR1 gconfd-2 could be useful. Now,
gconfd will log more verbose to /var/log/user.log and you hopefully can
solve your problem.

best regards,

jochen

signature.asc (196 bytes) Download Attachment
ter
Reply | Threaded
Open this post in threaded view
|

Re: Elusive problem related to %gconf-tree.xml after testing upgrade

ter
On Thu, 2006-01-19 at 17:39 +0100, Jochen Bartl wrote:
> Am Mittwoch, den 18.01.2006, 18:37 -0800 schrieb Elaine Tsiang YueLien:
> > It may be related to a previous post about gconf not working.
> >
> > I answered yes to migration during upgrade. All seemed to work fine.
> > Except windows would hang at various random points, sometimes crashing
> > the system to the point of not being able to switch to a tty.
> >
[snipped]

> >
> > The migration question did say that "certain scripts may break" when all
> > gconf data are combined into %gconf-tree.xml.
> >
> > Even though not migrating seems to solve the hang problem for now, it is
> > still disturbing that I was not able to start afresh by removing .gconf*
> > and .gnome*.
> >
> > I would be happy to do some more experiments if it would help find the
> > problem.
> >
> > E
> > --
> >
> >
>
> Hi.
>
> I'm sure this problem is simlar to mine
> http://lists.debian.org/debian-gtk-gnome/2006/01/msg00035.html
>
> To solve this problem, I purged all my gnome packages and created a new
> user. After reconfiguring gnome and its programs, I did a reboot. All of
> the configuration was lost again. Firstly I thougt $HOME/.gconf/%
> gconf-tree.xml was readonly, but it wasn't.
Very drastic medicine, which I had to take one time before. But maybe I
would need to take it again sometime soon. My gnome/gconf data have come
through several incarnations of X/gnome/gconf. The single-file
conversion may not take care of some really old settings.
>
> The errors didn't show up since yesterday, so I think my problem is
> fixed. But in your case, killall -USR1 gconfd-2 could be useful. Now,
> gconfd will log more verbose to /var/log/user.log and you hopefully can
> solve your problem.
Yes, I did not think about how the daemon could preserve settings even
through rebooting. It needs to be killed before removing the gconf data.

I logged out - which killed the gconfd. To be sure, I killed gdm. Then I
removed DON'T-MIGRATE and rebooted. I answered yes to migration. The
gnome-volume-control is still there. No funny .xsession-errors, and no
hangs so far. This still begs the question of why it did not work after
the upgrade - maybe the upgrade needs to be done without gnome, in tty
mode.

Thanks, I'll take the bitter medicine later when I have to.

E.
>
> best regards,
>
> jochen
--


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]