akonadi 1.11.80 fails to start

Bug #1290717 reported by Bruno Patri on 2014-03-11
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Fix Released
akonadi (Ubuntu)
Harald Sitter
Harald Sitter

Bug Description


installations that used to be trusty and went through akonadi 1.11.80 (early beta upgrades to 14.04) have a broken database

adding a fix for these broken setups as per upstream request.

[Test Case]

* have a broken akonadi and upgrade
* install 14.04 alpha
* login and setup mails
* upgrade akonadi to [1]
* logout and login again, observe akonadi being broken
* upgrade to final+proposed
* akonadi should be repaired

[1] https://launchpad.net/ubuntu/+source/akonadi/1.11.80-0ubuntu3

[Regression Potential]


[Other Info]



akonadi fails to start since the update from 1.11.0 to 1.11.80
Full description in upstream bug report: https://bugs.kde.org/show_bug.cgi?id=331867

Download full text (25.6 KiB)

Starting kontact brings up a grayed out background for kmail. Indicating that Akonadi is not running. Pressing the Start button attempts to do an upgrade of the Database. It errors out and stops.

When I try to start akonadi manually I get the following:

Error code: 1048
DB error: "Column 'name' cannot be null"
Error text: "Column 'name' cannot be null QMYSQL3: Unable to execute statement"
Query: "INSERT INTO PartTypeTable (ns, name) VALUES (:0, :1)"
"Column 'name' cannot be null QMYSQL3: Unable to execute statement"
Update failed
Failed to commit transaction for database update
Unable to initialize database.
0: akonadiserver() [0x419587]
1: akonadiserver() [0x4197e2]
2: /lib/x86_64-linux-gnu/libc.so.6(+0x36ff0) [0x7f5e6e31bff0]
3: /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x39) [0x7f5e6e31bf79]
4: /lib/x86_64-linux-gnu/libc.so.6(abort+0x148) [0x7f5e6e31f388]
5: /usr/lib/x86_64-linux-gnu/libQtCore.so.4(_Z17qt_message_output9QtMsgTypePKc+0x102) [0x7f5e6fe05c82]
6: akonadiserver() [0x41b57d]
7: /usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN9QIODevice5writeEPKcx+0xb0) [0x7f5e6fea0460]
8: /usr/lib/x86_64-linux-gnu/libQtCore.so.4(+0x11ab2d) [0x7f5e6feafb2d]
9: /usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN11QTextStreamD1Ev+0x31) [0x7f5e6feb8711]
10: akonadiserver() [0x41e27b]
11: /usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN7QObject5eventEP6QEvent+0x24e) [0x7f5e6ff2ac0e]
12: /usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN16QCoreApplication14notifyInternalEP7QObjectP6QEvent+0x6d) [0x7f5e6ff124cd]
13: /usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData+0x1ed) [0x7f5e6ff15b2d]
14: /usr/lib/x86_64-linux-gnu/libQtCore.so.4(+0x1aaf53) [0x7f5e6ff3ff53]
15: /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x254) [0x7f5e6d9eae04]
16: /lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x49048) [0x7f5e6d9eb048]
17: /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x2c) [0x7f5e6d9eb0ec]
18: /usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x65) [0x7f5e6ff3f815]
19: /usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN10QEventLoop13processEventsE6QFlagsINS_17ProcessEventsFlagEE+0x2f) [0x7f5e6ff1109f]
20: /usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0x175) [0x7f5e6ff11395]
21: /usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN16QCoreApplication4execEv+0x89) [0x7f5e6ff16b69]
22: akonadiserver() [0x413c17]
23: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f5e6e306ec5]
24: akonadiserver() [0x414548]
ProcessControl: Application 'akonadiserver' returned with exit code 255 (Unknown error)
search paths: ("/usr/local/sbin", "/usr/local/bin", "/usr/sbin", "/usr/bin", "/sbin", "/bin", "/usr/games", "/usr/local/games", "/usr/lib/jvm/java-8-oracle/bin", "/usr/lib/jvm/java-8-oracle/db/bin", "/usr/lib/jvm/java-8-oracle/jre/bin", "/usr/sbin", "/usr/local/sbin", "/usr/local/libexec", "/usr/libexec", "/opt/mysql/libexec", "/opt/local/lib/mysql5/bin", "/opt/mysql/sbin")
akonadi.collectionattributetable OK
akonadi.collectionmimetyperelation ...

Schema version table = 24

Same issue here, on upgrade to kubuntu 14.04.

I did a little further checking. My original database that is currently failing has a column "name" varbinary(255), Null = no, Key =MUL.

As a cross check, I created a completely new DB and checked the layout. The new parttable does not have a name column.

If looks like an incomplete upgrade of the DB occurred.

I can confirm this bug happens when upgrading to newest KDE on ubuntu 14.04 beta

Problem has been nailed down to akonadi-server package being 1.11.80 version so its the beta for 4.13 KDE release... will try to downgrade to 1.11.0 and keep all updated

Changed in akonadi:
importance: Unknown → High
status: Unknown → New

