[gentoo-amd64] Re: Re: Re: No kdm after 2005.0 upgrade

[Duncan]

Daiajo Tibdixious posted
<a4a9bfcb0601310120t2c38c7b3l861a937a2dbd2a40@××××××××××.com>, excerpted
below,  on Tue, 31 Jan 2006 20:20:37 +1100:

> Anyway, not solved, just a different problem. When I correct DISPLAYMANAGER,
> nothing comes up, no X, no XDM, no KDM.
> If I enter "kdm" in bash, with no X, it starts X and brings up KDM.
> I'm sure under 2004.3 I changed the run level in /etc/inittab, however
> 3,4,& 5 are all "default" and I don't understand where X is started.
> I'd create my own /etc/init.d/kdm module if it weren't for the hoops
> xdm seems to have to run thru with its special "a" runlevel. I've
> debugged /etc/X11/startDM.sh
> ${svcdir} is fine and ${svcdir}/options/xdm/services has /usr/bin/kdm.
> If I do
> $ /sbin/start-stop-daemon --start --exec /usr/bin/kdm
> it exits with 0 but doesn't start anything. If I
> $ . /etc/X11/startDM.sh
> It gives a non-specific error message "ERROR: could not start the
> Display Manager..."

Hold on a moment!!!  /usr/bin/kdm ????

Try equery b /usr/bin/kdm (equery is part of gentoolkit, which I
recommend merging and investigating if you don't have it). I don't have
that file, even with kdm merged (altho mine's the KDE 3.5 version).  Maybe
that's your problem.

Here, all the KDE-core stuff is located in /usr/kde/<major.minor>,
thus for KDE 3.5, it's /usr/kde/3.5 .  The path is adjusted accordingly by
the initscripts (in this case by /etc/env.d/45kdepaths-major.minor, so for
3.5, /etc/env.d/45kdepaths-3.5) to include /usr/kde/<major.minor>/bin (and
sbin for the root user).

Where did your /usr/bin/kdm come from?

Also, at least with baselayout-1.12.0_pre's, it's
/${svcdir}/options/xdm/service (not services).  Whether it's "service" or
"services" or something else, is set in /etc/init.d/xdm, "start"
function, "save_options" line (the setting there should match the one in
the myexe local variable in the stop function).

Again, where's the /usr/bin/kdm coming from, this time as the contents of
your "xdm/service(s) file, not the /usr/bin/kdm file itself? Take a look
at the setup_dm function in /etc/init.d/xdm.  It sets the content using
"which kdm".  If you have some strange /usr/bin/kdm that appears first in
your path, that shouldn't be there, "which kdm" will return it instead of
the one later in your path, that's /supposed/ to be there, as
/usr/kde/3.<whatever>/bin/kdm.

I'm guessing the problem now, therefore, is an old /usr/bin/kdm from who
knows /how/ old a KDE, which is failing, as the KDE it belongs to is no
longer there.  Remove it, and you'll probably get the /correct/ kdm in
/usr/kde/3.<whatever>/bin.

As for that "a" runlevel and how everything is started, the explanatory
note in /etc/init.d/xdm, perhaps along with "man telinit" and "man
inittab" to understand what the "a" runlevel is all about, should help
answer some questions.

> The only errors I can see in /var/log/Xorg.o.log are
> (EE) Unable to locate/open config file
> (EE) open /dev/fb0: No such device
> The first one has always come up (it loads a default config file later),
> and the second is a lie:
> # file /dev/fb0
> /dev/fb0: character special (29/0)

This probably isn't related to your current issue, but you are aware that
under normal circumstances, using a framebuffer (/dev/fb#) in console
mode, rather than the standard VGA text console kernel option, gives you
console mode flexibility at the expense of X mode flexibility and
acceleration, correct?  It sounds like your users spend most of their time
in X, so unless you have a rather strange video card, I'm not sure this is
the best option.  Likewise, just letting X choose its own defaults instead
of setting up an xorg.conf works, but is probably non-optimal (altho with
framebuffer your options are rather limited, so if you are using that, an
xorg.conf may not be worthwhile).

In any case, no-such-device errors can be permission errors, meaning no
/access/ to the device, rather than literally, no-such-device.  The device
would normally be accessed as root, so that shouldn't be the problem, but
locking issues might be, or it could be that X is trying to start before
the device file has been created.  As I'm not running a framebufferdev
here, it's a bit hard to troubleshoot beyond that, but perhaps that'll
help you some way.

> I tried setting XSESSION again, which gave me "setting up kdm..." in the
> startup messages, but did not start kdm.

That's strange.  I believe XSESSION, if set correctly, would boot directly
into KDE, not KDM.  Why would it need to setup KDM?  Maybe there's another
layer of indirection there than I'm aware of, and your KDM problems are
affecting it as well.  You DID set XSESSION="kde-3.4" (or whatever),
correct?  I don't believe it needs the micro-version, and it should
/certainly/ not be set to "kdm" or similar, but to "kde-3.#", where # is
of course your minor-version.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@g.o mailing list