getting rid of akonadi
 

I don't use kontact cos it's still not reliable enough for me, so in the past I have just disabled akonadi (and nepomuk) in the checkboxes in systemsettings.
In Slackware though, this doesn't seem to do it, as each boot akonadi starts up again, runs for 20secs or so, then gives me error messages.

I tried removing the akonadi package with pkgtool, but this seemed to cause other hard-to-nail-down kde probs which required a reinstall in the end.

So, anyone know how I can either get rid of it, or make it be quiet?

This is the error message if anyone wants to take a look.

Cheers

Spoov

I just use removepkg and the thing goes away (look and see if it's still in /var/log/packages). Might want to init 3 so KDE isn't running when you do it.

i'm kind of reluctant to do that again cos i started getting weird probs last time; multimedia probs and things taking ages to start up. I did remove it using a konsole terminal though, so maybe that was the prob. Or it might have been an unrelated problem i spose..

First thing I do after installation (after giving it one try) is removepkg that thing. I don't really know just what the heck it's supposed to (and I suspect I don't want it doing whatever it does actually do in any event). Haven't had any problems with anything (in 32-bit and 64-bit installations) after removing it. Just shut down X (so you've got the white-on-black console), log in as root, removepkg and startx again.

What the heck, remove it and if things get weird reinstall it from the distribution media, eh?

Should work, give it a shot.

Well I did it, and it seems fine, thanks both.

I had a bit of trouble with X though again - how are you supposed to 'shut down' X properly? I logged out to kdm, then pressed ctrl+alt+F1, which opened up a console but with no prompt. To get a prompt to login I needed to open another console (tty?) with ctrl+alt+F5, which worked ok, but then i couldn't restart X 'cos it said there was already an X running (on the F1 login?).
I'm also finding that inittab needs to be set to default init 5, otherwise if i start in init 3 I can't then startx, it just gives errors leaving me trapped in consoles.

Something dodgy with my X maybe?

In Slackware, runlevel 5 behaves exactly the same as runlevel 3. So... if you experience differences that is an indication of a misconfigured system.
In runlevel 3 (or 5) you should be able to use "startx" to start X. If you get errors instead, please post those errors.

Shutting down X when you are in runlevel 4 can mean a few things.

First, if you mean you want to go back to graphical mode (runlevel 3) then you can press Ctrl-Alt-F6 while in X, which opens the one console (tty) which Slackware keeps open for cases like this. There you can logon as root, and issue "init 3" which will end your X session and kill all programs running in that session. If you then type "init 4" you will be transported back to a fresh KDM login screen. Or if instead you type "startx" you will land directly into a new X session.

Alternatively if you just want to re-initialize the X-server you can logout in runlevel 4, which drops you to the KDM login manager. There you press Ctrl-Alt-Backspace to forcibly kill the X-server. The init system will than restart KDM for you. This is the fast but ugly way.

Eric

Sorry my mistake that should read

Still got my redhat on, thinking init 5 was default x runlvl. ;)

I do need to set inittab to 4 as default though, cos if i try to default to 3 i just get a black screen at bootup, no cursor even. I thought this was an X fault at first but it can't be cos X isn't started in runlvl 3 is it? I think it's something to do with the rc.udev script, cos if I de-executable that, then I can then boot into init 3, but then i can't startx.

Something is definately not right, and i'm not entirely happy with this workaround either (having to default to runlvl 4) or no console even.

writing as I think, I suppose it makes sense, if i disable udev it won't find my screen hardware, hence startx will then throw up an error. So the real problem is why the udev script if executable causes a blank screen.

sorry for the ramble. Any ideas?

On my laptop I also only get a black screen in runlevel 3 unless I pass vga=771 to lilo, then runlevel 3 works fine.

Strangely Jackhair, you commented on my original post on this topic - http://www.linuxquestions.org/questi...13-1-a-822890/ Except you wrote vga=773 in that post rather than 771. I followed your advice, using vga=773 (grub instead of lilo though) and that was the only way I could get it to boot even in runlvl 4!!

I will try 771 instead, see if that makes any difference.



EDIT - Makes no difference, I still can't boot straight into init 3 without disabling udev.

Ah that's right I actually meant to type 773 here too. To bad it doesn't work for you, guess you'll have to wait for someone with more knowledge about these problems.

What video card do you have? What drivers are you using? Is KMS involved?

"vga = ask" in lilo.conf (remember to rerun lilo) is the failsafe option, which uses no framebuffer at all. However, depending on your graphics card and how it is setup, it may ignore your lilo options and have to be adjusted differently (I know intel is problematic, but I cannot remember if ATI has issues with KMS by default as well).

i'm using a laptop with integrated intel gm965 graphics chip. drivers are built in to the kernel as far as I know, i've never had to mess with additional drivers before.

As for KVM, really no idea sorry, i'm using the standard as-shipped 2.6.33.4-smp kernel if that helps?

I got this from lshw -

See this thread and other KMS threads (just a search away) for some help (though I don't have an intel card so I don't know if you will find the ultimate answer to your problem or not).

Great T3Slider thanks, it appears that was the problem, and a pretty common one.

So I have got it working, booting in rl3 and allowing startx. I don't know if I correctly understand what I did though, as I seem to have prevented KMS loading, then changed driver anyway? I would've thought one or the other?? I did the following -

1) I added "nomodeset" to grub.cfg, which I believe stops KMS loading?
2) I also removed all reference to vga=???, which then allows automatic screen size detection??
3) used pkgtool to remove the xf86=intel video driver and then install the older one. Cos the newer one isn't compatible with...?? KMS?

Is this the best way to go about changing modules? I would have tried modprobe -r or rmmod but I couldn't find a module which related to xf86=intel using lsmod so I just removed the whole package.

Cheers

I am getting the same akonadi errors, "not registered with D-Bus".
I do not have a clue as to what it wants (yet).
My Akonadi errors show up in a window when KDE starts up.
Akonadi puts up a progress slider, then takes a while to try to start itself, then aborts with these error messages, then repeats.
It was going on its third or fourth attempt to start when I finally intervened by clicking on a cancel button on the error messages.
That finally stopped it and let the rest of KDE finish loading.

I am planning on doing a removepkg on it too, because whatever PIM functions it performs are rather vague and probably unnecessary.
The pkgtool description could have been more informative.
I only installed in a desperate attempt to make some other KDE errors go away. This KDE 4 is really screwed up.

I got that "things taking forever to start up" problem too.