Arch Linux

This works for me. Do you have hal running?

Yes, it should be running. At least no error is shown when hal is starting.
Anyway, if it would be problem with hal (I've only added it to /etc/rc.conf) is this dependency necessary? Because before I was able to run KDE without need to run HAL (actually I don't like hal).

You will need at least the dbus system bus running. Hal is optional AFAIK.

hal starts dbus automatically.

Do you start it in the background? (might be a timing problem then) Does it work if you quit kdm and start it again manually? Is there anythign interesting logged in /var/log/kdm.log?

That's why it works for people who think they need hal specifically. Anyways, KDE and a lot of other desktop applications are crippled in functionality without hal.

I don't think it's a timing problem, because I've tried restarting dbus and hal and then starting KDM several times. Nothing helped. I've also found that it can be caused by nvidia driver which could be fixed adding by some specific option to /etc/X11/xorg.conf, but it didn't help either (moreover it was working before and this was only one package upgraded along with it's dependencies).

I'm starting hal in /etc/rc.conf:
DAEMONS=(syslog-ng iptables network @mysqld !timidity++ @ntpdate crond @ddclient @ossec alsa hal @vmware)

KDM is configured in /etc/inittab:
id:5:initdefault:
x:5:respawn:/usr/bin/kdm -nodaemon

Ad logs) everything useful is in forum topic. /var/log/kdm.log contains only note that everything is logged via syslog and part of Xorg log:

X.Org X Server 1.5.3
Release Date: 5 November 2008
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.27-ARCH i686
Current Operating System: Linux red_dragon 2.6.28 #1 Thu Dec 25 11:08:32 CET 2008 i686
Build Date: 17 December 2008 08:20:05PM

Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Wed Jan 7 10:05:22 2009
(==) Using config file: "/etc/X11/xorg.conf"
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning: Symbol map for key <RALT> redefined
> Using last definition for conflicting fields
Errors from xkbcomp are not fatal to the X server
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning: Symbol map for key <RALT> redefined
> Using last definition for conflicting fields
Errors from xkbcomp are not fatal to the X server
[config/dbus] couldn't register object path

Warning about keyboard could be caused by using non-standard layout. Dbus problem is logged also in Xorg.0.log

I also have this problem, which happened suddenly after upgrading kdebase-workspace, so now I have to login to the console and call startx. The following are the relevant lines from errors.log:

Jan 7 07:25:27 cies kdm: :0[4862]: Cannot open ConsoleKit session: Unable to open session: Failed to execute program /usr/lib/dbus-1.0/dbus-daemon-launch-helper: Success
Jan 7 07:25:27 cies kdm: :0[4862]: Client start failed
Jan 7 07:25:27 cies kdm: :0[4862]: Cannot close ConsoleKit session: Unable to close session: no session open

Is the dbus system bus running on your system? Without that, consolekit won't get launched and these things fail.

Yes, dbus is running before I try to log in:

[root@cies ~]# ps -ef | grep dbus
dbus 4511 1 0 15:58 ? 00:00:00 /usr/bin/dbus-daemon --system
root 4867 1 0 15:58 ? 00:00:00 dbus-launch --autolaunch 51eba166730de56fd26c705b490212f6 --binary-syntax --close-stderr
root 4869 1 0 15:58 ? 00:00:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session

Same thing here :/ that's very, I've also test it with a clean installation of arch, and of course having dbus running :/

Yep, after research a bit, I discovered that, executing console-kit somewhere, kdm works perfect, so maybe the last update remove/add something about console-kit.

Hmm, this should not be the case, as dbus should launch consolekit when something asks for it. It's in the system-services dbus path, so dbus knows where to find it when it's requested.

What are the permissions and groups for /usr/lib/dbus-1.0/dbus-daemon-launch-helper on the systems where this bug appears? It should show up like this:
-rwsr-x--- 1 root dbus 46056 2008-11-28 20:35 /usr/lib/dbus-1.0/dbus-daemon-launch-helper

Also post the output of "id dbus".

[root@cies ~]# ls -lh /usr/lib/dbus-1.0/dbus-daemon-launch-helper
-rwxr-x--- 1 root root 39K nov 14 22:35 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
[root@cies ~]# id dbus
uid=81(dbus) gid=81(dbus) grupos=81(dbus)
[root@cies ~]#

So that was it! I changed the permissions and group for /usr/lib/dbus-1.0/dbus-daemon-launch-helper and now kdm works fine:
# chown root:dbus /usr/lib/dbus-1.0/dbus-daemon-launch-helper
# chmod u+s /usr/lib/dbus-1.0/dbus-daemon-launch-helper

Thank you so much!

Any idea why this file was extracted as root:root while the package states root:dbus?

Sorry, no idea

Maybe the dbus user was not available at the time pacman extracts the files?

Then usually it should extract as root:81, which will resolve to root:dbus later. Does pacman do anything with permissions when a group doesn't exist?

Still doesn't work. I think that the problem is in ConsoleKit:
Jan 12 13:46:13 red_dragon console-kit-daemon[3917]: DEBUG: Debugging enabled
Jan 12 13:46:13 red_dragon console-kit-daemon[3917]: DEBUG: initializing console-kit-daemon 0.3.0
Jan 12 13:46:13 red_dragon console-kit-daemon[3917]: DEBUG: Creating thread for log writing
Jan 12 13:46:13 red_dragon console-kit-daemon[3917]: DEBUG: Creating seat /org/freedesktop/ConsoleKit/Seat1 with 0 devices
Jan 12 13:46:13 red_dragon console-kit-daemon[3917]: DEBUG: Current VT: tty2
…
Jan 12 13:46:13 red_dragon console-kit-daemon[3917]: DEBUG: Creating thread for vt 62
Jan 12 13:46:13 red_dragon console-kit-daemon[3917]: DEBUG: VT_WAITACTIVE for vt 62
Jan 12 13:46:13 red_dragon console-kit-daemon[3917]: DEBUG: Added seat: /org/freedesktop/ConsoleKit/Seat1
Jan 12 13:46:13 red_dragon console-kit-daemon[3917]: DEBUG: Writing log for event: 1231764373.278 type=SEAT_ADDED : seat-id='Seat1' seat-kind=0
Jan 12 13:46:13 red_dragon console-kit-daemon[3917]: CRITICAL: cannot initialize libpolkit
Jan 12 13:46:13 red_dragon console-kit-daemon[3917]: DEBUG: Destroying writer thread
Jan 12 13:46:13 red_dragon console-kit-daemon[3917]: DEBUG: Writer thread received None event - exiting
Jan 12 13:46:13 red_dragon console-kit-daemon[3917]: DEBUG: Joining writer thread

I've found where the problem was. Policykit needs support for inotify in kernel for running, which I didn't have. After compiling kernel with inotify support everything works fine. Sorry for inconvenience.

I think policykit isn't the only thing that breaks on a kernel without inotify support. Inotify is a common thing used by a lot of applications. Inotify is quite standard and is assumed to be available on every distribution that ships a recent version of glibc and a "recent" kernel.

I have the same bug, kde not started without dbus (kdebase-workspace 4.1.3-1 works ok)
if dbus started(rc.conf) i have first login failed (return to kdm), second ok


downgrade to 4.1.3-1 :)