On Mon, 2002-10-14 at 02:15, russell davie wrote:
> thanks for the clues on urpmi, went smoothly
> its nearly done, and xfs starts and stops properly
> xserver now only is stopped by a failing dcopserver
> the error message is a red or blue screen (yep, KDE
> has its own BSOD!)
> with a dialog box:
> could not read connection list
> /root/DCOPserver_localhost.localdomain_:0
> please check that DCOPserver is running
hmm. ok. It doesn't have anything to do with the problem (I think), but
I'd suggest logging into kde as normal user and then suing to do any
admin work.
urpmi may well fix this (it could just be a library problem or
something) - were you getting it to upgrade kde? (I can't remember).
Just to be sure that we've got X fixed, can you try logging in with a
different window manager? WindowMaker say? I don't know if you have it
installed or not, so do 'urpmi -v WindowMaker' - It's not very big. Now,
I'm not sure which versions of what scripts you have. On my Mandrake 9.0
box here you set which window manager to start by changing the contents
of the ~/.desktop file. So, to make it start window maker you'd just
have a single line in that file that says:
DESKTOP=WindowMaker
and then running startx should make it "just work" (don't know if you've
used window maker, but click on the desktop with various buttons to make
it do stuff).
If it does not "just work", then here's a hideous way to try it out
anyway:
X & sleep 10 && /usr/X11R6/bin/wmaker -display 0:0
If that works then we can safely ignore any X server problems in fixing
this dcopserver thing, but as I say above, urpmi may just fix it (I hope
so!)
>
> running dcopserver from /usr/bin returned:
> Aborting. $DISPLAY is not set.
hrmm. ok, that's because you ran it from console (the DISPLAY variable
is supposed to contain an address for the xserver to start programs on.
If an xserver is running, it will set this variable). Does anyone on
slug know if dcopserver leaves any logs lying around? I don't use kde,
so I don't know much about it. I understand that dcopserver is a corba
server thing, so I'm not surprised that kde won't work without it.
Now, as I recall I suggested you switch to runlevel 3 to debug this
stuff. Once kde is working from startx again, you might want to switch
back to runlevel 5 (you were running kdm, weren't you?). There's two
ways to do this:
1. Just edit the inittab file so that the default runlevel is 5 rather
than 3:
id:5:initdefault:
2. Get urpmi to get the latest version of the init scripts in which the
dislpay manager is a service and enabled in runlevel 5 by default, and
then edit inittab :) - 'urpmi initscripts' will install the latest
version of the initscripts.
Just on this: there's probably not any huge practical gain to running
the latest initscripts - with the possible exception being that it will
let you start and stop the display manager independent of runlevel. But
being on the current initscripts is probably a good idea, because
they've fixed bugs and because there are now some mandrake tools that
depend on the initscripts being a certain version (of course, urpmi will
pick that up, but, do it now and make sure it's working before playing
with such tools and you'll have one less (fairly important) thing to
trouble shoot with problems in the future)
you might also want to ensure that xfs *is* being started in both
runlevel 3 and 5. Now, assuming that urpmi hasn't gone and upgraded it
away - there's a little tool called "ntsysv". You might need to urpmi
it, it wasn't installed by default on my mandrake 9.0 installs. ntsysv
lets you tick little checkbox things to say what scripts are to be
started in what runlevels. You'll need to run it twice, once for
runlevel 3 and once for 5 (and there is a command line paramater that
'ntsysv --help' will tell you to let you specify which runlevel you want
to edit.) - just check that xfs is enabled in both. It's an ncurses app,
so you just run it from console.
Alternatively, if window maker starts up, there's a thing inside
'drakconf' that will let you set this stuff. You'll need to upgrade
drakconf if you upgrade initscripts (I'd be interested to know if urpmi
does resolutions that way... I've never tried it). So if you walk this
path: 'urpmi -v DrakConf'
hopefully everything is smooth sailing from here on. Keep us posted :)
James.
--
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug
