Description of problem: Akonadi fails to start with the following message in the .xsession-errors file: "Unable to add column 'version' to table 'SchemaVersionTable'. Query error: 'Table 'akonadi.SchemaVersionTable' doesn't exist QMYSQL: Unable to execute query'" Unable to initialize database. "[ 0: akonadiserver(_Z11akBacktracev+0x34) [0x451d84] 1: akonadiserver() [0x4520c1] 2: /lib64/libc.so.6() [0x3333c359a0] 3: /lib64/libc.so.6(gsignal+0x35) [0x3333c35925] 4: /lib64/libc.so.6(abort+0x148) [0x3333c370d8] 5: /lib64/libQtCore.so.4(_Z17qt_message_output9QtMsgTypePKc+0x74) [0x3ade071234] 6: akonadiserver(_ZN15FileDebugStream9writeDataEPKcx+0x9b) [0x453d9b] 7: /lib64/libQtCore.so.4(_ZN9QIODevice5writeEPKcx+0xb4) [0x3ade10b294] 8: /lib64/libQtCore.so.4() [0x3ade115f3f] 9: /lib64/libQtCore.so.4(_ZN11QTextStreamD1Ev+0x3b) [0x3ade11e53b] 10: akonadiserver(_ZN7Akonadi13AkonadiServerC1EP7QObject+0x5e0) [0x455f60] 11: akonadiserver(_ZN7Akonadi13AkonadiServer8instanceEv+0x47) [0x457037] 12: akonadiserver(main+0x183) [0x44b483] 13: /lib64/libc.so.6(__libc_start_main+0xf5) [0x3333c21735] 14: akonadiserver() [0x44bde1] ] " ProcessControl: Application 'akonadiserver' returned with exit code 255 (Unknown error) Version-Release number of selected component (if applicable): akonadi-1.8.0-1.fc17.x86_64 How reproducible: always Steps to Reproduce: 1. akonadictl start Additional info: Fedora 17 and updated kde using updates-testing. The first problem was that yum wanted to remove the mysql server due to dependencies. I cancelled and reran yum with --setopt=clean_requirements_on_remove=0. Then akonadi faied to start with: Test 6: ERROR -------- MySQL server default configuration not found. Details: The default configuration for the MySQL server was not found or was not readable. Check your Akonadi installation is complete and you have all required access rights. I copied the file with: sudo cp /usr/share/kde4/apps/digikam/database/mysql-global.conf /etc/akonadi Now I get the error I'm reporting in this bug. Here's what I have installed now: akonadi-1.8.0-1.fc17.x86_64 kdepimlibs-4.9.1-3.fc17.x86_64 kdepimlibs-akonadi-4.9.1-3.fc17.x86_64 kdepim-libs-4.9.1-1.fc17.x86_64 kdepim-4.9.1-1.fc17.x86_64 kdepim-runtime-libs-4.9.1-1.fc17.x86_64 kdepim-runtime-4.9.1-1.fc17.x86_64 Here's /etc/akonadi/mysql-global.conf: # # Global Akonadi MySQL server settings, # These settings can be adjusted using $HOME/.config/akonadi/mysql-local.conf # # Based on advice by Kris Köhntopp <kris> # [mysqld] skip_grant_tables skip_networking # strict query parsing/interpretation # TODO: make Akonadi work with those settings enabled #sql_mode=strict_trans_tables,strict_all_tables,strict_error_for_division_by_zero,no_auto_create_user,no_auto_value_on_zero,no_engine_substitution,no_zero_date,no_zero_in_date,only_full_group_by,pipes_as_concat #sql_mode=strict_trans_tables # use InnoDB for transactions and better crash recovery # TODO by foerster, This doesn't work - we need the default storage engine #default_storage_engine=innodb # case-insensitive table names, avoids trouble on windows #lower_case_table_names=1 character_set_server=latin1 collation_server=latin1_general_ci table_cache=200 thread_cache_size=3 log_bin=mysql-bin expire_logs_days=3 #sync_bin_log=0 # error log file name, relative to datadir log_error=mysql.err log_warnings=2 # log all queries, useful for debugging but generates an enormous amount of data #log=mysql.full # log queries slower than n seconds, log file name relative to datadir log_slow_queries=mysql.slow long_query_time=1 # log queries not using indices, debug only, disable for production use log_queries_not_using_indexes=1 # maximum blob size max_allowed_packet=32M max_connections=256 # makes sense when having the same query multiple times # makes no sense with prepared statements and/or transactions query_cache_type=0 query_cache_size=0 innodb_file_per_table=1 innodb_log_buffer_size=1M innodb_additional_mem_pool_size=1M # messure database size and adjust # SELECT sum(data_length) as bla, sum(index_length) as blub FROM information_schema.tables WHERE table_schema not in ("mysql", "information_schema"); innodb_buffer_pool_size=80M # size of average write burst, keep Innob_log_waits small, keep Innodb_buffer_pool_wait_free small (see show global status like "inno%", show global variables) innodb_log_file_size=64M innodb_flush_log_at_trx_commit=2
Rex points out that installing akonadi-mysql will supply the missing conf file. Furthermore, I found this in my local mysql.conf file: #lower_case_table_names=1 I uncommented it and akonadi starts without the error. That fixes the Unable to add column 'version' to table 'SchemaVersionTable' symptom. I'm closing this bug NOTABUG, but the upgrade should have worked properly without me having to manually install akonadi-mysql. It's also a mystery to me how my local mysql.conf got the statement commented out -- I don't even know if it was there before the upgrade.
I think what we found here was a bug in the yum feature enabled with clean_requirements_on_remove=1 (which is not default on, by the way). The normal upgrade path *should* have gone something like this: akonadi-1.7.x => akonadi-1.8.x + akonadi-mysql-1.8.x since akonadi-mysql includes the rpm tags: Obsoletes: akonadi < 1.7.90-2 Requires: %{name}%{?_isa} = %{version}-%{release} except what happened instead was clean_requirements_on_remove=1 kicking in that akonadi-1.7.x Requires: qt4-mysql mysql-server and akonadi-1.8.x does not and it decided to remove those apprently no-longer-needed dependencies. So, in short, the bug seems to be that clean_requirements_on_remove=1 apparently does not take Obsoletes into account before calculating what can be removed. reopening and reassigning to yum.
reassigning for real, apparently that clean_requirements_on_remove is too agressive, and doesn't take Obsoletes into accouny. See comment #2 for further detail.
Just so you know, I cancelled the upgrade when I saw it wanted to erase mysql. I then reran the command with --setopt=clean_requirements_on_remove=0 but this still resulted in akonadi-mysql missing in the upgrade. I suspect that's because I said `update kde\*' on the yum command line. Yes?
Oh, so my analysis was incorrect, thanks for the clarification. so yeah, since you only explicitly asked for kde\* that's exactly what you got, and akonadi-1.8 got pulled in via other versioned dependencies... I don't think we can expect Obsoletes to get proper treatment in that scenario. :( I guess back to NOTABUG we go.
> I suspect that's because I said `update kde\*' on the yum command line. Yes? Probably. That's the wrong way to do selective updates (also because kde\* is neither a necessary nor a sufficient criterion for a package to be a part of the KDE software compilation!), what you really want is: yum install yum-security yum --enablerepo=updates-testing --advisory=FEDORA-2012-14137 update (and yes, yum-security actually works just fine on non-security updates like this one ;-) – it adds that --advisory switch). But Rex, is making akonadi-mysql optional really worth all that pain?
We use Obsoletes to help upgrade paths all the time. If we're going to start doubting it's usefulness, then we have bigger problems.