I can confirm this error on beta of kubuntu 14.04. See attachment oof my try starting this via the console. Seems that I have to reconfigure/reset akonadi then?

Temporary solution for me to regain my Kontact-Suite was to rename ~/.local/share/akonadi to some other name, so that database was able to do a full new initialization.

The updated packages on 3/10 allowed Akonadi to start doing a data scan that never finished.
The packages released on 3.11 are back to the original issue.

Anders (eddiedog988) on 2014-03-13
Changed in akonadi (Ubuntu):
status: New → Confirmed

If you still run the stable database (from Akonadi 1.11) that you tried to update to 1.12, could any of you please open Akonadi Console, go to DB Console tab and run following query:


and post it's output here? The problem you ran into can only happen when some of they part names don't have NAMESPACE:NAME format, which should not happen, but it's possible that there are some legacy names I missed.

Daniel - As you requested


Ha! We found the culprit. GID is not supposed to be there, it's not a part. It looks like after an update you started KMail, but did not restart Akonadi, so KMail was sending the "GID" data, but Akonadi did not know it so it though it's a part type.

You can run following query in DB Console to get rid of it:

DELETE FROM PartTable WHERE name = 'GID';

This will fix the migration to 1.12 for you. I'll add a check to Akonadi to prevent this from happening to others.

That took care of the akonadi issue. Thanks Daniel !!

Changed in akonadi:
status: New → Unknown

Bug seems present in the final release 1.12.0.

Daniel's solution in Comment #9 solved the issue for me when I today upgraded from Kubuntu 13.10 to 14.04.

As of April 6th, the akonadi-server package 1.12.0-0ubuntu1 still triggered the exact GID issue as was reported in comment #8.

thanks, comment by Daniel Vrátil 2014-03-14 18:36:05 UTC

solved my issue

I have the same problem after upgrading to kubuntu 14.04 (akonadi-server 1.12.1).
How do I get akonadi console to run when any attempt to start it causes the conversion to run and it therefore fails?

I am having the same problem as well and I do not know how to fix it since akonadi console is also non-functional after the upgrade. Please, help!

OK, figured it out myself:

$ mysql --socket=/tmp/akonadi-${USER}.rp6WPG/mysql.socket
mysql> use akonadi
mysql> DELETE FROM PartTable WHERE name = 'GID';
mysql> quit
$ akonadictl start

That helped and akonadi database migration was successfully completed. KMail is now working again.

P.S. Nota, that exact name of your akonadi mysqld instance temporary socket file will be different, use the following command to find it out:

$ ps aux | grep mysqld

Then look for the line in the output with the following parameter: --datadir=/home/$USER/.local/share/akonadi/db_data/. Copy the --socket= parameter from the same line to start mysql textmode client above.

Ivan Adzhubey at comment 16, thank you very much!

(In reply to comment #16)
Ivan, you are a legend!

Experienced this issue upgrading from Kubuntu 13.10 to 14.04; Akonadi DB probably goes back to Kubunnto 12 era :
mysql> DELETE FROM PartTable WHERE name='GID';
Query OK, 48 rows affected (1.12 sec)

Can I add that having Akonadi as a single point of failure it's a real shame that it took me a day of poking around to find this bug report; no other user visible means of diagnosis etc.

I am glad my fix helped you.

Ivan @ Comment 16

Thanks again for the walk-through. This one was a real pain for me.


Download full text (3.8 KiB)

mysql> use akonadi
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables;
| Tables_in_akonadi |
| collectionattributetable |
| collectionmimetyperelation |
| collectionpimitemrelation |
| collectiontable |
| flagtable |
| mimetypetable |
| parttable |
| parttypetable |
| pimitemflagrelation |
| pimitemtable |
| pimitemtagrelation |
| resourcetable |
| schemaversiontable |
| tagattributetable |
| tagremoteidresourcerelationtable |
| tagtable |
16 rows in set (0.00 sec)

mysql> DELETE FROM parttable WHERE name = 'GID';
ERROR 1054 (42S22): Unknown column 'name' in 'where clause'
mysql> desc part
partTypeId parttable.data parttable.external parttable.partTypeId parttable.version parttypetable.id parttypetable.ns
parttable parttable.datasize parttable.id parttable.pimItemId parttypetable parttypetable.name
mysql> desc parttable;
| Field | Type | Null | Key | Default | Extra |


same here on gentoo with 4.13.0 + akonadi server 12.1

Git commit 4ca8b846baaad48ebbd723f6411f9571a3b0f5ad by Dan Vrátil.
Committed on 22/04/2014 at 09:28.
Pushed by dvratil into branch '1.12'.

Remove the invalid GID part from PartTable before starting PartTable migration

More people than we expected have invalid 'GID' part in their PartTable,
which breaks migration to schema 25, because it expects all part types
to have a valid name.

To work around this fact, we DELETE all parts with name 'GID' from PartTable
before starting the actual migration. This will not fix the migration for
people with other invalid parts, but I haven't heard of any such. To make
this completely bullet-proof, we would need to iterate through all entries,
which would be massively slower than current INSERT INTO ... SELECT FROM approach.

Distributions, this is a good choice for backporting into 1.12.1 ;-)
FIXED-IN: 1.12.2

