Hardy Heron KDE freezes for one user account (others have no problem)

[lhgreene]

Upgraded to Hardy Heron on a System76 laptop that came with Ubuntu preinstalled and Kubuntu added afterward, that was successfully running Gutsy Gibbon, with multiple user accounts that were able to use KDE and Gnome under Gutsy.

After the upgrade to HH, GRUB runs and it gets to the login window successfully. All users can successfully login to Gnome sessions. Most users also can login to KDE sessions. But for one user (and only that one) when logging into a KDE session - the desktop wallpaper appears and toolbar, but before icons become visible on the desktop, the system freezes up and a continuous loud tone blares from the laptop speakers. From there, the system is unresponsive and the only way to stop the sound and escape the freeze is to power off the machine. There must be some sort of configuration file for that one user which is different than the versions for the other users and which is causing the problem. Anybody have any suggestions for how to troubleshoot and resolve this problem for that user to log in and use KDE? Anyone know what file(s) to modify and how to do it?

[Fintan]

Re: Hardy Heron KDE freezes for one user account (others have no problem)

I am no expert but I would boot into recovery (root) mode and type startx at the prompt(#).

Then go to systemsettings>usermanagement and have a look and compare the users (groups, etc) and look for differences.

Edit:
Another way (probably easier) of doing this would be for the user to back up all of his/her data, configurations (kmail, kontact, .mozilla Firefox, thunderbird etc) and delete that user from within usermanagement and create a new one.

[dibl]

Re: Hardy Heron KDE freezes for one user account (others have no problem)

The user's KDE settings are in a hidden folder named ~/,kde. It also has some types of "data", i.e. kmail, contact lists, etc. If you can (from a root console) rename it to ".kde_bak", then that user should be able to log in to KDE, but will find a generic KDE desktop with no settings or customization. A new "clean" ~/.kde folder will be created, and the "data" can be transferred into it from the backed up folder.

[lhgreene]

Re: Hardy Heron KDE freezes for one user account (others have no problem)

Renaming .kde for that user created another problem - when trying to login to a KDE session for that user, it just generates a kstartupconfig error and won't login to KDE. Renaming it the original .kde folder back to .kde, that generates an error "unable to read /home/carol/.ICEauthority" that prevents that user from logging in to either Gnome or KDE sessions. Getting in as another user and using sudo to delete the .ICEauthority file for user Carol solves that, so Carol can login successfully to a Gnome session. Now, the interesting part - after all that - the good news: Carol can login to a KDE session now, without freezing, and the bad: when Carol logins to a KDE session, that loud continuous tone blares from the laptop speakers and won't stop. I'm using the speaker icon and mute button to kill the noise - but need to determine what's causing the noise and get it to stop. Any suggestions on that remaining issue?

The user's KDE settings are in a hidden folder named ~/,kde. It also has some types of "data", i.e. kmail, contact lists, etc. If you can (from a root console) rename it to ".kde_bak", then that user should be able to log in to KDE, but will find a generic KDE desktop with no settings or customization. A new "clean" ~/.kde folder will be created, and the "data" can be transferred into it from the backed up folder.

[dibl]

Re: Hardy Heron KDE freezes for one user account (others have no problem)

I'm guessing, and I'll admit it, but I wonder if the "save session" function has gone wrong, and saved a sound setting. In other words, there is a function that "memorizes" the KDE settings upon logging out of a session, so that those open pages and applications can be re-opened at the next login. In your case, it thinks there's supposed to be a C-sharp playing on the sound chip, I guess. I've never heard of this problem, but if you can work out where the "save session settings" is in kcontrol, and mark it to NOT save session settings, then maybe that would clear the problem.

"Maybe" being the operative term .... :P