I forgot: I'm using sysvinit, and policykit is enabled for kdelibs. So I also tried reinstalling consolekit and polkit (the day I tried I had to patch polkit 0.110 in order to compile !!! :-/). Nothing changed.
Natanael. On 04/10/2013 10:11 PM, nael wrote: > Hi, > > On 04/09/2013 05:05 PM, Yuri K. Shatroff wrote: >> On 09.04.2013 17:13, João Matos wrote: >>> >>> >>> 2013/4/9 Yuri K. Shatroff <yks-...@yandex.ru <mailto:yks-...@yandex.ru>> >>> >>> Hello gentoo-users, >>> >>> Yesterday I completed a world update (amd64, unstable) and now I >>> can't login with kdm. >>> (I have kdm set as display manager in /etc/conf.d/xdm, and started >>> from default runlevel) >>> After booting, the login screen appears as usual. I type >>> login/password and then a glimpse of X's default x-shaped pointer on >>> black background appears, returning to the login screen. >>> I don't get any sensible errors, neither in kdm.log nor in messages, >>> all I see is: >>> >>> [/var/log/kdm.log] >>> ----------------------------- >>> klauncher(21958) kdemain: No DBUS session-bus found. Check if you >>> have started the DBUS server. >>> kdeinit4: Communication error with launcher. Exiting! >>> kdmgreet(21952)/kdecore (K*TimeZone*): KSystemTimeZones: ktimezoned >>> initialize() D-Bus call failed: "Not connected to D-Bus server" >>> >>> kdmgreet(21952)/kdecore (K*TimeZone*): No time zone information >>> obtained from ktimezoned >>> ----------------------------- >>> >>> But I guess this is unrelated, since dbus is running (and restarting >>> it doesn't help, nor does restarting xdm) >>> >>> Each time login fails I also see this in >>> [/var/log/messages] >>> ----------------------------- >>> Apr 9 11:33:53 localhost kdm: :0[20396]: pam_unix(kde:session): >>> session opened for user yks by (uid=0) >>> Apr 9 11:33:54 localhost kdm: :0[20396]: pam_unix(kde:session): >>> session closed for user yks >>> ----------------------------- >>> >>> No other logs appear to change. >>> >>> Needless to say that kdm 4.10.1 and earlier worked properly, and no >>> configuration files were changed during the last update. >>> >>> As a workaround, I just typed startx on the console (with startkde >>> in .xinitrc) and KDE started up, so I assume the problem is >>> somewhere around kdm. > > I' m exactly in the same situation. In two different machines I had the > same result upgrading world. The upgrade included kde 4.10.2, but I also > udev-201 and more ebuilds. > > On one of the machines I tried downgrading udev but didn' t work. > > > Xdm doesn't work neither, but gdm does! > startx with "startkde" also works. > > > Did you found something more? > > > > Best regards, > Natanael. > > >>> Any ideas? >>> >>> P.S. I had no problem with networking and udev which got updated >>> from 197-r9 to 200 and the network interface name didn't change from >>> eth0 (the 80-*rules file was a regular file full of commented text) >>> >>> -- >>> Best wishes, >>> Yuri K. Shatroff >>> >>> >>> Hi. I have a similar problem here, since the last update from kde 4.9. >>> But I can login with my user, I just cant using any new user. I found >>> this problem easily, because I have a guest account, and I erase >>> "/home/guest/*" once in a while. Since two months ago this account is >>> useless. >> that's a little different problem ;) I remember the related discussion >> on this mailing list. >> >>> But my kde is istill 4.10.1. It seemed nobody had the same problem, and >>> my problem was not that bad because my own account was working pretty >>> well. >>> >>> The error is exactly the same of yours, when I try to login the guest >>> account, but when I try "startx" a get the following: >>> >>> /etc/X11/xinit/xinitrc line 63: exec: xterm: not found >> Can this be solved by putting an executable .xinitrc into the user's >> home dir? >> As for me, I had to put >> ----- >> exec /usr/bin/startkde >> ----- >> so that startx would start kde. >> >>> I don't think it will help, because I get the same error if I try the >>> "working account". >>> >>> I'm using systemd, so I tried to remove consolkit support from kdm, but >>> it didn't help. >> I also have a suspicion it has to do with consolekit, but there is no >> simple way to make sure. >> >>> Is anyone else facing a similar problem? >>> >>> >>> -- >>> João de Matos >>> Linux User #461527 >>> Graduado em Engenharia de Computação >>> UEFS - Universidade Estadual de Feira de Santana >>
