This is the second time this happens. First time my Suse 9.2 got frozen while in a root session, pushed reset and I could no longer login as root, other 2 users could login. I reinstalled.

I rarely login as root, I rather login into KDE as a common user and open a Root Console to manage the system. Yesterday the session got frozen again and the user with the frozen session could no longer login after reset/reboot. I created a new account for this user and copied the /home/user/.thunderbird and other .directories. The user's account works ok.

I noticed a .kde folder in every user directory. Is there something that controls such login situation?

When one types in the faulty user+password pair, the screen gets dark, and then the Suse wait cursor shows and then the login screen shows again. ONLY THE FAILSAFE login works ok, but it's a terminal login, not the kde desktop.

Does anyone know how to fix the fault in the account's login into kde? (besides the obvious erasing of old user's directory and account creation with same old name of course) In other words: where is the setting that controls login process within the user's information?

Thanks.

In such cases, just delete the .kde directory in the users home folder. If it's root that cannot access kde, delete the .kde folder in /root folder. This should do the trick and reset your settings(THIS RESETS YOUR SETTINGS) and you should be able to login to KDE once again without problems.

My SUSE 9.2 install is doing the same da*n thing, after a single reboot I am unable to login using the home account. Attempting to login simply loops me around through a dark screen and back to the login prompt. I AM able to login as root to KDE. I disabled the NVIDIA driver and deleted the .kde folder in the home directory, to no avail! HELP!

It's common for Suse and it happened to me everytime I installed this distro. After some reboots you cannot login as user, but you can as root. After few other reboots this doesn't work either. The solution is simple: if you are still able to login as root, do it, and then just delete the .xinitrc file from your /home directory (it's 0 bytes and you can see it by selecting View-> Show hidden files in your Konqueror browser). Another solution would be to replace the 0 bytes .xinitrc file from your home directory with the xinitrc file from root/x... etc. directory. Just be careful when copying that file to rename it by adding the dot"." in front of it so it becomes .xinitrc . I personally didn't find any differences between the two methods so I used the first one, since it's simpler. And also, if you cannot login as root either use login as failsafe and do the same.
Hope that helped

Hi Guys:

Thanks for the last suggestion of the .xinitrc directory. Last time this happened to me I tried the former suggestion of deleting the .kde in the user's directory but it did not work, so I did the long method of coping the data to some other place, then delete the account deleting the user's dir, create the account again, re-creating user's dir, log in with the newly re-created account and copy the data (all mail info, mozila configuration, etc.). This part of copying the data has to be done as root and then chown the data copied to the corresponding user, because some files might have 600 or 700 permissions, with root or ANOTHER owner, so only root/owner could read it. You can test this situation just for fun, trying to copy your data info "as yourself" (not root) to some other place and check for "cp" (copy) warnings.

This problem of not being able to log it could happen to any user including root, so better to keep the root account only for emergencies and even better if you can have an additional user account for emergencies, just to log in and manage the situation.

Also consider that you can run or launch any program like konqueror "as root" even if you logged in as any other user, which is helpful to move data without restrictions *BUT* any file copied in this manner will also change ownership to root in the destination file(s), which needs an extra step to "chown" all those files to the correct user.

Next time I will use the .xinitrc delete method which will certainly save me from all that -relatively- long process, though the research is always healthy.

Regards

THANK YOU! This did the trick finally! I wonder how often I will need 2 repeat it? Will installing the NVIDIA driver cause worse problems that this trick might not be able to solve?