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 :)