2026-02-20 обновил систему (p11). Akonadi утратил работоспособность (при загрузки системы с предыдущего снэпшота Akonadi работает нормально): ~/.local/share/akonadi/db_data/mysql.err: 2026-02-20 17:40:48 0 [Note] Starting MariaDB 11.8.6-MariaDB-alt1 source revision server_uid c3hre+ZoClu89bVg2IrQqQFTDLs= as process 5854 2026-02-20 17:40:48 0 [Warning] --innodb-file-per-table is deprecated and will be removed in a future release 2026-02-20 17:40:48 0 [Warning] option 'innodb-log-buffer-size': unsigned value 1048576 adjusted to 2097152 2026-02-20 17:40:48 0 [Note] InnoDB: Compressed tables use zlib 1.3.1 2026-02-20 17:40:48 0 [Note] InnoDB: Number of transaction pools: 1 2026-02-20 17:40:48 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions 2026-02-20 17:40:48 0 [Note] InnoDB: Using Linux native AIO 2026-02-20 17:40:48 0 [Note] InnoDB: innodb_buffer_pool_size_max=128m, innodb_buffer_pool_size=128m 2026-02-20 17:40:48 0 [Note] InnoDB: Initialized memory pressure event listener 2026-02-20 17:40:48 0 [Note] InnoDB: Completed initialization of buffer pool 2026-02-20 17:40:48 0 [Note] InnoDB: Buffered log writes (block size=512 bytes) 2026-02-20 17:40:48 0 [Note] InnoDB: End of log at LSN=324190365 2026-02-20 17:40:48 0 [Note] InnoDB: Opened 3 undo tablespaces 2026-02-20 17:40:48 0 [Note] InnoDB: 128 rollback segments in 3 undo tablespaces are active. 2026-02-20 17:40:48 0 [Note] InnoDB: Removed temporary tablespace data file: "./ibtmp1" 2026-02-20 17:40:48 0 [Note] InnoDB: Setting file './ibtmp1' size to 12.000MiB. Physically writing the file full; Please wait ... 2026-02-20 17:40:48 0 [Note] InnoDB: File './ibtmp1' size is now 12.000MiB. 2026-02-20 17:40:48 0 [Note] InnoDB: log sequence number 324190365; transaction id 131222 2026-02-20 17:40:48 0 [Note] Plugin 'FEEDBACK' is disabled. 2026-02-20 17:40:48 0 [Note] Plugin 'wsrep-provider' is disabled. 2026-02-20 17:40:48 0 [Note] InnoDB: Loading buffer pool(s) from /home/gleb/.local/share/akonadi/db_data/ib_buffer_pool 2026-02-20 17:40:48 0 [Note] Recovering after a crash using tc.log 2026-02-20 17:40:48 0 [Note] Starting table crash recovery... 2026-02-20 17:40:48 0 [Note] Crash table recovery finished. 2026-02-20 17:40:48 0 [Note] /usr/sbin/mysqld: ready for connections. Version: '11.8.6-MariaDB-alt1' socket: '/run/user/500/akonadi/mysql.socket' port: 0 (ALT p11) 2026-02-20 17:40:48 0 [Note] InnoDB: Buffer pool(s) load completed at 260220 17:40:48 260220 17:40:48 [ERROR] /usr/sbin/mysqld got signal 11 ; Sorry, we probably made a mistake, and this is a bug. Your assistance in bug reporting will enable us to fix this for the next release. To report this bug, see https://mariadb.com/kb/en/reporting-bugs about how to report a bug on https://jira.mariadb.org/. Please include the information from the server start above, to the end of the information below. Server version: 11.8.6-MariaDB-alt1 source revision: The information page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mariadbd/ contains instructions to obtain a better version of the backtrace below. Following these instructions will help MariaDB developers provide a fix quicker. Attempting backtrace. Include this in the bug report. (note: Retrieving this information may fail) Thread pointer: 0x7ffb94000c68 stack_bottom = 0x7ffbd25be000 thread_stack 0x49000 /usr/sbin/mysqld(my_print_stacktrace+0x2c)[0x55f7dc296bfc] /usr/sbin/mysqld(handle_fatal_signal+0x213)[0x55f7dbdf25a3] /lib64/libc.so.6(+0x3da20)[0x7ffbe1a30a20] Connection ID (thread ID): 6 Status: NOT_KILLED Query (0x7ffb94167d98): SELECT information_schema.REFERENTIAL_CONSTRAINTS.CONSTRAINT_NAME, information_schema.KEY_COLUMN_USAGE .COLUMN_NAME, information_schema.KEY_COLUMN_USAGE.REFERENCED_TABLE_NAME, information_schema.KEY_COLUMN_USAGE.REFERENCED_COLUMN _NAME, information_schema.REFERENTIAL_CONSTRAINTS.UPDATE_RULE, information_schema.REFERENTIAL_CONSTRAINTS.DELETE_RULE FROM inf ormation_schema.REFERENTIAL_CONSTRAINTS INNER JOIN information_schema.KEY_COLUMN_USAGE ON ( information_schema.REFERENTIAL_CON STRAINTS.CONSTRAINT_NAME = information_schema.KEY_COLUMN_USAGE.CONSTRAINT_NAME ) WHERE ( information_schema.KEY_COLUMN_USAGE.T ABLE_SCHEMA = ? AND information_schema.KEY_COLUMN_USAGE.TABLE_NAME = ? ) Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_i ntersection=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=o n,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_base d=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_ca che_bka=on,optimize_join_buffer_size=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condi tion_pushdown_for_derived=on,split_materialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_ having=on,not_null_range_scan=off,hash_join_cardinality=on,cset_narrowing=on,sargable_casefold=on Writing a core file... Working directory at /home/gleb/.local/share/akonadi/db_data Resource Limits (excludes unlimited resources): Limit Soft Limit Hard Limit Units Max stack size 8388608 unlimited bytes Max core file size 0 unlimited bytes Max processes 4096 5120 processes Max open files 3503 3503 files Max locked memory 1048576 2097152 bytes Max pending signals 39571 39571 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Core pattern: |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %d %F Kernel version: Linux version 6.12.68-6.12-alt1 (builder@localhost.localdomain) (gcc-13 (GCC) 13.2.1 20240128 (ALT Sisyphus 13 .2.1-alt3), GNU ld (GNU Binutils) 2.41.0.20230826) #1 SMP PREEMPT_DYNAMIC Fri Feb 6 20:37:37 UTC 2026
Покажите `cat /etc/os-release`. В p11 akonadi работает с MySQL: $ head -1 ~/.local/share/akonadi/db_data/mysql.err 2026-02-06T10:02:45.547755Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.42-alt1) starting as process 4096
ситуация в точности одинакова на K-станции и Starterkit. NAME="ALT Linux" VERSION="11" ID=altlinux VERSION_ID=11 PRETTY_NAME="ALT Starterkit 11 (Salvia)" ANSI_COLOR="1;33" CPE_NAME="cpe:/o:alt:starterkit:11" BUILD_ID="ALT 11.1" ALT_BRANCH_ID="p11" HOME_URL="https://en.altlinux.org/starterkits" BUG_REPORT_URL="https://bugs.altlinux.org/" LOGO=altlinux Да, я в курсе. Однако, рабочее окружение унаследовано (много лет!). Когда-то менялось на maria, когда-то на mysql. Терять наработанную почту невозможно, приходится в любом случае переключаться на maria. До последнего обновления (в т.ч. в Сизифе) это проблем не вызывало, Аконади работало нормально. После сегодняшнего обновления -- падение сервера. При перезагрузке с предыдущим снэпшотом системы (mariadb-server-10.11.15-alt1.x86_64) никаких проблем не замечено.
https://packages.altlinux.org/ru/tasks/408663/ попробуйте обновиться до этого задания.
*** This bug has been marked as a duplicate of bug 57864 ***
(Ответ для Alexander Makeenkov на комментарий #3) > https://packages.altlinux.org/ru/tasks/408663/ попробуйте обновиться до > этого задания. похоже, это работает. в течении дня буду смотреть подробнее