From: otto@debian.org   
      
   Thanks Ben for the very thorough bug report!   
      
   What is the contents of /home/ben/.local/share/akonadi/db_data?   
   The first crash log (mysql-sad.err) has a lot of warnings about   
   missing files that are suspicious.   
      
   The error that is thrown in the 11.8.5 start that succeeded to start   
   anyway is very confusing, so I filed upstream a bug report about it:   
   https://jira.mariadb.org/browse/MDEV-38802   
   But this is clearly not the cause of the crash.   
      
   I also browsed upstream Jira for people reporting new crashes and   
   recent 11.8.6 commits for signs of relevant changes to   
   get_schema_privileges_for_show but I didn't find anything that looks   
   like this. I also checked the most recent entries at   
   https://tracker.debian.org/media/packages/a/akonadi/changelog-425.12.1-2   
   in case Akonadi has any major changes, but I don't see anything   
   special.   
      
   If there isn't something clearly broken with Akonadi and the data   
   directory or how MariaDB is started/restarted we should file a bug   
   report in MariaDB at jira.mariadb.org about a potential 11.8.6   
   regression.   
      
   > > In both cases seems MariaDB is doing crash recovery and then crashing   
   again.   
   >   
   > This is just because Akonadi keeps trying to restart. I'll attach a log   
   > showing the first crash after upgrade, without the crash recovery attempt.   
   >   
   > > The latter log has this line:   
   > > 2026-02-09 0:54:21 0 [ERROR] Can't open and lock privilege tables: Table   
   > > 'mysql.servers' doesn't exist   
   > >   
   > > But there is no way to tell if this is the cause or a symptom of the crash.   
   >   
   > I don't know why that is happening on my machine but not on Matthias's   
   > machine, but it may be unrelated to this bug. That message also appears   
   > when using the old version, which apparently works fine. I'll attach a   
   > log of that too, for comparison.   
   >   
   > For both logs, I've set log_warnings=10 in   
   > ~/.local/share/akonadi/mysql.cnf and disabled AppArmor enforcement. It   
   > doesn't look like there is a meaningful difference in the log files   
   > before the signal handler is invoked.   
   >   
   > I'm not sure why the included backtrace only goes as far as the signal   
   > handler. I've added core_file to mysql.cnf and obtained a more   
   > interesting backtrace with gdb.   
   >   
   > "gdb-full.bt" is the backtrace as recommended by   
   > https://mariadb.com/docs/server/reference/product-development/   
   ariadb-fault-finding/how-to-produce-a-full-stack-trace-for-maria   
   bd#getting-backtraces-with-gdb-on-linux   
   >   
   > Frankly, I can't comprehend that file, so I've also included a simple   
   > backtrace for Thread 1, as "gdb.bt"   
   >   
   > There does seem to be some hint of a cause in the backtrace - in 11.8.5,   
   > get_schema_privileges_for_show() didn't call acl_get_all3(). See Thread   
   > 1, frames #9 and #10.   
   >   
   >   
   > Ben   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)