I was using Plasma 6.5.5 on Wayland in a Fedora 43 KDE installation. In Konsole, I ran a dnf offline upgrade with updates-testing enabled using sudo dnf offline-upgrade download --refresh sudo dnf offline-upgrade reboot The update included mariadb-10.11.16-1.fc43.x86_64. On the next boot after the update, I started Plasma from sddm. A crash notification from akonadi server was shown three times. coredumpctl showed that mariadbd or mysqld crashed three times. The trace showed the crash involved my_hash_first possibly with a null pointer to a function in frame 0. Core was generated by `/usr/libexec/mysqld --defaults-file=/home/matt/.local/share/akonadi/mysql.conf --datadir=/home/matt/.local/share/akonadi/db_data/ --socket=/run/user/1000/akonadi/mysql.socket --pid-file=/run/user/1000/akonadi/mysql.pid'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000000000000000 in ?? () [Current thread is 1 (Thread 0x7f2b6425f6c0 (LWP 2969))] (gdb) bt #0 0x0000000000000000 in ?? () #1 0x0000559b063ed499 in my_hash_first (hash=0x559b44ba7108, key=0x7f2b642594a0 "", length=20, current_record=0x7f2b6425949c) at /usr/src/debug/mariadb10.11-10.11.16-1.fc43.x86_64/mysys/hash.c:263 #2 my_hash_search (hash=0x559b44ba7108, key=0x7f2b642594a0 "", length=20) at /usr/src/debug/mariadb10.11-10.11.16-1.fc43.x86_64/mysys/hash.c:236 #3 hash_filo::search (this=0x559b44ba7090, key=0x7f2b642594a0 "", length=20) at /usr/src/debug/mariadb10.11-10.11.16-1.fc43.x86_64/sql/hash_filo.h:120 #4 Hash_filo<acl_entry>::search (this=0x559b44ba7090, key=0x7f2b642594a0 "", len=20) at /usr/src/debug/mariadb10.11-10.11.16-1.fc43.x86_64/sql/hash_filo.h:211 #5 acl_get (host=0x559b06e1d09c "localhost", ip=0x0, user=user@entry=0x7f2b18002c20 "", db=0x7f2b642594a2 "information_schema", db@entry=0x559b06e290b6 "information_schema", db_is_pattern=db_is_pattern@entry=0 '\000') at /usr/src/debug/mariadb10.11-10.11.16-1.fc43.x86_64/sql/sql_acl.cc:3813 #6 0x0000559b063ed80f in acl_get_all3 (sctx=0x7f2b18002c08, db=0x559b06e290b6 "information_schema", db_is_patern=false) at /usr/src/debug/mariadb10.11-10.11.16-1.fc43.x86_64/sql/sql_acl.cc:3878 #7 0x0000559b06547730 in get_referential_constraints_record (thd=<optimized out>, tables=0x7f2b181787f0, table=0x7f2b18168790, res=<optimized out>, db_name=0x559b0771ff70 <INFORMATION_SCHEMA_NAME>, table_name=0x7f2b18017bd0) at /usr/src/debug/mariadb10.11-10.11.16-1.fc43.x86_64/sql/sql_show.cc:8457 #8 0x0000559b0653fc5a in fill_schema_table_by_open (thd=thd@entry=0x7f2b18000cd8, mem_root=mem_root@entry=0x7f2b6425bf20, is_show_fields_or_keys=is_show_fields_or_keys@entry=false, table=table@entry=0x7f2b18168790, schema_table=schema_table@entry=0x559b076649c0 <schema_tables+1792>, orig_db_name=orig_db_name@entry=0x559b0771ff70 <INFORMATION_SCHEMA_NAME>, orig_table_name=0x7f2b18017bd0, open_tables_state_backup=0x7f2b6425bf60, can_deadlock=false) at /usr/src/debug/mariadb10.11-10.11.16-1.fc43.x86_64/sql/sql_show.cc:4806 #9 0x0000559b06541b08 in get_all_tables (thd=0x7f2b18000cd8, tables=0x7f2b181638f0, cond=<optimized out>) at /usr/src/debug/mariadb10.11-10.11.16-1.fc43.x86_64/sql/sql_show.cc:5441 #10 0x0000559b0654b2ec in get_schema_tables_result (join=0x7f2b18011ae0, executed_place=PROCESSED_BY_JOIN_EXEC) --Type <RET> for more, q to quit, c to continue without paging-- at /usr/src/debug/mariadb10.11-10.11.16-1.fc43.x86_64/sql/sql_show.cc:9279 #11 0x0000559b064ea9d3 in JOIN::exec_inner (this=this@entry=0x7f2b18011ae0) at /usr/src/debug/mariadb10.11-10.11.16-1.fc43.x86_64/sql/sql_select.cc:4980 #12 0x0000559b064eb457 in JOIN::exec (this=this@entry=0x7f2b18011ae0) at /usr/src/debug/mariadb10.11-10.11.16-1.fc43.x86_64/sql/sql_select.cc:4807 #13 0x0000559b064ebac4 in mysql_select (thd=0x7f2b18000cd8, tables=0x7f2b181638f0, fields=..., conds=0x7f2b18010ce0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2201724652288, result=0x7f2b18166940, unit=0x7f2b18160868, select_lex=0x7f2b18162a58) at /usr/src/debug/mariadb10.11-10.11.16-1.fc43.x86_64/sql/sql_select.cc:5285 #14 0x0000559b064dbd2e in handle_select (thd=0x7f2b18000cd8, lex=0x7f2b18160790, result=0x7f2b18166940, setup_tables_done_option=0) at /usr/src/debug/mariadb10.11-10.11.16-1.fc43.x86_64/sql/sql_select.cc:601 #15 0x0000559b0648f99e in execute_sqlcom_select (thd=thd@entry=0x7f2b18000cd8, all_tables=all_tables@entry=0x7f2b181638f0) at /usr/src/debug/mariadb10.11-10.11.16-1.fc43.x86_64/sql/sql_parse.cc:6463 #16 0x0000559b0649ac10 in mysql_execute_command (thd=0x7f2b18000cd8, is_called_from_prepared_stmt=<optimized out>) at /usr/src/debug/mariadb10.11-10.11.16-1.fc43.x86_64/sql/sql_parse.cc:4042 #17 0x0000559b064c949d in Prepared_statement::execute (this=this@entry=0x7f2b1815f818, expanded_query=expanded_query@entry=0x7f2b6425e080, open_cursor=open_cursor@entry=false) at /usr/src/debug/mariadb10.11-10.11.16-1.fc43.x86_64/sql/sql_prepare.cc:5310 #18 0x0000559b064cd573 in Prepared_statement::execute_loop (this=0x7f2b1815f818, expanded_query=0x7f2b6425e080, open_cursor=<optimized out>, packet=<optimized out>, packet_end=<optimized out>) at /usr/src/debug/mariadb10.11-10.11.16-1.fc43.x86_64/sql/sql_prepare.cc:4711 #19 0x0000559b064ce435 in mysql_stmt_execute_common (thd=0x7f2b18000cd8, stmt_id=<optimized out>, packet=0x7f2b18008772 "", packet_end=<optimized out>, cursor_flags=<optimized out>, bulk_op=<optimized out>, read_types=<optimized out>) at /usr/src/debug/mariadb10.11-10.11.16-1.fc43.x86_64/sql/sql_prepare.cc:3621 #20 0x0000559b06492449 in mysqld_stmt_execute (thd=0x7f2b18000cd8, packet_arg=0x18 <error: Cannot access memory at address 0x18>, packet_length=1770700319) --Type <RET> for more, q to quit, c to continue without paging--c at /usr/src/debug/mariadb10.11-10.11.16-1.fc43.x86_64/sql/sql_prepare.cc:3392 #21 dispatch_command (command=command@entry=COM_STMT_EXECUTE, thd=thd@entry=0x7f2b18000cd8, packet=packet@entry=0x7f2b18008769 "\t", packet_length=packet_length@entry=42, blocking=blocking@entry=true) at /usr/src/debug/mariadb10.11-10.11.16-1.fc43.x86_64/sql/sql_parse.cc:1848 #22 0x0000559b06494c08 in do_command (thd=0x7f2b18000cd8, blocking=true) at /usr/src/debug/mariadb10.11-10.11.16-1.fc43.x86_64/sql/sql_parse.cc:1434 #23 0x0000559b0661d660 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x559b44bf0708, put_in_cache=put_in_cache@entry=true) at /usr/src/debug/mariadb10.11-10.11.16-1.fc43.x86_64/sql/sql_connect.cc:1475 #24 0x0000559b0661db1f in handle_one_connection (arg=arg@entry=0x559b44bf0708) at /usr/src/debug/mariadb10.11-10.11.16-1.fc43.x86_64/sql/sql_connect.cc:1387 #25 0x0000559b06961b71 in pfs_spawn_thread (arg=0x559b44c1fd18) at /usr/src/debug/mariadb10.11-10.11.16-1.fc43.x86_64/storage/perfschema/pfs.cc:2201 #26 0x00007f2b65e7c464 in start_thread (arg=<optimized out>) at pthread_create.c:448 #27 0x00007f2b65eff5ec in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78 my_hash_first had some null or zero values in the crashing line in hash, key, etc. (gdb) frame 1 #1 0x0000559b063ed499 in my_hash_first (hash=0x559b44ba7108, key=0x7f2b642594a0 "", length=20, current_record=0x7f2b6425949c) at /usr/src/debug/mariadb10.11-10.11.16-1.fc43.x86_64/mysys/hash.c:263 263 res= my_hash_first_from_hash_value(hash, (gdb) l 258 HASH_SEARCH_STATE *current_record) 259 { 260 uchar *res; 261 DBUG_ASSERT(my_hash_inited(hash)); 262 263 res= my_hash_first_from_hash_value(hash, 264 hash->hash_function(hash->charset, key, 265 length ? length : 266 hash->key_length), 267 key, length, current_record); (gdb) p hash $1 = (const HASH *) 0x559b44ba7108 (gdb) p *hash $2 = {key_offset = 0, key_length = 0, blength = 0, records = 0, flags = 0, array = {buffer = 0x0, elements = 0, max_element = 0, alloc_increment = 0, size_of_element = 0, m_psi_key = 0, malloc_flags = 0}, get_key = 0x0, hash_function = 0x0, free = 0x0, charset = 0x0} (gdb) p key $3 = (const uchar *) 0x7f2b642594a0 "" (gdb) p *key $4 = 0 '\000' (gdb) p length $5 = 20 (gdb) p hash->key_length $6 = 0 (gdb) p current_record $7 = (HASH_SEARCH_STATE *) 0x7f2b6425949c (gdb) p *current_record $8 = 0 akonadiserver crashed after each mariadbd crash with the following. Thread 1 (Thread 0x7ff008227d40 (LWP 2947)): [KCrash Handler] #4 __pthread_kill_implementation (threadid=<optimized out>, signo=6, no_tid=<optimized out>) at pthread_kill.c:44 #5 0x00007ff00722415e in __GI_raise (sig=6) at ../sysdeps/posix/raise.c:26 #6 0x00007ff00720b6d0 in __GI_abort () at abort.c:77 #7 0x00007ff0074091b4 in __gnu_cxx::__verbose_terminate_handler () at ../../../../libstdc++-v3/libsupc++/vterminate.cc:95 #8 0x00007ff00741ebfc in __cxxabiv1::__terminate (handler=<optimized out>) at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:48 #9 0x00007ff007408d3a in std::terminate () at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:58 #10 0x00007ff00741eea8 in __cxxabiv1::__cxa_throw (obj=<optimized out>, tinfo=0x560f2aca5560 <typeinfo for Akonadi::Server::DbException>, dest=0x560f2ab9f660 <Akonadi::Server::DbException::~DbException()>) at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:98 #11 0x0000560f2aaba0cf in Akonadi::Server::DbIntrospector::hasIndex (this=<optimized out>, tableName=..., indexName=...) at /usr/src/debug/akonadi-server-25.12.2-1.fc43.x86_64/src/server/storage/dbintrospector.cpp:56 #12 0x0000560f2aba7adc in Akonadi::Server::DbInitializer::checkIndexes (this=0x560f66bf04e0, tableDescription=...) at /usr/src/debug/akonadi-server-25.12.2-1.fc43.x86_64/src/server/storage/dbinitializer.cpp:205 #13 0x0000560f2ab8211f in Akonadi::Server::DbInitializer::updateIndexesAndConstraints (this=0x560f66bf04e0) at /usr/src/debug/akonadi-server-25.12.2-1.fc43.x86_64/src/server/storage/dbinitializer.cpp:228 #14 Akonadi::Server::DataStore::init (this=<optimized out>) at /usr/src/debug/akonadi-server-25.12.2-1.fc43.x86_64/src/server/storage/datastore.cpp:227 #15 0x0000560f2aad6154 in Akonadi::Server::AkonadiServer::setupDatabase (this=this@entry=0x7ffc4987c830) at /usr/src/debug/akonadi-server-25.12.2-1.fc43.x86_64/src/server/akonadi.cpp:263 #16 0x0000560f2aad74bc in Akonadi::Server::AkonadiServer::init (this=0x7ffc4987c830) at /usr/src/debug/akonadi-server-25.12.2-1.fc43.x86_64/src/server/akonadi.cpp:107 #17 0x00007ff007958fcc in QObject::event (this=<optimized out>, e=<optimized out>) at /usr/src/debug/qt6-qtbase-6.10.1-3.fc43.x86_64/src/corelib/kernel/qobject.cpp:1413 #18 0x00007ff0078fc488 in doNotify (receiver=<optimized out>, event=<optimized out>) at /usr/src/debug/qt6-qtbase-6.10.1-3.fc43.x86_64/src/corelib/kernel/qcoreapplication.cpp:1210 #19 QCoreApplication::notify (this=<optimized out>, receiver=<optimized out>, event=<optimized out>) at /usr/src/debug/qt6-qtbase-6.10.1-3.fc43.x86_64/src/corelib/kernel/qcoreapplication.cpp:1193 #20 QCoreApplication::notifyInternal2 (receiver=0x7ffc4987c830, event=0x560f66bee2f0) at /usr/src/debug/qt6-qtbase-6.10.1-3.fc43.x86_64/src/corelib/kernel/qcoreapplication.cpp:1109 #21 0x00007ff0078fc74d in QCoreApplication::sendEvent (receiver=<optimized out>, event=<optimized out>) at /usr/src/debug/qt6-qtbase-6.10.1-3.fc43.x86_64/src/corelib/kernel/qcoreapplication.cpp:1549 #22 0x00007ff0078ffb09 in QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x560f66bdf3a0) at /usr/src/debug/qt6-qtbase-6.10.1-3.fc43.x86_64/src/corelib/kernel/qcoreapplication.cpp:1904 #23 0x00007ff007c1efcf in postEventSourceDispatch (s=0x560f66bdf7a0) at /usr/src/debug/qt6-qtbase-6.10.1-3.fc43.x86_64/src/corelib/kernel/qeventdispatcher_glib.cpp:246 #24 0x00007ff005aeb2a3 in g_main_dispatch (context=0x560f66be2c80) at ../glib/gmain.c:3565 #25 g_main_context_dispatch_unlocked (context=0x560f66be2c80) at ../glib/gmain.c:4425 #26 0x00007ff005af41f8 in g_main_context_iterate_unlocked (context=context@entry=0x560f66be2c80, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4490 #27 0x00007ff005af43a3 in g_main_context_iteration (context=0x560f66be2c80, may_block=1) at ../glib/gmain.c:4556 #28 0x00007ff007c1e80d in QEventDispatcherGlib::processEvents (this=0x560f66be2830, flags=...) at /usr/src/debug/qt6-qtbase-6.10.1-3.fc43.x86_64/src/corelib/kernel/qeventdispatcher_glib.cpp:399 #29 0x00007ff007909063 in QEventLoop::exec (this=this@entry=0x7ffc4987c540, flags=..., flags@entry=...) at /usr/src/debug/qt6-qtbase-6.10.1-3.fc43.x86_64/src/corelib/global/qflags.h:77 #30 0x00007ff007904819 in QCoreApplication::exec () at /usr/src/debug/qt6-qtbase-6.10.1-3.fc43.x86_64/src/corelib/kernel/qcoreapplication.cpp:1452 #31 0x0000560f2aacd98e in AkApplicationBase::exec (this=0x7ffc4987c7f0) at /usr/src/debug/akonadi-server-25.12.2-1.fc43.x86_64/src/shared/akapplication.cpp:109 #32 main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/akonadi-server-25.12.2-1.fc43.x86_64/src/server/main.cpp:65 I logged out and logged in and the same problem happened again. The problem didn't affect mariadb-10.11.15-3.fc43 Reproducible: Always Steps to Reproduce: 1. Start Plasma 6.5.5 on Wayland in a Fedora 43 KDE installation. 2. Start Konsole. 3. Run a dnf offline upgrade with updates-testing enabled using sudo dnf offline-upgrade download --refresh sudo dnf offline-upgrade reboot 4. On the next boot after the update, start Plasma from sddm. Actual Results: mariadbd 10.11.16-1.fc43 crashed when starting Plasma Expected Results: mariadbd shouldn't have crashed when starting Plasma
Hello, Thank you for testing the packages in the fedora-updates-testing repo. I am currently looking into it and I was able to reproduce the issue. When starting mariadb through akonadi mariadb-10.11.16 fails with a segfault while mariadb-10.11.15 does not. I will look into what exactly causes this issue and how to fix it.
New finding: this issue has to do with the `skip_grant_tables` option in the config akonadi uses alongside an `INNER JOIN` query. I can reproduce the issue even without akonadi if I simply add this option to the mariadb config. Also when I remove the `skip_grant_tables` option from the mariadb config created by akonadi (the one in ~/.local/share/akonadi) akonadi runs just with an issue about not being able to upgrade the database (mariadb throws an upgrade error but it works in the end). This is not sustainable in the long run (e.g.: after a couple of mariadb version migrations the databse might become outdated and stop working), but if you are looking for a workaround in the meantime this should be ok. I will continue to look into this and any changes made to this behavior in the latest release.
*** Bug 2438792 has been marked as a duplicate of this bug. ***
I commented out skip_grant_tables in ~/.local/share/akonadi/mysql.conf, and the crash didn't happen after I did that. Thanks. There's a mariadb server crash report with a similar trace when using --skip-grant-tables at https://jira.mariadb.org/browse/MDEV-38811 which appeared to bisect the problem to the commit c0acc3cc8f1ec24e96b1ee192fdf6e4b6ccf4e0a MDEV-38209 REFERENCES permission on particular schema is sometimes ignored.
*** Bug 2439440 has been marked as a duplicate of this bug. ***
*** Bug 2439969 has been marked as a duplicate of this bug. ***
*** Bug 2440116 has been marked as a duplicate of this bug. ***
*** Bug 2439809 has been marked as a duplicate of this bug. ***
The abrt report that was closed as a dupe was accepted as a Final blocker. Transferring that status here.
It looks like there's a draft fix at https://github.com/MariaDB/server/commit/87309d3d4bb8f48910d05b0ca5ee989bcdd6b053 that Arch and Debian are using, though AFAICS it's not even posted as a PR yet.
This is also causing a crash of akonadi for KDE!
Yes, we know.
Hi, there is already an MR present here: https://src.fedoraproject.org/rpms/mariadb10.11/pull-request/33 and one for MariaDB 11.8 as well: https://src.fedoraproject.org/rpms/mariadb11.8/pull-request/15 I will be merging them and creating the respective builds today and they will be available in the updates-testing repository on f44 and f43 and in the standard repo for rawhide.
*** Bug 2440910 has been marked as a duplicate of this bug. ***
I was triying to upgrade Fedora and the kernel, right after rebooting i had a couple Abrt Notifications. reporter: libreport-2.17.15 type: CCpp reason: mariadbd killed by SIGSEGV journald_cursor: s=694e1ca40c4549c0a36553fe27f3bfeb;i=4c2a5;b=320a2de164584a52b0afffe03c16c27c;m=2734092;t=64b0aaffede1d;x=c2c15b9b737e6b36 executable: /usr/libexec/mariadbd cmdline: /usr/libexec/mysqld --defaults-file=/home/manuel/.local/share/akonadi/mysql.conf --datadir=/home/manuel/.local/share/akonadi/db_data/ --socket=/run/user/1000/akonadi/mysql.socket --pid-file=/run/user/1000/akonadi/mysql.pid cgroup: 0::/user.slice/user-1000.slice/user/app.slice/app-org.kde.kalendarac rootdir: / uid: 1000 kernel: 6.20.0-0.rc0.260216g0f2acd3148e0e.8.fc45.x86_64 package: mariadb-server-3:11.8.6-1.fc45 runlevel: /bin/sh: line 1: runlevel: command not found backtrace_rating: 4 crash_function: my_hash_first comment: I was triying to upgrade Fedora and the kernel, right after rebooting i had a couple Abrt Notifications.
(In reply to Pavol Sloboda from comment #13) > I will be merging them and creating the respective builds today and they > will be available in the updates-testing repository on f44 and f43 and in > the standard repo for rawhide. If bug 2438792 is a duplicate of this bug, can you also produce an update for f42?
Yes I will, sorry, forgot to mention it here, I just need to do a bit more testing for f42.
FEDORA-2026-5a5a60358d (mariadb11.8-11.8.6-2.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-5a5a60358d
FEDORA-2026-5a5a60358d (mariadb11.8-11.8.6-2.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-9802ad4489 (mariadb10.11-10.11.16-2.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-9802ad4489
FEDORA-2026-9802ad4489 (mariadb10.11-10.11.16-2.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.
This should not be closed just because the Rawhide update went out. For F44 blocker/FE purposes we need to track the F44 update at least (and the bug is technically reported against 43).
As in https://bugzilla.redhat.com/show_bug.cgi?id=2441236#c0. reporter: libreport-2.17.15 type: CCpp reason: mariadbd killed by SIGSEGV journald_cursor: s=46bb43f1faea498db084fdfcb024f166;i=153f459;b=b9efe603f7d4428eab20b16bd19e9083;m=e661ba5;t=64b36885b7d48;x=2d02366bffa15156 executable: /usr/libexec/mariadbd cmdline: /usr/libexec/mysqld --defaults-file=/home/Red/.local/share/akonadi/mysql.conf --datadir=/home/Red/.local/share/akonadi/db_data/ --socket=/run/user/1000/akonadi/mysql.socket --pid-file=/run/user/1000/akonadi/mysql.pid cgroup: 0::/user.slice/user-1000.slice/user/session.slice/plasma-plasmashell.service rootdir: / uid: 1000 kernel: 6.19.2-300.fc44.x86_64 package: mariadb-server-3:11.8.6-1.fc44 runlevel: /bin/sh: line 1: runlevel: command not found backtrace_rating: 4 crash_function: __syscall_cancel_arch comment: As in https://bugzilla.redhat.com/show_bug.cgi?id=2441236#c0.
*** Bug 2441665 has been marked as a duplicate of this bug. ***
FEDORA-2026-bc0aa47ea8 (mariadb10.11-10.11.16-2.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-bc0aa47ea8
FEDORA-2026-c7ff425345 (mariadb10.11-10.11.16-2.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-c7ff425345
FEDORA-2026-3240fda724 (mariadb11.8-11.8.6-2.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-3240fda724
FEDORA-2026-a0deaf295f (mariadb11.8-11.8.6-2.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-a0deaf295f
FEDORA-2026-c8f8f8d3d7 (mariadb11.8-11.8.6-2.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2026-c8f8f8d3d7
FEDORA-2026-f93abae2ae (mariadb10.11-10.11.16-2.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2026-f93abae2ae
+3 Beta FE in https://pagure.io/fedora-qa/blocker-review/issue/2038 , marking accepted Beta FE.
(In reply to Fedora Update System from comment #30) > FEDORA-2026-f93abae2ae (mariadb10.11-10.11.16-2.fc42) has been submitted as > an update to Fedora 42. > https://bodhi.fedoraproject.org/updates/FEDORA-2026-f93abae2ae I think the name is in error. My current version is mariadb-10.11.15-3.fc42.x86_64 and this one will not replace it.
Yes, it will. 16 is bigger than 15.
oh, wait, you mean it shouldn't have the version in the package name? Possibly. Not sure what the intended setup is there.
no, looking at past builds, it looks like. the source RPM is mariadb10.11, but it builds unversioned binary packages. See https://koji.fedoraproject.org/koji/buildinfo?buildID=2946221 .
I have mariadb-10.11.15-3.fc42.x86_64 installed (I down-graded because of the last update causing crashes in akonadi). This update proposes to update my version with mariadb10.11-10.11.16-2.fc42. This is clearly wrong.
FEDORA-2026-c8f8f8d3d7 has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-c8f8f8d3d7` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-c8f8f8d3d7 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-f93abae2ae has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-f93abae2ae` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-f93abae2ae See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-bc0aa47ea8 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-bc0aa47ea8` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-bc0aa47ea8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-3240fda724 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-3240fda724` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-3240fda724 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-c7ff425345 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-c7ff425345` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-c7ff425345 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-a0deaf295f has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-a0deaf295f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-a0deaf295f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
> I have mariadb-10.11.15-3.fc42.x86_64 installed (I down-graded because of the last update causing crashes in akonadi). This update proposes to update my version with mariadb10.11-10.11.16-2.fc42. This is clearly wrong. I don't think it possibly could. There is no binary package called mariadb10.11 in the output of the build. You can see that for yourself at https://koji.fedoraproject.org/koji/buildinfo?buildID=2946221 . I don't know what update tool you're using, but can you paste a log or attach a screenshot of exactly what it's saying?
(In reply to Adam Williamson from comment #43) > > I have mariadb-10.11.15-3.fc42.x86_64 installed (I down-graded because of the last update causing crashes in akonadi). This update proposes to update my version with mariadb10.11-10.11.16-2.fc42. This is clearly wrong. > > I don't think it possibly could. There is no binary package called > mariadb10.11 in the output of the build. You can see that for yourself at > https://koji.fedoraproject.org/koji/buildinfo?buildID=2946221 . > > I don't know what update tool you're using, but can you paste a log or > attach a screenshot of exactly what it's saying? OK, I see what you are saying. I looked at "Information for build mariadb10.11-10.11.16-2.fc42" and mistakenly assumed that the rpm (binary) had that name. I will wait for the repos to sync and try again using --advisory=FEDORA-2026-f93abae2ae from comment 38.
*** Bug 2441988 has been marked as a duplicate of this bug. ***
*** Bug 2438795 has been marked as a duplicate of this bug. ***
*** Bug 2441238 has been marked as a duplicate of this bug. ***
FEDORA-2026-3240fda724 (mariadb11.8-11.8.6-2.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-c7ff425345 (mariadb10.11-10.11.16-2.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-a0deaf295f (mariadb11.8-11.8.6-2.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-c8f8f8d3d7 (mariadb11.8-11.8.6-2.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-f93abae2ae (mariadb10.11-10.11.16-2.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-bc0aa47ea8 (mariadb10.11-10.11.16-2.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.