On samedi, 23 avril 2016 11.26:47 h CEST Dennis Gallien wrote:
On Fri, Apr 22 03:33:18 PM Bruno Friedmann wrote:
I don't think it could help a lot but. akonadictl vacuum akonadictl fsck
can't damage more.
The errors you have look like and older mysql/mariad db structure which have escape upgrade procedure ( rpm install running only those on system wide server )
Sorry I'm using a central postgresql instance, so I'm not aware of all the details for mysql/mariadb
but I would check the package of those and check the postin action to replay exactly the same to your local akonadi server.
kmail exporter can perhaps help you to dump the actual data, then create a fresh one and reimport (but don't trust this tool as a silver bullet, it lack certainly maturity) And nobody like to loose some setup.
Hope this give you some direction where to check --
Bruno Friedmann
Thank you for the suggestions, Bruno.
I tried akonadictl, as you suspected it did not help.
Sorry but I don't know what the "postin action" is or how to execute it.
The kmail export/import seems worth a try. When you write "create a fresh one" are you referring to deleting and reinstalling akonadi and kmail including removing the mysql database?
Thanks again for the assistance.
Dennis Gallion
Hi Dennis. When I'm talking about post action in rpm this is for example what happen in mariadb just after the installation %post %service_add_post mysql.service mysql@.service mysql.target mysql@default.service # Use %%tmpfiles_create when 13.2 is oldest in support scope %{_bindir}/systemd-tmpfiles --create %{_tmpfilesdir}/mysql.conf || : # SLE11 Migration support for i in protected tmp; do rmdir "$datadir"/.$i 2>/dev/null || : done # Remove any messages that could've been in place about the upgrade rm -f %{_localstatedir}/adm/update-messages/%{name}-%{version}-%{release} # During package rename (migration maria->mysql-community-server), # there might be config file move and we get rpmsave that we should keep if [ -f %{_sysconfdir}/my.cnf.rpmsave ]; then mv %{_sysconfdir}/my.cnf{,.rpmnew} mv %{_sysconfdir}/my.cnf{.rpmsave,} cat >> %{_localstatedir}/adm/update-messages/%{name}-%{version}-%{release} << EOF WARNING: %{_sysconfdir}/my.cnf.rpmsave file detected! This probably means that you are migrating from different variant of MySQL. Your configuration was left intact and you can see the new configuration in %{_sysconfdir}/my.cnf.rpmnew EOF fi # warn on first run datadir="`%{_bindir}/my_print_defaults mysqld mysql_server | sed -n 's|--datadir=||p'`" [ -n "$datadir" ] || datadir="%{_localstatedir}/lib/mysql" if [ -d "$datadir/mysql" ]; then touch "$datadir/.run-mysql_upgrade" fi if [ \! -f "$datadir/mysql_upgrade_info" ]; then if [ $1 -eq 1 ]; then cat >> %{_localstatedir}/adm/update-messages/%{name}-%{version}-%{release} << EOF %(cat %{_sourcedir}/README.install) EOF fi else MYSQLVER="`echo %{version} | sed 's|\.[0-9]\+$||'`" if [ -f "$datadir/mysql_upgrade_info" ] && \ [ -z "`grep "^$MYSQLVER" "$datadir/mysql_upgrade_info" 2> /dev/null`" ]; then cat >> %{_localstatedir}/adm/update-messages/%{name}-%{version}-%{release} << EOF WARNING: You are upgrading from different stable version of MySQL! Your database will be migrated automatically during next restart of MySQL. Before you do that make sure you have up to date backup of your data. It should be mainly in $datadir directory. EOF fi fi exit 0 This is valid for what is stored in /var/lib/mysql (/var/lib being %datadir) So once you have 2 times a copy of your pim stack data and also used once kmail exporter to be on a safe side you could do something like that datadir=~/.local/share/akonadi touch "$datadir/.run-mysql_upgrade" and also have a look at https://build.opensuse.org/package/view_file/server:database/mariadb/mysql-s... especially the upgrade part it should give you some clue of what to run to have an upgraded mysql. if, and please verify twice where the mysql data are located. cause I'm not able to have a mysql/mariadb to be 100% of the information I'm giving to you. You should also have a .my.cnf file at that location, it is worth to check and compare it against the system wide ... /me is happy to have always used system-wide server configuration, more easy to maintain, backup and upgrade. :-) Finally, if nothing works, then yes the absolute medics, is to logout, in console mode cleanup completely all trace of akonadi & kmail, korganizer, kontact and so from your .local and .kde4 if it still exist. then login, and try to use kmail importer, perhaps you will be enough lucky to be able to restore everything. the database being reinitialized new. Good luck -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org