On a minimal install, with gdm configured to autologin, kde starts, but then dies, returning the system to the gdm login screen. A subsequent login to kde is ok. It appears kde is starting before something that it requires has started. I expect this would also happen if using the autologin package, or kdm, instead of gdm. In the .xsession-errors file on the first start of kde, the failures start with ... kglobalaccel: Fatal IO error: client killed kactivitymanagerd: Fatal IO error: client killed kdeinit4: Fatal IO error: client killed kdeinit4: sending SIGHUP to children. I'll attach the .xsession-errors files from both the first start of kde, where it fails, and the second start, where the startup is good.
Created attachment 1108 [details] .xsession-errors from first (failed) attempt to start kde
Created attachment 1109 [details] .xsession-errors from second (good) start of kde
Looking through the first .xsession-errors file, I think the line plasma-desktop(3990)/libakonadi Akonadi::AgentManagerPrivate::createDBusInterface: AgentManager failed to get a val id AgentManager DBus interface. Error is: 1 "org.freedesktop.DBus.Error.NameHasNoOwner" "Could not get owner of nam e 'org.freedesktop.Akonadi.Control': no such name" is the critical one. It looks to me like kde is starting before dbus.
Mikala, any idea ?
Assignee: bugsquad => balcaen.john
Also, just fyi, I currently have two cauldron installs, and this only happens on one of them. The one where it doesn't happen, is an install that started as a Mdv 2009.1 install, udated via urpmi to 2010.2, then to Mageia 1, alpha 2 (by mistake), which has since been kept as a cauldron install. It has about 4800 packages installed. On the install where it does happen, this was a clean install of mga 1, updated to cauldron using the pre-release alpha iso. I've installed all of the updates since then. It only has around 2200 packages installed, and only default services enabled. It seems that the extra services in the full install, slow down the staring of kde long enough that autologin works in that install.
Created attachment 1112 [details] service -s output when kde fails Now I know it is not dbus that is causing the problem, but now I have no idea what is causing the problem. I created ... $ cat /home/dave/.kde4/Autostart/status #!/bin/bash /sbin/service -s > /home/dave/service.status Comparing the output when kde fails with the output when kde works shows no obvious differences. The dbus service has already started. I'm attaching the output from when kde fails.
Created attachment 1113 [details] service -s output when kde works
Attachment 1112 mime type: application/octet-stream => text/plain
if i'm not wrong the issue is only happening with systemd & not sysvinit. @ david > you're speaking about the autologin package ? or the autologin functionnality of kdm/gdm ? (not sure if gdm provides such functionnality but if i'm not wrong it was also broken )
CC: (none) => balcaen.john
CC: (none) => dmorganec
I realize I was wrong about both cauldron installs using gdm. The one where autologin is working properly was using kdm. Switching it to gdm causes the same failure there, so I've changed the rpm for this bug to gdm. This is with systemd. I haven't tried sysvinit in cauldron, since systemd became the default. Some more info that may help to track down the problem. The crash doesn't happen until I do something that involves pressing the enter key. I can play pysol, open konsole and type in a command. Everything seems to be fine, until I press the enter key. Also happens with gnome. All I have to do to crash it, after autologin, is press the enter key. After normal login, everything is ok. Additionally, I noticed that when the desktop manager crashes (I.E. when I press the enter key), there are some garbage characters added to VT 7. It's as if the enter key is still going to vt7, while other keys pressed on the keyboard are going to vt8.
Source RPM: systemd-37-11.mga2.src.rpm => gdm-3.2.1.1-1.mga2.src.rpm
Ok the problem seems related to gdm here & not kde at all. Do you have the .xsession-errors available during the crash ? (& removing me as assignee :p )
Assignee: balcaen.john => bugsquad
(In reply to comment #10) > Ok the problem seems related to gdm here & not kde at all. > Do you have the .xsession-errors available during the crash ? > (& removing me as assignee :p ) @ mikala You mean there is something missing in attachment 1108 [details]? cc'ing two more gdm committers
CC: (none) => jani.valimaa, mageia, marja11
I did ?
@ Dave We have gdm-3.4.0.1-3.mga2 now, is this bug still valid?
CC: jani.valimaa => (none)
Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja
Keywords: (none) => NEEDINFO
Closing, because this bug was filed in november 2011, there is nothing indicating the bug is still valid and there was no reply to the last two comments Please reopen if it is still valid for Mga2 or current cauldron
Status: NEW => RESOLVEDResolution: (none) => OLD