Mageia 8: Akonadi did not start after upgrade

This forum is dedicated to advanced help and support :

Ask here your questions about advanced usage of Mageia. For example you may post here all your questions about network and automated installs, complex server configurations, kernel tuning, creating your own Mageia mirrors, and all tasks likely to be touchy even for skilled users.

Mageia 8: Akonadi did not start after upgrade

Postby cyril » Mar 29th, '21, 07:56

After upgrading from Mageia 7 to Magia 8 I was very surprised to find that Kontact would not start.
When I tried to open Kontact a message window displayed showing that Akonadi server was not starting.
Akonadi stores the data that is shared among the components of Kontact (mail, contact, calendar etc. )
To store the data Akonadi uses MariaDB database server.

I did a lot of internet searching and found that the problem was not with the upgrade to Mageia 8 but with the upgrade to MariaDB that was part of the process.
Many posts suggested that the problem was with the way newer versions of MariaDB define paths using "mariadb" instead of "mysql".
They found solutions by rolling back to an earlier version of MariaDB, running "mariadb-upgrade" and then installing the current version of MariaDB.

Fortunately I found a much simpler solution thanks to a post on an archlinux forum (those folks do great documentation!).
They said that as of MariaDB 10.5 the redo log could no longer be split into multiple files and suggested looking for files like "ib_logfile0" and "ib_logfile1" and renaming them like "ib_logfile0_old" so that there would be only one log file.

--- and it worked like magic ---

In /home/my_user_name/.local/share/akonadi/db_data/
I just renamed the ib_logfile0 to iblogfile0.old then the iblogfile1 disappeared, after a restart I checked using ksysgard and saw that there were now two instances of mysqld running, one for username = my_user_name (with parent = akonadiserver) and the regular one with username = mysql and parent = systemd

I started Kontact from krunner and everything looks good.
Wow! that sure beats a rollback and an upgrade.
I hope this helps anyone who may be having a similar problem after a MariaDB upgrade.
Posts: 6
Joined: Feb 5th, '14, 19:35

Re: Mageia 8: Akonadi did not start after upgrade

Postby doktor5000 » Mar 29th, '21, 18:02

Hi there, thanks for sharing this. Would be interesting to know whether this would have been fixed by e.g. akonadictl fsck or akonadictl vacuum
Cauldron is not for the faint of heart!
Caution: Hot, bubbling magic inside. May explode or cook your kittens!
Disclaimer: Beware of allergic reactions in answer to unconstructive complaint-type posts
User avatar
Posts: 16739
Joined: Jun 4th, '11, 10:10
Location: Leipzig, Germany

Re: Mageia 8: Akonadi did not start after upgrade

Postby cyril » Mar 29th, '21, 23:08

I was not aware of akonadictl fsck or akonadictl vacuum. The error messages indicated that MariaDB was closing the connection when Akonadi was starting.
It seemed like it was more of a db problem.
But... I liked the question so I did a little research to deepen my understanding. Here is what I found.

einar << an admin at says in a post:
Fsck checks for items that are referenced in Akonadi but no longer present in the sources (e.g. deleted mails).
Vacuum cleans out those entries, IIRC (fsck only moves them to a "lost+found" folder).

I don't really know anything about Akonadi but to me that indicates those options might need to use the ib_logfile but they would not manage it.

So I looked into the ib_logfile based on the suggestion from the ArchLinux forum that it was a MariaDB 10.5 change.
Here is what I found.
This guy has a detailed story about how he ran into a problem with it: ... -hole.html

MariaDB confirms that there is a change with v. 10.5 and there should not be a file named "ib_logfile1"

InnoDB Redo Log Overview:

The redo log is used by InnoDB during crash recovery. The redo log files have names like ib_logfileN, where N is an integer.
From MariaDB 10.5, there is only one redo log, so the file will always be named ib_logfile0.
If the innodb_log_group_home_dir system variable is configured, then the redo log files will be created in that directory. Otherwise, they will be created in the directory defined by the datadir system variable.
Posts: 6
Joined: Feb 5th, '14, 19:35

Return to Advanced support

Who is online

Users browsing this forum: No registered users and 1 guest