M +9 -0 server/src/storage/dbupdater.cpp


Changed in akonadi:
status: Unknown → Fix Released
Changed in akonadi (Ubuntu Untitled):
status: New → Triaged
Changed in akonadi (Ubuntu Trusty):
status: Confirmed → Triaged
milestone: none → ubuntu-14.04.1
description: updated
Changed in akonadi (Ubuntu Trusty):
assignee: nobody → Harald Sitter (apachelogger)
Changed in akonadi (Ubuntu Untitled):
status: Triaged → Fix Committed
Harald Sitter (apachelogger) wrote :

  Uploading akonadi_1.12.1-0ubuntu1.1_source.changes: done.
Successfully uploaded packages.

uploaded to trusty. sru review pending.

also committed to bzr for 14.10

tags: added: kubuntu trusty

Hello Bruno, or anyone else affected,

Accepted into trusty-proposed. The package will build now and be available in a few hours in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in akonadi (Ubuntu Trusty):
status: Triaged → Fix Committed
tags: added: verification-needed
Download full text (26.5 KiB)

Hi ! (sorry for my bad english)

it'sn't solved forum after upgrade 4.12 to 4.13.

these is the konsole result :

jajax@portable:~$ akonadictl start
Starting Akonadi Server...
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
jajax@portable:~$ search paths: ("/usr/lib/lightdm/lightdm", "/usr/local/sbin", "/usr/local/bin", "/usr/sbin", "/usr/bin", "/sbin", "/bin", "/usr/games", "/usr/local/games", "/usr/sbin", "/usr/local/sbin", "/usr/local/libexec", "/usr/libexec", "/opt/mysql/libexec", "/opt/local/lib/mysql5/bin", "/opt/mysql/sbin")
Found mysql_install_db: "/usr/bin/mysql_install_db"
Found mysqlcheck: "/usr/bin/mysqlcheck"
akonadi.collectionattributetable OK
akonadi.collectionmimetyperelation OK
akonadi.collectionpimitemrelation OK
akonadi.collectiontable OK
akonadi.flagtable OK
akonadi.mimetypetable OK
akonadi.parttable OK
akonadi.parttypetable OK
akonadi.pimitemflagrelation OK
akonadi.pimitemtable OK
akonadi.pimitemtagrelation OK
akonadi.resourcetable OK
akonadi.schemaversiontable OK
akonadi.tagattributetable OK
akonadi.tagremoteidresourcerelationtable OK
akonadi.tagtable OK
mysql.columns_priv OK
mysql.db OK
mysql.event OK
mysql.func OK
mysql.general_log OK
mysql.help_category OK
mysql.help_keyword OK
mysql.help_relation OK
mysql.help_topic OK
mysql.host OK
mysql.ndb_binlog_index OK
mysql.plugin OK
mysql.proc OK
mysql.procs_priv OK
mysql.servers OK
mysql.slow_log OK
mysql.tables_priv OK
mysql.time_zone OK
mysql.time_zone_leap_second OK
mysql.time_zone_name OK
mysql.time_zone_transition OK
mysql.time_zone_transition_type OK
mysql.user OK
MySQL version OK (required "5.1" , available "5.5" )
Database "akonadi" opened using driver "QMYSQL"
checking table "SchemaVersionTable"
checking table "ResourceTable"
checking table "CollectionTable"
checking table "MimeTypeTable"
checking table "PimItemTable"
checking table "FlagTable"
checking table "PartTypeTable"
checking table "PartTable"

jajaX, your problem is unrelated to this one, please open a new report.

ok, no problem. sorry ;)

René Fritz (ubuntu-colorcube) wrote :

The package from trusty-proposed solved that problem for me. The server starts and a quick test shows that kmail works.

tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package akonadi - 1.12.1-0ubuntu1.1

akonadi (1.12.1-0ubuntu1.1) trusty; urgency=medium

  * Add upstream_Remove-the-invalid-GID-part-from-PartTable-before-st.patch
    Fixing databases that went through an akonadi 1.12 pre-release and ended up
    with a broken migration LP: #1290717
 -- Harald Sitter <email address hidden> Wed, 23 Apr 2014 12:21:40 +0200

Changed in akonadi (Ubuntu Trusty):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for akonadi has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

Changed in akonadi (Ubuntu):
milestone: ubuntu-14.04.1 → none
Changed in akonadi (Ubuntu Utopic):
status: Fix Committed → Won't Fix
Changed in akonadi (Ubuntu):
importance: Undecided → High
Changed in akonadi (Ubuntu Trusty):
importance: Undecided → High
Changed in akonadi (Ubuntu Utopic):
importance: Undecided → High
Changed in akonadi (Ubuntu):
status: Triaged → Fix Released
Changed in akonadi (Ubuntu Utopic):
status: Won't Fix → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.