might be /home/stk/.kde/share/config/kdedrc in Arch? - some distros use ~/.kde4 others ~/.kde

Arch should use .kde4 by default. Unless you run KDEMod, in which case the directory is called .kdemod4.

I suspect that something is strange with your home directory _stk. Could you please elaborate what you did when you created a new one (e.g. as which user, the permissions it has etc.). Can you do a

Code: Select all

ls -la ~

and post the result here? (You can cut out your own directories from the list, it's mostly the directories/files starting with a dot that are interesting.)

Hans wrote:Arch should use .kde4 by default. Unless you run KDEMod, in which case the directory is called .kdemod4.

Yup, Arch Linux uses ~/.kde4 by default. Btw, all other accounts on my computer have ~/.kde4/share/config/kderc.

Hans wrote:I suspect that something is strange with your home directory _stk. Could you please elaborate what you did when you created a new one (e.g. as which user, the permissions it has etc.). Can you do a

Code: Select all

ls -la ~

and post the result here? (You can cut out your own directories from the list, it's mostly the directories/files starting with a dot that are interesting.)

When I create new $HOME (as root in tty)

Code: Select all

# mv /home/stk /home/stk-bak
# mkdir /home/stk
# chown -Rc stk:stk /home/stk
changed ownership of `/home/stk' to stk:stk
# chmod -Rc 700 /home/stk
mode of `/home/stk' changed to 0700 (rwx------)

So far, /home/stk is a new and empty folder. Then I switch to 'stk' and start kdm (in /etc/sudoers, 'stk' is set to "ALL=(ALL) ALL")

Code: Select all

$ sudo /etc/rc.d/kdm start

After login failed, I switch back to tty and try listing everything in my $HOME

Code: Select all

$ ls -lA
total 24
-rw------- 1 stk stk   39 Nov 29 06:20 .bash_history
drwxr-xr-x 2 stk stk 4096 Nov 29 06:12 .config
drwx------ 3 stk stk 4096 Nov 29 06:12 .dbus
drwx------ 3 stk stk 4096 Nov 29 06:12 .gnupg
-rw-r--r-- 1 stk stk    0 Nov 29 06:12 icon-cache
drwx------ 3 stk stk 4096 Nov 29 06:12 .kde4
-rw------- 1 stk stk    0 Nov 29 06:12 .Xauthority
-rw------- 1 stk stk  811 Nov 29 06:12 .xsession-errors


There is one weird file, ~/icon-cache. I don't know where it's from and why it's created _every time_ I try to login to 'stk'. It seems like an empty text file.

Code: Select all

$ file icon-cache
icon-cache: empty


.Xauthority is empty
.xsession-errors is exactly match to the one I posted.

Regards,
_stk

Thanks for posting such detailed information. Unfortunately this seems to be beyond my knowledge - the permissions look correct to me, you start with a clean $HOME (meaning there should be no corrupt config file) and it has worked for that user previously (so probably not group issues).

My only bet left is the cache files in /var/tmp/kdecache-$USER/, but that shouldn't prevent you from logging in. Anyway you could try to clear them and see if it helps.

As a last solution you can try to delete your user and create one with the same name and uid and see if it help (as it did for this user). You seem to know what you're doing, so I guess I don't have to remind you to make a backup first.

I got the same problem!
After painfully test with all the files, I finally find the file that is responsible for my blank screen!
It's krandrrc!!!

As a future note, checking the content of ~/.xsession-errors usually indicates why this occurs.

I have a similar problem, but no one of above solutions didn't solved.
I'm using OpenSUSE 11.4, and kde 4.7, and I cannot login to kde with my username, even in failsafe mode. When I'm trying to do it I get a blank screen for a sec and fallback to gdm. I can start kde as mythtv user, and I can start plasma-desktop manually from gnome3. But not from login screen.
I can find only this related entries on .xsession-errors:

Code: Select all

gnome-session[11765]: WARNING: Could not parse desktop file /etc/xdg/autostart/ksmolt-autostart.desktop: Invalid key name: X-KDE-autostart-condition[$e]
gnome-session[11765]: WARNING: could not read /etc/xdg/autostart/ksmolt-autostart.desktop
GNOME_KEYRING_CONTROL=/tmp/keyring-1gOMpz
GNOME_KEYRING_CONTROL=/tmp/keyring-1gOMpz
GNOME_KEYRING_CONTROL=/tmp/keyring-1gOMpz
GPG_AGENT_INFO=/tmp/keyring-1gOMpz/gpg:0:1
GNOME_KEYRING_CONTROL=/tmp/keyring-1gOMpz
GPG_AGENT_INFO=/tmp/keyring-1gOMpz/gpg:0:1
SSH_AUTH_SOCK=/tmp/keyring-1gOMpz/ssh

Any help?

EDIT:
I "solved" it by reinstall system

I've done a physical copy of an old HD into a new one and after that, I was not able to login into KDE again.

This is pretty weird because it is a physical copy. Every single byte from one HD was copied into the new one. For some unknown reason, KDE was refusing to let me log in after that. This is a pretty unexpected situation.

I've tried other solutions presented in this thread and nothing.
In particular, I've tried to create a brand new user and try to login KDE but nothing. So, seems like it's not related to any user configuration file.

I've looked at my ~/.xsession-errors file, which told me

Code: Select all

open: Permission denied


Well... not very explicative. I would love to know what hell my user does not have permission to open/read/write/whatever. Such kind of message is useless

Well, after lots of try-and-nothing, I found a solution which works for me.
I hope I can contribute to others finding the same difficulty.


Solution

1. Stop KDM

Code: Select all

# /etc/init.d/kdm stop


2. Make sure /tmp can be written by everyone, but exec is denied
see:

Code: Select all

# chmod 1777 /tmp


In particular, my /tmp was protected. After I executed the above command, I started to see something a little more useful in the .xsessions-errors file.
But the problem still persisted, so I had to go ahead with the steps below.

3. Enter in 'paranoid' mode and start cleaning some files.
Don't be afraid: these files will be recreated later.

Clear dbus configuration.

Code: Select all

$ cd # go to your user's home directory
$ rm -r -f .dbus


Clear your KDE cache

Code: Select all

$ cd /var/tmp
$ rm -r -f kdecache-`whoami`


4. Start X on DISPLAY :0, using your non-root user.

Note: substitute "user" by the your actual username.

Code: Select all

# su - user
$ startx :0


If everything goes well, the graphical environment will appear and you will see a terminal window. If this is not your case, you will have to investigate why X is not kicking off. Please find out why somewhere else and return back to this point later.

5. Make sure you are authorized to start KDE.

Using the terminal window which appeared when you executed the previous step, enter the commands below. You will have to tell that your local box is authorized to use X and also your username "user" (just for the sake of example) is autorized too.

Code: Select all

$ xhost +localhost
$ xhost +user


Note: substitute "user" by the your actual username.

6. Now start KDE from the terminal window mentioned before.

Code: Select all

$ startkde


If you see your desktop, this is great!
I hope you can, cos otherwise I'm not able to help you.
OK. Let's go ahead.

7. From root, save everything and reboot.

Code: Select all

# sync
# reboot


If after boot you can access your desktop as usual from the KDM login, problem solved! Otherwise, let's go ahead with some more steps.


Enter 'hardcore' mode

a) As root, reinstall KDM

Stop KDM

Code: Select all

# /etc/init.d/kdm stop


Remove KDM

Code: Select all

# apt-get remove kdm


Wipe out KDM from its dirty and insignificant existence

Code: Select all

# dpkg --purge kdm


Reinstall KDM

Code: Select all

# apt-get update
# apt-get install kdm


b) Try a clean reboot and see what happens

Code: Select all

# reboot


More tricks

In my specific case, turned out that the problem was due to /tmp not mounted properly. In a nutshell, you need to guarantee that it is mounted with permission 1777.

Below you can see a snippet of my /etc/fstab which (now!) does that properly:

Code: Select all

/dev/sda3       /tmp            ext3    noexec,nosuid,rw  0       2


I hope my contribution had helped you somehow.

Richard Gomes

The likely issue could be the the "uid" of your user changed when you reinstalled your system. In this case, running "chown -R <username>:$(id -gn <username>) /home/<username>/" should correct the situation.