[arch-general] maria update to 10.4.6 breaks akonadi's db

Oliver Jaksch arch-general at com-in.de
Fri Jun 28 08:12:36 UTC 2019


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


More information about the arch-general mailing list