On my new computer using Leap 42.2, I have a big problem with Akonadi… It freezes at startup, which in turns freezes Kmail (and is seriously slowing down the startup of the session, it seems)…
I have tried everything I could to fix the problem, using “fsck” and “vacuum” from akonadictl, purging the config and database of both Akonadi and Kmail, I even updated to 16.08.2 from the KDE:Applications repo to see if the bugfixes would solve it… But everytime, the issue is coming back (most often, after I configure my IMAP accounts, but once it happened even before I configured anything).
I’m a bit clueless. The log is acting crazy, but nothing recent and relevant come up in Google using the error messages: http://pastebin.com/f6G6a4mt
Any idea about how I could fix that? I’d very much like to avoid reinstalling because I don’t know whether it’ll fix the problem and it’ll be time consuming to reconfigure everything…
The weird thing is that the same accounts and software works seemlessly on Tumbleweed on my laptop (not much differences in KDE between 42.2 and TW at that point, I’d expect)
EDIT: The “D-Bus communication errors” seem to be triggered when I try to open Kmail. On the GUI, nothing happens for quite a long time (during which those messages are printed in Konsole) and finally, Kmail opens with the message: “The Akonadi personal information management is not operational”)
[HR][/HR]You could consider raising a Bug Report: <https://bugzilla.opensuse.org/>.
[HR][/HR]Looking at trace you supplied in your log, it seems that, there may be a deeper security issue in one of the system versions currently being tested but, until we know which Test Version you’ve installed, we cannot determine if this is a current (RC1) issue or, a Beta Test issue (which may, or may not, have been resolved).
Huge update today (seems most of the packages were rebuilt for some reason? And Plasma went to 5.8.2), this seems to have solved my problem with Akonadi (for now?).
I suspect some problematic system config file was re-written (the problem didn’t appear to be specifically linked to my user, a test user encountered the same issue). Or maybe the problem was Plasma-related, but that seems dubious…
Leap 42.2 Release Candidate 2 was published yesterday – it may be that you got “auto-magically” updated to the latest Release Candidate . . .
You do not mention if you performed a “default” installation or not.
[HR][/HR]Assuming a “default” installation with freshly/newly formatted partitions and a Btrfs system partition, there is an issue with “fresh” installations which I’ll, hopefully, investigate later today – there seems to be a “Btrfs initialisation” issue with “fresh” installs which consumes 100% CPU until it completes – and nobody else seems to have noticed that yet (most folks seem to do a “zypper dup” on existing, initialised, file systems) . . .
Yes, I realised that after writing the message. It was a mere “zypper up”.
Not sure what you mean by “default”… My install has been in ext4 with a partition for /, one for /home and a last one for the data. I’ve also setup a SWAP partition and a EFI one. Is that what you asked?
No offense, but this is a weird bet? I just manually configured the install to be that way. My plan was to keep the computer on Leap 42.2, so this was not a “default/test” install, if this is what you thought.
Anyway, the problem seems to have definitely been solved by going to the RC2 (a few reboot without issue now), so I guess we won’t really know what happened… Thank you for your help!
Please take a look at the Leap 42.2 RC2 discussion thread and, especially the mention of a couple of Bug Reports raised this morning.
Hopefully, due to the effort being expended on Leap 42.2 Beta and Release Candidate testing, the “production” Release coming soon will be acceptable for a lot of folks.
You can please some of the people all of the time, you can please all of the people some of the time, but you can’t please all of the people all of the time.
John Lydgate (poet); used by Abraham Lincoln.
