The solution found at https://bbs.archlinux.org/viewtopic.php?id=184192 fixed 'em all. Tried tipp #1 (backup, restore, upgrade) on two machines, which worked impeccably, but resetted some settings of kmail to default. Tipp #2 (create db mysql, upgrade) on the 3rd machine was the easiest one and left akonadi usable in a sec. No more errors nor problems left; problem was the missing of db mysql/* inside ~/.local/share/akonadi/db_data/ On Friday, 28 June 2019, 10:12:36 CEST you wrote: > Little progress... > The man of mysql_upgrade states it: > > --datadir=path > Old option accepted for backward compatibility but ignored > > > So I did a fresh login and let akonadi/mariadb starts. I then stopped > akonadi and re-used it's socket: > # mysqld --defaults-file=$HOME/.local/share/akonadi/mysql.conf -- > datadir=$HOME/.local/share/akonadi/db_data/ > --socket=/tmp/akonadi-XXX.n8sdoz/ mysql.socket > --pid-file=/tmp/akonadi-XXX.n8sdoz/mysql.pid > > I can connect to the mariadb instance now and let some commands fly, > according to https://mariadb.com/kb/en/library/mysql_upgrade/ : > > # mysqlcheck --no-defaults --check-upgrade --auto-repair --all-databases -- > socket=/tmp/akonadi-XXX.n8sdoz/mysql.socket > > # mysqlcheck --no-defaults --all-databases --fix-db-names --fix-table-names > -- write-binlog --socket=/tmp/akonadi-XXX.n8sdoz/mysql.socket > > # mysqlcheck --no-defaults --check-upgrade --all-databases --auto-repair -- > write-binlog --socket=/tmp/akonadi-XXX.n8sdoz/mysql.socket > > The output is always > > > 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.relationtable OK > > akonadi.relationtypetable OK > > akonadi.resourcetable OK > > akonadi.schemaversiontable OK > > akonadi.tagattributetable OK > > akonadi.tagremoteidresourcerelationtable OK > > akonadi.tagtable OK > > akonadi.tagtypetable OK > > But when ending this mariadb instance and restarting akonadi, the horror of > errors from post #1 starts all over again :( > > On Friday, 28 June 2019, 08:55:24 CEST you wrote: > > On Friday, 28 June 2019, 07:49:16 CEST you wrote: > > > On Fri, 28 Jun 2019, at 07:41, Oliver Jaksch via arch-general wrote: > > > > Updated three of my KDE clients by terminal (not logged in by display > > > > manager/DM) and ran > > > > > > > > # systemctl restart mariadb.service && mariadb-upgrade -u root > > > > -p > > > > > > This doesn't affect akonadi's data since it is located someplace else at > > > a > > > > > > non-system location: > > > /usr/bin/mysqld > > > --defaults-file=$HOME/.local/share/akonadi/mysql.conf > > > > > > --datadir=$HOME/.local/share/akonadi/db_data/ --s > > > ocket=/tmp/akonadi-xxx.LdhzVw/mysql.socket > > > --pid-file=/tmp/akonadi-xxx.LdhzVw/mysql.pids > > > > Yes, I know that, but I thought that akonadi would run a similar upgrade > > by > > itself when started and necessary. Wasn't that the case in the past? > > > > > I suggest you look into actually upgrading akonadi's DB first. For that, > > > you probably can pass --defaults-file and --datadir as-is to > > > mariadb-upgrade (and the upgrade should be executed as the user akonadi > > > is running as, not root). > > > > Thanks for that good starting point. But, alas, it gives me a > > # mysql_upgrade: the '--datadir' option is always ignored > > > > ...but this gives me hope for further investigations (=search engine). > > Will > > try and report; chances are good as it's friday and it's quiet today :)
