This error occurs in my /var/log/kdm.log file and causes kdm to take about a minute to start: /etc/X11/xdm/Xsetup_0: cd: /usr/share/config/kdm: No such file or directory Fix - make the following link: /usr/share/config -> /usr/kde/3.1/share/config Now kdm starts in a reasonalbe amount of time. Charlie
I don't know if this is a related problem but after a CVS build of qt, arts, kdelibs and kdebase a few days back, I can't start *any* wm from kdm. xdm works fine. Even kde-cvs was working fine till before this build. I looked at some of the scripts and they all looked OK to me. I have even deleted all .xsession, .wmrc and .kde stuff from my home directory. Even creating a new user and loggin in as that user using kdm, didn't work. The /var/log/kdm.log file looks like this:- <SNIP> XFree86 Version 4.2.1 / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 3 September 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.19-xfs-r2 i686 [ELF] Module Loader present 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/XFree86.0.log", Time: Sun Dec 8 13:09:20 2002 (==) Using config file: "/etc/X11/XF86Config" (II) [GLX]: Calling GlxExtensionInit /etc/X11/xdm/Xsetup_0: line 7: /usr/kde/cvs/bin/kdmdesktop: No such file or directory sessions: SessionTypes=Xsession,icewm,kde-5, Changing kdmrc in /usr/kde/cvs Changing kdmrc in /usr /etc/X11/xdm/Xsetup_0: line 25: cd: /usr/share/config/kdm: No such file or directory Changing kdmrc in /usr/kde/cvs (II) [GLX]: Calling GlxExtensionInit /etc/X11/xdm/Xsetup_0: line 7: /usr/kde/cvs/bin/kdmdesktop: No such file or directory sessions: SessionTypes=Xsession,icewm,kde-5, Changing kdmrc in /usr/kde/cvs Changing kdmrc in /usr /etc/X11/xdm/Xsetup_0: line 25: cd: /usr/share/config/kdm: No such file or directory Changing kdmrc in /usr/kde/cvs </SNIP> When started from the vc (X :0 & and then startkde), the screen flickers around three times (as if the X configuration is wrong), but then kde starts up and works fine. It also works fine when started from xdm. There is no time lag as well, unlike that reported by Charlie. The time lag isn't there even when started using startkde from the vc. Just the monitoring flickering (switching) on and off repeatedly before the wm starts. This behaviour can be seen on two different machines using the same CVS kde build. One uses the 1.4 profile and one uses the older 1.2 profile. Both are x86.
Sorry about the lack of line breaks in the previous comment. I've begun using Opera now and it probably behaves differently from Mozilla/Phoenix.
using kde-cvs (compiled yesterday) i got a very similar problem as you both. kdm loads sluggish and fails to start kde/kwin or any other wm. gdm and xdm work fine, with kde/kwin-cvs too. the kdm.log looked similar to the one of prashanth before i made symlinks for /usr/share/config (pointing to the according in /usr/kde/cvs) and kdmdesktop (pointing to an old one in /usr/kde/3 due to lacking alternative). after having created these symlinks, kdm.log didn't look uncommon anymore (no errors or warnings besides the usual speedo stuff), but the problem remained. unfortunately, no ~.xsession-errors file is written. tried some other things too, none of them solved the problem. #kde on freenode wasn't of any help either (no kdm dev there at the time). i also checked the bug reports at kde.org, did not spot anything similar. pathes and environment variables should be fine actually as i even (temporarily) removed the old qt and kde files from /etc/env.d (checked with 'set'). the testing was done as root, as user who already used kde 3.05a and as blank new (test-)user. strange problem.. any idea of how to easily trace the calls of kdm when loading a session? strace is only helpful when starting kdm, not while running it. any help greatly appreciated.
addendum: looks like 'strace kdm -nodaemon' could be helpful.
gee, finally i found the reason why :)) in /usr/kde/cvs/share/config/kdm/kdmrc the following two (hardcoded!) lines (there are more such, but they are commented-out) Startup=/usr/kde/3.1/share/config/kdm/Xstartup Reset=/usr/kde/3.1/share/config/kdm/Xreset point to non-existing files (as i don't have any /usr/kde/3.1 directory) unfortunately, the directory supposed to contain these files (at least in my case), /usr/kde/cvs/share/config/kdm/ doesn't contain neither of the two files. as these two files are basically just scripts i tested whether kdm works with the "old", kde 3.05a ones too. and yes, kdm works fine with them :) thus as a nasty workaround (until the thing's fixed) i suggest replacing these two lines by Startup=/usr/kde/3/share/config/kdm/Xstartup Reset=/usr/kde/3/share/config/kdm/Xreset (or any other location where you find these two files). alternatively: symlinking. btw. kdm still feels sluggish when starting, but i suppose this might be due to intentional library preloading (my hdd is pretty busy at least). kde itself loads much faster than it loaded with kde 3.0.5a.
Created attachment 7153 [details] /usr/kde/3/share/config/kdm/Xstartup (from kde 3.0.5a, in case you don't have any kde 3.0.x anymore)
Created attachment 7154 [details] /usr/kde/3/share/config/kdm/Xreset (from kde 3.0.5a, in case you don't have any kde 3.0.x anymore)
I had similar behavior until I did a ln -sf /usr/kde/cvs /usr/kde/3.1 then everything worked. Using kde cvs.
Where to start... The 3.1 kdebase ebuild has a new kdmrc that should have all the right paths. This can be backported to a new revision of 3.0.5a if needed. The cvs ebuild(s) might well be broken, I'll take them up again shortly.. The '/foo/kdm: no such file or directory' errors are completely harmless. They can't cause any problems or slowdown. Shouldn't, anyway... They live in /etc/X11/xdm/Xsetup_0. You can run it directly without any adverse effects, ad thus measure the time it takes to run (it shouldn't take more than a few milliseconds really) and see if it really is causing a slowdown. But I think something else must be to blame...
the kde ebuild doesn't seem to take care of running fc-cache after compiling kde. running 'fc-cache' by hand should do it. at least this helped me out (thanks to Oswald Buddenhagen). Dennis
icky, I'll look into why this happening with xfree
Seemant and I fixed this. It's in the new xfree 4.3.0-r2. Please confirm. (You may want to wait until r2 stabilizes and is unmasked...)
oops sorry -- I've changed 4.3.0 and 4.3.0-r1 as well. the fix was actually danarmak's I just checked it in, that's all.
