Submited bug. Please review: User Switcher crashes on user B, user A can work only in text mode.

[Juan R. de Silva]

On Wed, 12 May 2010 17:56:12 +0000, sktsee wrote:

> On Wed, 12 May 2010 01:33:00 +0000, Juan R. de Silva wrote:
> 
>> I've just submitted a bug in Launchpad.
>> 
>> https://bugs.launchpad.net/ubuntu/+bug/579061
>> 
>> Please review it, and if anybody knows how to get out of situation
>> without a complete re-install, I would appreciate your help.
>> 
>> 
> From what you wrote in your bug report, user B has no issues when
> logging in, correct? 

Absolutely so. User B can use the system as normal at any time. User A is 
out of luck. He can actually log in, but then the only way to work with 
the system for him is to switch to one of the tty consoles and to work in 
text mode.

> If that's the case, then it's not necessary to
> re-install anything because the problem is not with the system, but
> something within user A's configuration, which means it's highly likely
> that it's local to his home directory. 

I think so too. But read further...

> The most drastic measure you
> should have to take is to remove/rename some configuration related
> directories that will reset user A's program settings back to their
> defaults once he logs out and back in again.

> Gnome app configs and data are stored in legacy and newer
> freedesktop.org specified directories:
> 
> ~/.gnome
> ~/.gnome2
> ~/.config
> ~/.cache
> ~/.local
> 
> Apps that use gconf managed settings store them in
> 
> ~/.gconf
> ~/.gconfd
> 
> And then apps may store some of their settings within their own
> directories, i.e. evolution in ~/.evolution.
> 
> Probably missed a few, but generally those are places to look in when
> trying to troubleshoot certain problems with non-starting or crashing
> apps.
> 
> If you want to try a few shot in the dark solutions, do the following in
> a vt before logging in to a Gnome session. Try logging in after doing
> each one.
> 
> 1. Delete ~/.gconfd/saved_state
> 
> 2. Rename ~/.gconf/apps/panel to ~/.gconf/apps/panel-backup. This will
> cause your panels and panel objects settings to be reset to their
> installation defaults upon login.
> 
> 3. If the above doesn't work, then rename ~/.gconf to ~/.gconf-backup.
> This resets everything gconf-wise to installation defaults.
> 
> 4. Check file perms for configs. Use find to see if any config files are
> owned by root, or user B.
> 
> $ cd ~
> $ find . ! -user <user A's username>
> Any config file or directory (those starting with ".") found and not
> owned by user A should be examined.
> 
> If none of the above work, then login as user A and then switch out to a
> vt and examine ~/.xession-errors file. Hopefully, there will be some
> indication in that file to help narrow down where the problem lies. Post
> any relevant error messages in that file to the list and go from there.

Tried absolutely all you suggested and probably a couple of things more 
(even do not remember now all of them) - nothing helped. I get frustrated 
and restored the system to Hardy. 

Good for me I imaged the entire system before upgrade. What happened is a 
real mystery... I think the bug is quite dangerous though. 

Just think about it - user B without any administrative privileges while 
working within its own environment was able to completely corrupt another 
user's environment. Isn't it scary? Everything was supposed to be 
confined with user's B home directory, wasn't it?

On my laptop I upgrade every 6 months. I'm willing to experiment and I do 
not mind things of a kind happen there. But IMHO LTS release should not 
go out with a bug of a kind. Looks like people are right saying fixed 
schedule hurts Ubuntu more than benefits it.

Well, I've learnt my lesson - Ubuntu LTS is not Debian Stable, never 
upgrade to it at an early stage.

Thanks for reply. I thought no one would take a ball :-).