http://bugzilla.opensuse.org/show_bug.cgi?id=1200432 http://bugzilla.opensuse.org/show_bug.cgi?id=1200432#c11 --- Comment #11 from Nick Dordea <ndordea@gmail.com> --- (In reply to Fabian Vogt from comment #10)
(In reply to Nick Dordea from comment #9)
(In reply to Fabian Vogt from comment #8)
mysql.err clearly shows that the database got corrupted, there's unfortunately not much you can do at that point. Turning on recovery mode and trying to pull as much data is the best option, but might not result in a usable clone.
I agree that the error messages during akonadi initiated/controlled start point to corrupted data.
However, the akonadi database was available via mysql -h localhost -u root -p I can not explain how comes that after mysql -h localhost -u root -p , sql queries worked .... not only sql queries but also mysql-check did not point to any issues with table belonging to akonadi database .
Is akonadi ceating/using a proprietary database different from the akonadi database accessed via mysql -h localhost -u root -p ?
By default, akonadi's database can be connected to with mysql -S /run/user/1000/akonadi/mysql.socket
It's also possible that errors only appear with write accesses.
It is very strange complains that the connection fails while other user/utility has problems.
Could you please tell me if we can customize kmail to access akonadi database directly without database services provided via "akonadi" packages ?
There's a way, but the UI for that got removed so you'd have to edit ~/.config/akonadi/akonadiserverrc manually.
Thanks,
ND
--------------- I think that I included in the attachements some info about /run/user/1000/akonadi/mysql.socket In one instance it was not created .... due to some permission issues. Manually I changed the permissions of /run/user/1000 directory ....to allow changes for group + others The attempt to start kmail failed again, but the socket was created. Then I tried to get to akonadi db via Beeheper Studio tool [ found on snap ] that use the socket for connection ..... It failed ..... My feeling is that the socket might had some issues ... The changed /run/user/1000 permissions were changed back their default [ No access] . The most recent archive was 2 days prior the upgrade to 15.4 .... so I decided to restore db based on the archive ..... renamed akonadi_[imap...|maildir....|migration_agent... ] recreated [ via kmail] accounts [ as before ] import from archive .... back in business with out any problems ..... Maybe the fact that the socket was not created or created with tweaked permissions has something to do with the start/connect initiated/handled by akonadi applications. Hope that this d woulhelp. Regards. ND I -- You are receiving this mail because: You are on the CC list for the bug.