Bug#1069535: [debian-mysql] Bug#1069535: Bug#1069535: galera-3: FTBFS on armel: dh_auto_test: error: cd obj-arm-linux-gnueabi && make -j1 test ARGS\+=--verbose ARGS\+=-j1 ARGS=--output-on-failure retu
control: forward -1 https://github.com/codership/galera/issues/659 control: forwarded -1 https://github.com/codership/galera/issues/659
Bug#1069535: [debian-mysql] Bug#1069535: Bug#1069535: galera-3: FTBFS on armel: dh_auto_test: error: cd obj-arm-linux-gnueabi && make -j1 test ARGS\+=--verbose ARGS\+=-j1 ARGS=--output-on-failure retu
Forwarded: https://github.com/codership/galera/issues/659
Bug#1053334: galera-4: FTBFS because of expired certificates
Bullseye oldstable update request filed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069802 You can +1 it if you want to show support.
Bug#1053334: galera-4: FTBFS because of expired certificates
> What about bullseye, which is also a supported distribution? > > I have not reached the point where I want to do NMUs for these kind > of bugs, but if this were my package, I would certainly do an upload > for bullseye as well. If I can be of any help, please say so. This bug report was about Bookworm, but sure, we can do Bullseye as well. WIP at https://salsa.debian.org/otto/galera/-/commits/debian/bullseye If you want to help, you can file a MR on Salsa at any time or review existing open MRs. No need to do NMUs - the actual upload is not the work, but doing the commits and filing the stable-update bug reports to release manager.
Bug#1053334: galera-4: FTBFS because of expired certificates
I was able to reproduce this for Bookworm both locally and in CI at https://salsa.debian.org/mariadb-team/galera-4/-/jobs/5620032 After importing latest upstream build/test passes: https://salsa.debian.org/otto/galera/-/jobs/5624466 Stable upload request filed at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069639
Bug#1069535: [debian-mysql] Bug#1069535: galera-3: FTBFS on armel: dh_auto_test: error: cd obj-arm-linux-gnueabi && make -j1 test ARGS\+=--verbose ARGS\+=-j1 ARGS=--output-on-failure returned exit cod
Galera 25.3.37 was last release from upstream in 3.x series. I suspect the best resolution here is to wait a bit and then just file removal request for galera-3 in sid/trixie when we are confident there is no MariaDB 10.1/2/3 users out there anymore.
Bug#1068404: marked as pending in mariadb
Control: tag -1 pending Hello, Bug #1068404 in mariadb reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/cd90d81520fd2211bd4b47c11ad51bac9618b8e2 Remove direct dependencies on libcurl4 (Closes: #1068403, #1068404) There is no libcurl4 package in Debian anymore since the transition to libcurl4t64. Instead of updating the dependency to new package name, remove it completely and rely on automatic shlibs:Depends to include it. (this message was generated automatically) -- Greetings https://bugs.debian.org/1068404
Bug#1068404: marked as pending in mariadb
Control: tag -1 pending Hello, Bug #1068404 in mariadb reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/cd90d81520fd2211bd4b47c11ad51bac9618b8e2 Remove direct dependencies on libcurl4 (Closes: #1068403, #1068404) There is no libcurl4 package in Debian anymore since the transition to libcurl4t64. Instead of updating the dependency to new package name, remove it completely and rely on automatic shlibs:Depends to include it. (this message was generated automatically) -- Greetings https://bugs.debian.org/1068404
Bug#1068403: marked as pending in mariadb
Control: tag -1 pending Hello, Bug #1068403 in mariadb reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/cd90d81520fd2211bd4b47c11ad51bac9618b8e2 Remove direct dependencies on libcurl4 (Closes: #1068403, #1068404) There is no libcurl4 package in Debian anymore since the transition to libcurl4t64. Instead of updating the dependency to new package name, remove it completely and rely on automatic shlibs:Depends to include it. (this message was generated automatically) -- Greetings https://bugs.debian.org/1068403
Bug#1068403: marked as pending in mariadb
Control: tag -1 pending Hello, Bug #1068403 in mariadb reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/cd90d81520fd2211bd4b47c11ad51bac9618b8e2 Remove direct dependencies on libcurl4 (Closes: #1068403, #1068404) There is no libcurl4 package in Debian anymore since the transition to libcurl4t64. Instead of updating the dependency to new package name, remove it completely and rely on automatic shlibs:Depends to include it. (this message was generated automatically) -- Greetings https://bugs.debian.org/1068403
Bug#1053334: galera-4: FTBFS because of expired certificates
Galera patch releases have been accepted as stable updates before. That is also what users expect. Thanks for reminding about this though, I yad forgotten about it. Will do it next weekend.
Bug#1067491: time_t transition upgrade: failed systemctl call in preinst due to missing pre-dependencies
Thanks Wouter for reporting this and Michael for submitting a merge request for a potential fix! The libcrypto.so.3 is from the OpenSSL package. In your upgrade case it seems to be switching from libssl3 [i386] to libssl3t64 [i386]. Your MariaDB packages are amd64. This makes me wonder what is actually going on. Were you able to recover? Can you now run manually 'systemctl --system daemon-reload'? This is the line dpkg was most likely running: https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/debian/mariadb-server.postinst#L289
Bug#1065275: mariadb: missing dpkg-dev (>= 1.22.5) build dependency for time_t transition
Since this is now the first time I noticed that new time_t should be available for testing and I started testing, I noticed that MariaDB has built-in check to prevent it from running on 2038 at all: # date Thu Mar 3 05:55:28 UTC 2039 # ./sql/mariadbd --version 2039-03-03 5:58:55 0 [ERROR] This server doesn't support dates later than 2038 Seems to stem from This is due to https://github.com/MariaDB/server/blob/11.5/sql/mysqld.cc#L3903-L3908 I am looking into this now as well.. On Sat, 2 Mar 2024 at 16:41, Otto Kekäläinen wrote: > > > > Could you Sebastian perhaps quickly skim through the commit that > > > implemented this > > > https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/8194544349982990fb2585c2a8c15c4db3904735 > > > and say if there might be something else missing as well? > > > > Did you mean > > https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/d2a0784f1e01b6613fefda17199a4e9867a126c3? > > > > At least for now that looks good. > > No I meant the original one, but you have now seen the original and > amendment and had no further comments, so seems good. > > I see Steven just uploaded curl 8.6.0-3.2 to fix the curl issues. I > will continue to wait a bit for the basic dependencies to stabilize, > for example this seems to affect many packages: > > libnsl2 depends on: > - libtirpc3:armel (>= 1.0.2) > libtirpc3t64 conflicts with: > - libtirpc3:armel (< 1.3.4+ds-1.1) > > I will upload new MariaDB as soon as I can verify that it is buildable.
Bug#1065275: mariadb: missing dpkg-dev (>= 1.22.5) build dependency for time_t transition
> > Could you Sebastian perhaps quickly skim through the commit that > > implemented this > > https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/8194544349982990fb2585c2a8c15c4db3904735 > > and say if there might be something else missing as well? > > Did you mean > https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/d2a0784f1e01b6613fefda17199a4e9867a126c3? > > At least for now that looks good. No I meant the original one, but you have now seen the original and amendment and had no further comments, so seems good. I see Steven just uploaded curl 8.6.0-3.2 to fix the curl issues. I will continue to wait a bit for the basic dependencies to stabilize, for example this seems to affect many packages: libnsl2 depends on: - libtirpc3:armel (>= 1.0.2) libtirpc3t64 conflicts with: - libtirpc3:armel (< 1.3.4+ds-1.1) I will upload new MariaDB as soon as I can verify that it is buildable.
Bug#1065275: mariadb: missing dpkg-dev (>= 1.22.5) build dependency for time_t transition
Currently MariaDB is not building[1] at all due to: ** mariadb build-depends on: - libcurl4-openssl-dev:amd64 libcurl4-openssl-dev depends on: - libcurl4t64:amd64 (= 8.6.0-3.1) mariadb build-depends on: - cmake:amd64 cmake depends on: - libcurl4:amd64 (>= 7.16.2) libcurl4t64 conflicts with: - libcurl4:amd64 (< 8.6.0-3.1) ** I can also see piuparts failing on broken libpam0t64[2] and a bunch of other tests failing various installability problems but seems they started before this upload, so they seem to happen only because many other packages right now during the transition have issues. Anyway I have the change[3] done in version control and I am ready to upload once I get some confirmation that this is now final. [1] https://buildd.debian.org/status/package.php?p=mariadb [2] https://salsa.debian.org/mariadb-team/mariadb-server/-/jobs/5393728 [3] https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/d2a0784f1e01b6613fefda17199a4e9867a126c3
Bug#1065275: marked as pending in mariadb
Control: tag -1 pending Hello, Bug #1065275 in mariadb reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/d2a0784f1e01b6613fefda17199a4e9867a126c3 Add 'dpkg-dev (>= 1.22.5)' to Build-Depends (Closes: #1065275) Extend 81945443 for time_t transition by adding missing dependency to ensure the package is built with correct ABI. (this message was generated automatically) -- Greetings https://bugs.debian.org/1065275
Bug#1062841: Bug#1065275: mariadb: missing dpkg-dev (>= 1.22.5) build dependency for time_t transition
Hi Sabastian! > * The package is built with the wrong ABI. > * The package migrates to testing before the change is enabled in > testing and builds there would be produced against the wrong ABI. > > Please add dpkg-dev (>= 1.22.5) to Build-Depends and upload the new > version ASAP. Thanks for following up with builds and transitions. I can do an upload quickly but would like to avoid having to do a third one, so: Could you Sebastian perhaps quickly skim through the commit that implemented this https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/8194544349982990fb2585c2a8c15c4db3904735 and say if there might be something else missing as well? Additional background info: - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062841 - https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/68
Bug#1062841: marked as pending in mariadb
Control: tag -1 pending Hello, Bug #1062841 in mariadb reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/8194544349982990fb2585c2a8c15c4db3904735 Rename libraries for 64-bit time_t transition (Closes: #1062841) (this message was generated automatically) -- Greetings https://bugs.debian.org/1062841
Bug#1062841: marked as pending in mariadb
Control: tag -1 pending Hello, Bug #1062841 in mariadb reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/f526df0a0921a55097d9c8c376da6c70843c1f2c Rename libraries for 64-bit time_t transition (Closes: #1062841) (this message was generated automatically) -- Greetings https://bugs.debian.org/1062841
Bug#1062841: [debian-mysql] Bug#1062841: Bug#1062841: mariadb: NMU diff for 64-bit time_t transition
Hi! I did additional testing and converted the attached patch into a MR ready to be merged on the debian/latest branch and uploaded to unstable: https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/68 Seems the experimental builds for MariaDB went OK. Let me know when is the correct time to upload this to unstable.
Bug#1062841: marked as pending in mariadb
Control: tag -1 pending Hello, Bug #1062841 in mariadb reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/063109a306a016974a4655260a0954e79d0e7412 Rename libraries for 64-bit time_t transition (Closes: #1062841) (this message was generated automatically) -- Greetings https://bugs.debian.org/1062841
Bug#1062841: [debian-mysql] Bug#1062841: mariadb: NMU diff for 64-bit time_t transition
Hi! Please do not do non-maintainer-uploads. This package is actively maintained, we can just include your patch in the next upload in a couple of days. On Sat, 3 Feb 2024 at 11:57, Graham Inggs wrote: > > Source: mariadb > Version: 1:10.11.6-2 > Severity: serious > Tags: patch pending sid trixie > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > NOTICE: these changes must not be uploaded to unstable yet! > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > mariadb as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). > > To ensure that inconsistent combinations of libraries with their > reverse-dependencies are never installed together, it is necessary to > have a library transition, which is most easily done by renaming the > runtime library package. > > Since turning on 64-bit time_t is being handled centrally through a change > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is > important that libraries affected by this ABI change all be uploaded close > together in time. Therefore I have prepared a 0-day NMU for mariadb > which will initially be uploaded to experimental if possible, then to > unstable after packages have cleared binary NEW. > > Please find the patch for this NMU attached. > > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. > > > > -- System Information: > Debian Release: trixie/sid > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.5.0-15-generic (SMP w/8 CPU threads; PREEMPT) > Kernel taint flags: TAINT_OOT_MODULE > Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: unable to detect > ___ > pkg-mysql-maint mailing list > pkg-mysql-ma...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mysql-maint
Bug#1053334: galera-4: FTBFS because of expired certificates
Sure, this will be fixed (automatically) with uploading latest upstream minor release as stable update, and I intend to do it in coming 1-2 weeks.
Bug#1052838: [debian-mysql] Bug#1052838: Bug#1052838: mariadb: FTBFS: make[1]: *** [debian/rules:161: override_dh_auto_test] Error 1
I restarted the build for powerpc yesterday, and it did not run into reserved ports issue and build passed. I suspect that this is because the ppc64 build (which runs on the same builder 'blaauw' was not running in parallel and thus the two build jobs were not competing for the same ports on that host. A later restart of ppc64 when the powerpc build had completed likewise did not run into reserved ports issues. Thus I'd say this is a Debian builder problem. The builds should be running inside a container or something so that they can't affect each other.
Bug#1052838: [debian-mysql] Bug#1052838: Bug#1052838: mariadb: FTBFS: make[1]: *** [debian/rules:161: override_dh_auto_test] Error 1
I saw this now after 1:10.11.5-2 upload on multiple builders. Snippets from logs https://buildd.debian.org/status/fetch.php?pkg=mariadb=powerpc=1%3A10.11.5-2=1696735216=0 main.failed_auth_unixsocket w13 [ fail ] Test ended at 2023-10-08 03:17:49 CURRENT_TEST: main.failed_auth_unixsocket Failed to start mysqld.1 mysqltest failed but provided no output - saving '/<>/builddir/mysql-test/var/13/log/main.failed_auth_unixsocket/' to '/<>/builddir/mysql-test/var/log/main.failed_auth_unixsocket/' Retrying test main.failed_auth_unixsocket, attempt(2/3)... worker[13] > Restart - not started ***Warnings generated in error logs during shutdown after running tests: main.failed_auth_unixsocket 2023-10-08 3:17:49 0 [ERROR] Can't start server: Bind on TCP/IP port. Got error: 98: Address already in use 2023-10-08 3:17:49 0 [ERROR] Do you already have another server running on port: 16120 ? 2023-10-08 3:17:49 0 [ERROR] Aborting main.password_expiration_unix_socket w13 [ fail ] Test ended at 2023-10-08 03:18:16 CURRENT_TEST: main.password_expiration_unix_socket Failed to start mysqld.1 mysqltest failed but provided no output - skipping '/<>/builddir/mysql-test/var/13/log/main.password_expiration_unix_socket/' Retrying test main.password_expiration_unix_socket, attempt(2/3)... main.order_byw14 [ pass ] 3306 worker[13] > Restart - not started ***Warnings generated in error logs during shutdown after running tests: main.password_expiration_unix_socket 2023-10-08 3:18:16 0 [ERROR] Can't start server: Bind on TCP/IP port. Got error: 98: Address already in use 2023-10-08 3:18:16 0 [ERROR] Do you already have another server running on port: 16120 ? 2023-10-08 3:18:16 0 [ERROR] Aborting main.ssl_cipher w15 [ fail ]main.ssl_cipher w15 [ fail ] ... 2023-10-08 3:18:22 0 [ERROR] Can't start server: Bind on TCP/IP port. Got error: 98: Address already in use 2023-10-08 3:18:22 0 [ERROR] Do you already have another server running on port: 16140 ? main.func_intw13 [ fail ]main.func_int w13 [ fail ] ... 2023-10-08 3:18:42 0 [ERROR] Can't start server: Bind on TCP/IP port. Got error: 98: Address already in use 2023-10-08 3:18:42 0 [ERROR] Do you already have another server running on port: 16120 ? main.plugin_loaderr w6 [ fail ] ... 2023-10-08 3:18:59 0 [ERROR] Can't start server: Bind on TCP/IP port. Got error: 98: Address already in use 2023-10-08 3:18:59 0 [ERROR] Do you already have another server running on port: 16100 ? etc Failing test(s): main.failed_auth_unixsocket main.password_expiration_unix_socket main.ssl_cipher main.func_int main.grant_4332 main.plugin_loaderr main.func_isnull main.grant_binlog_replay main.func_json main.grant_cache_no_prot https://buildd.debian.org/status/fetch.php?pkg=mariadb=ppc64=1%3A10.11.5-2=1696735349=0 main.connect w3 [ fail ] Test ended at 2023-10-08 03:17:18 CURRENT_TEST: main.connect Failed to start mysqld.1 mysqltest failed but provided no output - saving '/<>/builddir/mysql-test/var/3/log/main.connect/' to '/<>/builddir/mysql-test/var/log/main.connect/' Retrying test main.connect, attempt(2/3)... worker[3] > Restart - not started ***Warnings generated in error logs during shutdown after running tests: main.connect 2023-10-08 3:17:18 0 [ERROR] Can't start server: Bind on TCP/IP port. Got error: 98: Address already in use 2023-10-08 3:17:18 0 [ERROR] Do you already have another server running on port: 16140 ? 2023-10-08 3:17:18 0 [ERROR] Aborting main.innodb_load_xa w5 [ fail ] .. 2023-10-08 3:17:33 0 [ERROR] Can't start server: Bind on TCP/IP port. Got error: 98: Address already in use 2023-10-08 3:17:33 0 [ERROR] Do you already have another server running on port: 16120 ? main.flush_block_commit_notembedded 'innodb' w3 [ fail ] ... 2023-10-08 3:17:45 0 [ERROR] Can't start server: Bind on TCP/IP port. Got error: 98: Address already in use 2023-10-08 3:17:45 0 [ERROR] Do you already have another server running on port: 16140 ? main.long_unique_innodb 'innodb' w9 [ fail ] ... 2023-10-08 3:19:29 0 [ERROR] Can't start server: Bind on TCP/IP port. Got error: 98: Address already in use 2023-10-08 3:19:29 0 [ERROR] Do you already have another server running on port: 16260 ? Both builds above ran on builder 'blaauw' with kernel Linux 6.5.0-1-powerpc64 #1 SMP Debian 6.5.3-1 (2023-09-13) ppc64 (ppc64) I have not been able to reproduce this on any Salsa-CI builders or on Launchpad.
Bug#1052838: [debian-mysql] Bug#1052838: mariadb: FTBFS: make[1]: *** [debian/rules:161: override_dh_auto_test] Error 1
Hi! The relevant lines from log seems to be: > main.bind_address_resolution w4 [ fail ] ... > 2023-09-26 6:31:03 0 [ERROR] Can't start server: Bind on TCP/IP port. Got > error: 98: Address already in use > 2023-09-26 6:31:03 0 [ERROR] Do you already have another server running on > port: 16020 ? > 2023-09-26 6:31:03 0 [ERROR] Aborting What might have been holding port 16020 during the test run?
Bug#1035949: mariadb: upgrade issue: mariadb-server-10.5 fails to stop after all other -10.5 packages were removed
Hi! I did a bunch of reproducible experiments using Salsa-CI in https://salsa.debian.org/mariadb-team/mariadb-server/-/pipelines/536587 testing: ## upgrade to Bookworm * cacti and Bullseye upgrade - apt install -qq --yes cacti -> - apt full-upgrade -qq --yes * default-mysql-server and Bullseye upgrade - apt install -qq --yes default-mysql-server -> - apt full-upgrade -qq --yes * mariadb-server and Bullseye upgrade - apt install -qq --yes mariadb-server * zoph and Bullseye upgrade - apt install -qq --yes zoph -> - apt full-upgrade -qq --yes * zoph and Bullseye upgrade with mariadb-server explicitly - apt install -qq --yes zoph mariadb-server -> - apt install -qq --yes mariadb-server + apt full-upgrade -qq --yes * zoph with mariadb-server and Bullseye upgrade - apt install -qq --yes zoph mariadb-server -> - apt full-upgrade -qq --yes Only the last scenario failed. This suggests that perhaps users hit this issue only when having indirect dependency on default-mysql-server (via e.g. zoph), and upgrading only it or doing a full-upgrade. ## Recommendation how to avoid this issue I would recommend this as the best way as of today to update MariaDB 10.5.19/20 in Buster to 10.11.3 in Debian 12 "Bookworm": # Ensure Bullseye was running latest of everything, makes upgrade smoother $ sudo apt upgrade --yes # Ensure clean and safe shutdown before doing major version upgrade - this may take several minutes on large and busy database $ sudo systemctl stop mariadb || sudo /etc/init.d/mariadb stop # Enable new release $ sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list $ sudo apt update # Just upgrade MariaDB first so it can be brought back online as fast as possible $ sudo apt install mariadb-server # Then upgrade everything else $ sudo apt full-upgrade ## Recommendation how to recover if suffered this issue If you did not prepare along the lines of above and just upgraded, and if failed with error message: dpkg: mariadb-server-10.5: dependency problems, but removing anyway as you requested: zoph depends on default-mysql-server | virtual-mysql-server; however: Package default-mysql-server is not configured yet. Package virtual-mysql-server is not installed. Package mariadb-server-10.5 which provides virtual-mysql-server is to be removed. (Reading database ... 16559 files and directories currently installed.) Removing mariadb-server-10.5 (1:10.5.19-0+deb11u2) ... Stopping MariaDB database server: mariadbd failed! invoke-rc.d: initscript mariadb, action "stop" failed. dpkg: error processing package mariadb-server-10.5 (--remove): installed mariadb-server-10.5 package pre-removal script subprocess returned error exit status 1 dpkg: too many errors, stopping Errors were encountered while processing: mariadb-server-10.5 Processing was halted because there were too many errors. E: Sub-process /usr/bin/dpkg returned an error code (1) ..in that case the easiest way to recover is simply to manually stop the server and continue upgrade: $ sudo pkill -ef mariadbd || sudo pkill -ef mysqld $ sudo apt --fix-broken install $ sudo apt full-upgrade Workaround suggested to be included in Bookworm release notes at https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/197
Bug#1035949: mariadb: upgrade issue: mariadb-server-10.5 fails to stop after all other -10.5 packages were removed
Can you attach the full log as an attachment? The current short log does not show what apt told you in the beginning about what it plans to do, nor can I see if mariadb-client-10.5 was uninstalled or what happened. But it did at least hit a bug where the uninstall fails on `invoke-rd.c stop mariadb` failing. Is your system running systemd? What can you tell about the environment?
Bug#1035949: mariadb: upgrade issue: mariadb-server-10.5 fails to stop after all other -10.5 packages were removed
Thanks Frederick for the report! Do you still have the output of apt? Can you copy-paste here or attach log to show exactly what happened? It is likely that you hit this bug, but exact details would help confirm, and also help build CI test/scenario to ensure we have realistic upgrade testing.
Bug#1037107: Acknowledgement (pre-unblock: bookworm-pu: mariadb/1:10.11.3-2/+deb12u1)
Hi! Note that upstream released 10.11.4 today. Import preparation in progress at https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/50. I plan to upload this to experimental tomorrow and eventually into bookworm-pu if the release team approves. - Otto
Bug#1035949: mariadb: upgrade issue: mariadb-server-10.5 fails to stop after all other -10.5 packages were removed
Forwarded: https://jira.mariadb.org/browse/MDEV-28640 For reference: * The upgrade scenario this MR fixed: https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/15cbf6e691827608636e6ff7f0a50432f50d0c4f * Release notes mention: https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/187 * Upload to experimental pending in NEW queue: https://ftp-master.debian.org/new/mariadb_1:10.11.3-2~exp1.html * Release team consultation: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037107
Bug#1037107: pre-unblock: bookworm-pu: mariadb/1:10.11.3-2/+deb12u1
Package: release.debian.org Severity: serious Tags. bookworm User: release.debian@packages.debian.org Usertags: unblock Control: affects -1 src:mariadb This pre-unblock request is to get a decision from the Bookworm release team if you prefer to have this Bug#1035949 fix: a) in Bookworm in a stable update b) not at all (option c to have it in Bookworm I assume is too late) ## The new Debian revision reason: Bug#1035949 In Bug#1035949 it was discovered that in certain upgrade scenarios where a system has default-mysql-server indirectly installed (e.g. as a dependency of a consumer, such as zoph) running `apt-get install default-mysql-server` would trigger a sequence in apt which uninstalls mariadb-client-10.5 before mariadb-server-10.5 is stopped, causing dpkg to error as the MariaDB init file in mariadb-server-10.5 depends on mariadb-admin from mariadb-client-10.5. Running apt full-upgrade or apt dist-upgrade is not affected. Details in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035949, marked 'serious'. The issue was not visible in normal piuparts or in any of the custom Salsa-CI jobs testing upgrades in src:mariadb. Credits goes to Andreas Beckman for discovering the issue by meticulously testing various Bookworm upgrade scenarios semi-manually with piuparts! ## Fix: introduce transitional mariadb-server-10.5 Andreas also figured out the fix for this as none of the other attempted fixes were successful. The fix is to introduce a transitional mariadb-server-10.5 package: https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/47 Work on this particular issue has only been done around Bullseye to Bookworm upgrades. The same issue might also need a transitional mariadb-server-10.3 if we want to support flawless Buster to Bookworm upgrades. ## Testing and quality assurance Once Bug#1035949 was reported, a Salsa-CI job was added specifically for this type of upgrade scenarios: https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/15cbf6e691827608636e6ff7f0a50432f50d0c4f The fix has been validated to work both by this Salsa-CI scenario and by Andrea's piuparts runs. To expedite the distribution of the fix it has already been uploaded to experimental. Full debdiff attached, and visual comparison with full commit metadata at https://salsa.debian.org/mariadb-team/mariadb-server/-/compare/00c0a8fc...93c08bcc. Since it introduces a new package (albeit that it already existed in Debian previously) the upload needs to also pass the NEW queue: https://ftp-master.debian.org/new/mariadb_1:10.11.3-2~exp1.html ## Risk quantification and analysis This is not a regression from any recent uploads of MariaDB 10.11, but has existed since the introduction of 10.11 into Debian on January 16th, 2023. This is the first time this specific issue was reported by people doing or testing upgrades from mariadb-10.5 (or mariadb-10.6, which was in testing/unstable before 10.11). This may have existed upstream since MariaDB 10.7 from 2022 (https://jira.mariadb.org/browse/MDEV-286409), but never got proper attention by me as I was busy maintaining the package in Debian, and 10.7/8/9/10 were never in Debian. While Bug#1035949 has participation only from one reporter it is reasonable to expect that there are and will be more users affected. There are no known drawbacks of having a transitional mariadb-server-10.5 in Bookworm. ## Mitigation For the time being as a mitigation was filed to mention this as a potential issue in the Bookworm release notes: https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/187 (Bug#1037103). mariadb-1%10.11.3-2_exp1.debdiff.xz Description: application/xz
Bug#1035949: mariadb: upgrade issue: mariadb-server-10.5 fails to stop after all other -10.5 packages were removed
Indeed the transitional mariadb-server-10.5 fixes the issue. What do you Andreas suggest we do now? It is already past freeze for Bookworm, and this is not just a small fix but also introduces a new package (albeit transitional). Let me know how you want to proceed and I can immediately tomorrow push this to experimental or unstable if that is aligned with your plan. Alternatively we can ask for pre-approval from the release team.
Bug#1035949: mariadb: upgrade issue: mariadb-server-10.5 fails to stop after all other -10.5 packages were removed
I adjusted your patch a bit as it didn't apply cleanly and pushed it to https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/47 to replace the transitional mariadb-client-10.5 I had earlier. Thanks for diving deep in piuparts testing for MariaDB 10.11 and for the patch! Ideally the CI itself had all the install/upgrade scenarios that are relevant. Contributions to the debian/salsa-ci.yml file are also very welcome!
Bug#1035949: mariadb: upgrade issue: mariadb-server-10.5 fails to stop after all other -10.5 packages were removed
I filed now https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/47 as an exploration to fix this issue. If we don't fix this in 10.11 the alternative would be to patch 10.5 and 10.3 to simply never fail on missing mariadb-client-10.3/5 package. I already did https://salsa.debian.org/mariadb-team/mariadb-10.5/-/merge_requests/14 to make the problem have a proper error message users.
Bug#1032104: linux: ppc64el iouring corrupted read
Hello! This is not fixed. I sampled failing autopkgtests for MariaDB at https://ci.debian.net/packages/m/mariadb/testing/ppc64el/ between May 7th and 22nd. They still have crashes that include error message 'Database page corruption on disk'. Both failing and passing ones were running kernel: Linux 6.1.0-9-powerpc64le #1 SMP Debian 6.1.27-1 (2023-05-08) Most passing ones were on ci-worker-ppc64el-03, but also on -02. The failing ones were on workers -01 and -02. Since -02 had both failing and passing it indicates that this is not a hardware issue. The overall symptoms indicate that this is a software issue that started on Feb 6th (kernel: Linux 5.10.0-21-powerpc64le) and it happens sporadically, not on every run, and continues to happen. - Otto
Bug#1035949: mariadb: upgrade issue: mariadb-server-10.5 fails to stop after all other -10.5 packages were removed
I am experimenting the suggestion in https://salsa.debian.org/otto/mariadb-server/-/commits/bugfix/1035949-upgrade-removes-client
Bug#1035949: mariadb: upgrade issue: mariadb-server-10.5 fails to stop after all other -10.5 packages were removed
Here is the apt resolver output for debugging: # apt install default-mysql-server -o Debug::pkgDepCache::Marker=1 -o Debug::pkgDepCache::AutoInstall=1 -o Debug::pkgProblemResolver=1 Reading package lists... Done Building dependency tree... Done Reading state information... Done MarkInstall default-mysql-server:amd64 < 1.0.7 -> 1.1.0 @ii pumU Ib > FU=1 Installing mariadb-server:amd64 as Depends of default-mysql-server:amd64 Removing: mariadb-server-10.5:amd64 as upgrade is not an option for mariadb-server:amd64 (1:10.11.2-1) MarkDelete mariadb-server-10.5:amd64 < 1:10.5.19-0+deb11u2 @ii mK Ib > FU=0 MarkInstall mariadb-server:amd64 < none -> 1:10.11.2-1 @un puN Ib > FU=0 Installing mariadb-common:amd64 as PreDepends of mariadb-server:amd64 MarkInstall mariadb-common:amd64 < 1:10.5.19-0+deb11u2 -> 1:10.11.2-1 @ii pumU > FU=0 Installing mariadb-client:amd64 as Depends of mariadb-server:amd64 Removing: mariadb-client-10.5:amd64 as upgrade is not an option for mariadb-client:amd64 (1:10.11.2-1) MarkDelete mariadb-client-10.5:amd64 < 1:10.5.19-0+deb11u2 @ii mK Ib > FU=0 Removing: mariadb-client-core-10.5:amd64 as upgrade is not an option for mariadb-client:amd64 (1:10.11.2-1) MarkDelete mariadb-client-core-10.5:amd64 < 1:10.5.19-0+deb11u2 @ii mK > FU=0 MarkInstall mariadb-client:amd64 < none -> 1:10.11.2-1 @un puN Ib > FU=0 Installing mariadb-client-core:amd64 as Depends of mariadb-client:amd64 Removing: mariadb-server-core-10.5:amd64 as upgrade is not an option for mariadb-client-core:amd64 (1:10.11.2-1) MarkDelete mariadb-server-core-10.5:amd64 < 1:10.5.19-0+deb11u2 @ii mK > FU=0 MarkInstall mariadb-client-core:amd64 < none -> 1:10.11.2-1 @un puN Ib > FU=0 Installing libc6:amd64 as Depends of mariadb-client-core:amd64 MarkInstall libc6:amd64 < 2.31-13+deb11u5 -> 2.36-9 @ii pumU NPb > FU=0 Installing libssl3:amd64 as Depends of mariadb-client-core:amd64 MarkInstall libssl3:amd64 < none -> 3.0.8-1 @un puN > FU=0 Installing mariadb-server-core:amd64 as Depends of mariadb-server:amd64 MarkInstall mariadb-server-core:amd64 < none -> 1:10.11.2-1 @un puN Ib > FU=0 Installing libpmem1:amd64 as Depends of mariadb-server-core:amd64 MarkInstall libpmem1:amd64 < none -> 1.12.1-2 @un puN Ib > FU=0 Installing libdaxctl1:amd64 as Depends of libpmem1:amd64 MarkInstall libdaxctl1:amd64 < none -> 76.1-1 @un puN Ib > FU=0 Installing libkmod2:amd64 as Depends of libdaxctl1:amd64 MarkInstall libkmod2:amd64 < none -> 30+20221128-1 @un puN Ib > FU=0 Installing libzstd1:amd64 as Depends of libkmod2:amd64 MarkInstall libzstd1:amd64 < 1.4.8+dfsg-2.1 -> 1.5.4+dfsg2-5 @ii pumU > FU=0 Installing libndctl6:amd64 as Depends of libpmem1:amd64 MarkInstall libndctl6:amd64 < none -> 76.1-1 @un puN > FU=0 Installing libstdc++6:amd64 as Depends of mariadb-server-core:amd64 MarkInstall libstdc++6:amd64 < 10.2.1-6 -> 12.2.0-14 @ii pumU Ib > FU=0 Installing gcc-12-base:amd64 as Depends of libstdc++6:amd64 MarkInstall gcc-12-base:amd64 < none -> 12.2.0-14 @un puN > FU=0 Installing liburing2:amd64 as Depends of mariadb-server-core:amd64 MarkInstall liburing2:amd64 < none -> 2.3-3 @un puN > FU=0 Installing mariadb-plugin-provider-bzip2:amd64 as Recommends of mariadb-server:amd64 MarkInstall mariadb-plugin-provider-bzip2:amd64 < none -> 1:10.11.2-1 @un uN > FU=0 Installing mariadb-plugin-provider-lz4:amd64 as Recommends of mariadb-server:amd64 MarkInstall mariadb-plugin-provider-lz4:amd64 < none -> 1:10.11.2-1 @un uN > FU=0 Installing mariadb-plugin-provider-lzma:amd64 as Recommends of mariadb-server:amd64 MarkInstall mariadb-plugin-provider-lzma:amd64 < none -> 1:10.11.2-1 @un uN > FU=0 Installing mariadb-plugin-provider-lzo:amd64 as Recommends of mariadb-server:amd64 MarkInstall mariadb-plugin-provider-lzo:amd64 < none -> 1:10.11.2-1 @un uN Ib > FU=0 Installing liblzo2-2:amd64 as Depends of mariadb-plugin-provider-lzo:amd64 MarkInstall liblzo2-2:amd64 < none -> 2.10-2 @un uN > FU=0 Installing mariadb-plugin-provider-snappy:amd64 as Recommends of mariadb-server:amd64 MarkInstall mariadb-plugin-provider-snappy:amd64 < none -> 1:10.11.2-1 @un uN Ib > FU=0 Installing libsnappy1v5:amd64 as Depends of mariadb-plugin-provider-snappy:amd64 MarkInstall libsnappy1v5:amd64 < 1.1.8-1 -> 1.1.9-3 @ii umU > FU=0 Installing pv:amd64 as Recommends of mariadb-server:amd64 MarkInstall pv:amd64 < none -> 1.6.20-1 @un uN > FU=0 Starting pkgProblemResolver with broken count: 0 Starting 2 pkgProblemResolver with broken count: 0 Done The following package was automatically installed and is no longer required: libaio1 Use 'apt autoremove' to remove it. The following additional packages will be
Bug#1035949: mariadb: upgrade issue: mariadb-server-10.5 fails to stop after all other -10.5 packages were removed
I did some more testing in throwaway containers. In each test starting point was same: apt-get install default-mysql-server zoph sed s/bullseye/bookworm/g -i /etc/apt/sources.list apt update All cases ran apt 2.6.0. I only varied the command that followed: 1) apt-get install default-mysql-server Fails: debconf: delaying package configuration, since apt-utils is not installed (Reading database ... 16648 files and directories currently installed.) Preparing to unpack .../mysql-common_5.8+1.1.0_all.deb ... Unpacking mysql-common (5.8+1.1.0) over (5.8+1.0.7) ... Preparing to unpack .../mariadb-common_1%3a10.11.2-1_all.deb ... Unpacking mariadb-common (1:10.11.2-1) over (1:10.5.19-0+deb11u2) ... Preparing to unpack .../default-mysql-server_1.1.0_all.deb ... Unpacking default-mysql-server (1.1.0) over (1.0.7) ... dpkg: mariadb-client-10.5: dependency problems, but removing anyway as you requested: mariadb-server-10.5 depends on mariadb-client-10.5 (>= 1:10.5.19-0+deb11u2). dbconfig-mysql depends on default-mysql-client | virtual-mysql-client; however: Package default-mysql-client is not installed. Package virtual-mysql-client is not installed. Package mariadb-client-10.5 which provides virtual-mysql-client is to be removed. (Reading database ... 16648 files and directories currently installed.) Removing mariadb-client-10.5 (1:10.5.19-0+deb11u2) ... Removing mariadb-client-core-10.5 (1:10.5.19-0+deb11u2) ... dpkg: mariadb-server-10.5: dependency problems, but removing anyway as you requested: zoph depends on default-mysql-server | virtual-mysql-server; however: Package default-mysql-server is not configured yet. Package virtual-mysql-server is not installed. Package mariadb-server-10.5 which provides virtual-mysql-server is to be removed. Removing mariadb-server-10.5 (1:10.5.19-0+deb11u2) ... Stopping MariaDB database server: mariadbd failed! invoke-rc.d: initscript mariadb, action "stop" failed. dpkg: error processing package mariadb-server-10.5 (--remove): installed mariadb-server-10.5 package pre-removal script subprocess returned error exit status 1 dpkg: too many errors, stopping Errors were encountered while processing: mariadb-server-10.5 Processing was halted because there were too many errors. E: Sub-process /usr/bin/dpkg returned an error code (1) # apt --fix-broken install mariadb-client Reading package lists... Done Building dependency tree... Done Reading state information... Done You might want to run 'apt --fix-broken install' to correct these. The following packages have unmet dependencies: default-mysql-server : Depends: mariadb-server but it is not going to be installed mariadb-client : Depends: mariadb-client-core (>= 1:10.11.2-1) but it is not going to be installed Depends: libssl3 (>= 3.0.0) but it is not going to be installed Breaks: mariadb-server-10.5 but 1:10.5.19-0+deb11u2 is to be installed mariadb-server-10.5 : Depends: mariadb-client-10.5 (>= 1:10.5.19-0+deb11u2) but it is not installable E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution). 2) apt upgrade Passes: Everything is unpacked and installed, and MariaDB server restart is among the last things that happen and is successful. Upgrade of default-mysql-server was postponed and starts only when running 'apt full-upgrade'. 3) apt full-upgrade Fails: ... Preparing to unpack .../default-mysql-server_1.1.0_all.deb ... Unpacking default-mysql-server (1.1.0) over (1.0.7) ... dpkg: mariadb-client-10.5: dependency problems, but removing anyway as you requested: mariadb-server-10.5 depends on mariadb-client-10.5 (>= 1:10.5.19-0+deb11u2). dbconfig-mysql depends on default-mysql-client | virtual-mysql-client; however: Package default-mysql-client is not installed. Package virtual-mysql-client is not installed. Package mariadb-client-10.5 which provides virtual-mysql-client is to be removed. (Reading database ... 18487 files and directories currently installed.) Removing mariadb-client-10.5 (1:10.5.19-0+deb11u2) ... Removing mariadb-client-core-10.5 (1:10.5.19-0+deb11u2) ... dpkg: mariadb-server-10.5: dependency problems, but removing anyway as you requested: zoph depends on default-mysql-server | virtual-mysql-server; however: Package default-mysql-server is not configured yet. Package virtual-mysql-server is not installed. Package mariadb-server-10.5 which provides virtual-mysql-server is to be removed. Removing mariadb-server-10.5 (1:10.5.19-0+deb11u2) ... Stopping MariaDB database server: mariadbd failed! invoke-rc.d: initscript mariadb, action "stop" failed. dpkg: error processing package mariadb-server-10.5 (--remove): installed mariadb-server-10.5 package pre-removal script subprocess returned error exit status 1 dpkg: too many errors, stopping Errors were encountered while processing: mariadb-server-10.5 Processing was halted because there were too many errors. E: Sub-process /usr/bin/dpkg returned an
Bug#1035949: mariadb: upgrade issue: mariadb-server-10.5 fails to stop after all other -10.5 packages were removed
This is not a fix, but could help make the situation easier to detect/debug for users: * https://salsa.debian.org/mariadb-team/mariadb-10.5/-/merge_requests/14 * https://salsa.debian.org/mariadb-team/mariadb-10.3/-/merge_requests/37
Bug#1035944: mariadb: upgrade issue: mariadb-server-10.5 fails to restart after upgrading mariadb-common
Control: retitle -1 mariadb-plugin-gssapi-server: crash on partial upgrade of libk5crypto3 Filed now https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036055 for krb5 maintainers to advise on.
Bug#1035949: mariadb: upgrade issue: mariadb-server-10.5 fails to stop after all other -10.5 packages were removed
Hi Andreas! Thanks for reporting and looking into this. > Here apt choses a suboptimal removal order: mariadb-server-10.5 gets > removed (and therefore stopped, but that fails) only after > mariadb-client-10.5 and mariadb-client-core-10.5 are already gone. You are right. The /usr/bin/mysqladmin command is gone and thus the '$MYADMIN shutdown' will always fail in /etc/init.d/mariadb when removal happens in this order. The history here is that I submitted https://github.com/MariaDB/server/pull/2299/commits/a7fb9f80af6f6aa2e5ca2f36a79d325358b40e00 upstream in a PR that got squashed (against my recommendation) and thus got applied upstream as https://github.com/MariaDB/server/commit/f4adf3547420cced027d26ee8b8190be8a2bdea2. Upstream bug tracker was https://jira.mariadb.org/browse/MDEV-28640 and is still open, and this was filed now in Debian as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035949 but I recall there was duplicates earlier as well. Anyway, clearly this isn't fully fixed yet. > I have tried the early upgrade scenario only with one other package that > needs it (icinga2-ido-mysql), and there it worked flawless. > Some bits from the log: > > ... > Preparing to unpack .../mariadb-common_1%3a10.11.2-1_all.deb ... > Unpacking mariadb-common (1:10.11.2-1) over (1:10.5.19-0+deb11u2) ... > Preparing to unpack .../default-mysql-server_1.1.0_all.deb ... > Unpacking default-mysql-server (1.1.0) over (1.0.7) ... > Removing mariadb-server-10.5 (1:10.5.19-0+deb11u2) ... > invoke-rc.d: could not determine current runlevel > Stopping MariaDB database server: mariadbd. > Removing mariadb-client-10.5 (1:10.5.19-0+deb11u2) ... > Removing mariadb-client-core-10.5 (1:10.5.19-0+deb11u2) ... > Removing mariadb-server-core-10.5 (1:10.5.19-0+deb11u2) ... > ... > > > Do you have a test in you CI that does something equivalent to > > * apt-get install default-mysql-server > * sed s/bullseye/bookworm/ sources.list > * apt-get install default-mysql-server # early upgrade > * apt-get dist-upgrade I was able to reproduce this on my laptop in a Docker container with simply: ./test-prepare-container apt-get install default-mysql-server zoph sed s/bullseye/bookworm/g -i /etc/apt/sources.list apt update apt-get install default-mysql-server NOTE: Installing 'zoph' here is key. It will pull in dbconfig-common etc and create this interaction. Removing 'zoph' makes the upgrade pass just fine. This is similar to what we discovered with Cacti in Bug#1031116 I added this 'zoph' update as a new Salsa-CI job in commit 2 of https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/26 (result in https://salsa.debian.org/otto/mariadb-server/-/jobs/4213540). One way to mitigate this would be to backport https://github.com/MariaDB/server/pull/2299/commits/a7fb9f80af6f6aa2e5ca2f36a79d325358b40e00 to MariaDB 10.5 in Debian. However it would not fix the fact that the client library is removed too early. I need to play around with this to find out a proper solution.
Bug#1035944: mariadb: upgrade issue: mariadb-server-10.5 fails to restart after upgrading mariadb-common
After some experimentation I found out that updating libkrb5-3 so that /usr/lib/x86_64-linux-gnu/libkrb5.so.3 upgrades will stop MariaDB from crashing. $ apt install libk5crypto3 libkrb5-3 ... libssl3 amd64 3.0.8-1 libgssapi-krb5-2 amd64 1.20.1-1+b1 libkrb5support0 amd64 1.20.1-1+b1 libkrb5-3 amd64 1.20.1-1+b1 I made a quick bash one-liner to install all packages from 'apt upgrade' step one-by-one to find out which one exactly causes MariaDB to crash, and the result was also libk5crypto3. Here is a more complete stack trace with debug symbols installed and addr2line working: 230514 5:19:28 [ERROR] mysqld got signal 11 ; Server version: 10.5.19-MariaDB-0+deb11u2 source revision: f8a85af8ca1c937b8d4f847477bd282f80251cde key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=0 max_threads=153 thread_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467880 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 0x0 thread_stack 0x49000 2023-05-14 5:19:28 0 [Note] InnoDB: Buffer pool(s) load completed at 230514 5:19:28 ??:0(my_print_stacktrace)[0x556f175e616e] ??:0(handle_fatal_signal)[0x556f170def45] libc_sigaction.c:0(__restore_rt)[0x7f443ea8cf90] krb/prng.c:151(krb5_c_random_os_entropy)[0x7f443cd95de0] ??:0(krb5_init_context_profile)[0x7f443ce06cbf] ??:0(plugin_init())[0x7f443cee7569] /usr/lib/mysql/plugin/auth_gssapi.so(+0x2330)[0x7f443cee7330] ??:0(sys_var_pluginvar::sys_var_pluginvar(sys_var_chain*, char const*, st_plugin_int*, st_mysql_sys_var*, char const*))[0x556f16ef3562] ??:0(plugin_init(int*, char**, int))[0x556f16ef44d7] ??:0(unireg_abort)[0x556f16e1c0e6] ??:0(mysqld_main(int, char**))[0x556f16e21dc4] x86/libc-start.c:74(__libc_start_call_main)[0x7f443ea7818a] csu/libc-start.c:128(call_init)[0x7f443ea78245] ??:0(_start)[0x556f16e16daa] I think the solution would be for libk5crypto3 to have instead of Depends: libc6 (>= 2.33), libkrb5support0 (>= 1.16) to have Depends: libc6 (>= 2.33), libkrb5support0 (>= 1.20)
Bug#1035944: mariadb: upgrade issue: mariadb-server-10.5 fails to restart after upgrading mariadb-common
Hi! I was able to reproduce this with: apt install mariadb-plugin-gssapi-server mariadb-plugin-gssapi-client sed s/bullseye/bookworm/g -i /etc/apt/sources.list apt update apt-get upgrade Upgrade only updates mysql-common and mariadb-common: $ dpkg -l | grep -e mysql -e maria ii libdbd-mariadb-perl1.21-3 ii libmariadb3:amd64 1:10.5.19-0+deb11u2 ii mariadb-client-10.51:10.5.19-0+deb11u2 ii mariadb-client-core-10.5 1:10.5.19-0+deb11u2 ii mariadb-common 1:10.11.2-1 ii mariadb-plugin-gssapi-client:amd64 1:10.5.19-0+deb11u2 ii mariadb-plugin-gssapi-server 1:10.5.19-0+deb11u2 iF mariadb-server-10.51:10.5.19-0+deb11u2 ii mariadb-server-core-10.5 1:10.5.19-0+deb11u2 ii mysql-common 5.8+1.1.0 I applied manually the debugging patch I have in https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/26 on /etc/init.d/mariadb and it resulted in: $ /etc/init.d/mariadb restart Stopping MariaDB database server: mariadbd. Starting MariaDB database server: mariadbd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230514 01:36:00 mysqld_safe Can't log to error log and syslog at the same time. Remove all --log-error configuration options for --syslog to take effect. 230514 01:36:00 mysqld_safe Logging to '/tmp/tmp.AQ6kA9uzuH.err'. 230514 01:36:00 mysqld_safe Starting mariadbd daemon with databases from /var/lib/mysql Running '/etc/init.d/mariadb start' failed with error log: 230514 01:36:00 mysqld_safe Starting mariadbd daemon with databases from /var/lib/mysql 2023-05-14 1:36:00 0 [Note] Starting MariaDB 10.5.19-MariaDB-0+deb11u2 source revision f8a85af8ca1c937b8d4f847477bd282f80251cde as process 9189 2023-05-14 1:36:00 0 [Note] InnoDB: Uses event mutexes 2023-05-14 1:36:00 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 2023-05-14 1:36:00 0 [Note] InnoDB: Number of pools: 1 2023-05-14 1:36:00 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions 2023-05-14 1:36:00 0 [Note] InnoDB: Using Linux native AIO 2023-05-14 1:36:00 0 [Note] InnoDB: Initializing buffer pool, total size = 134217728, chunk size = 134217728 2023-05-14 1:36:00 0 [Note] InnoDB: Completed initialization of buffer pool 2023-05-14 1:36:00 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=45127,45127 2023-05-14 1:36:00 0 [Note] InnoDB: 128 rollback segments are active. 2023-05-14 1:36:00 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1" 2023-05-14 1:36:00 0 [Note] InnoDB: Creating shared tablespace for temporary tables 2023-05-14 1:36:00 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ... 2023-05-14 1:36:00 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB. 2023-05-14 1:36:00 0 [Note] InnoDB: 10.5.19 started; log sequence number 45163; transaction id 20 2023-05-14 1:36:00 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool 2023-05-14 1:36:00 0 [Note] Plugin 'FEEDBACK' is disabled. 230514 1:36:00 [ERROR] mysqld got signal 11 ; ... /usr/sbin/mariadbd(my_print_stacktrace+0x2e)[0x5613bb07516e] /usr/sbin/mariadbd(handle_fatal_signal+0x485)[0x5613bab6df45] /lib/x86_64-linux-gnu/libc.so.6(+0x3bf90)[0x7f4b7a2faf90] /usr/lib/x86_64-linux-gnu/libk5crypto.so.3(krb5_c_random_os_entropy+0x0)[0x7f4b785fcde0] /usr/lib/x86_64-linux-gnu/libkrb5.so.3(krb5_init_context_profile+0x22f)[0x7f4b7866dcbf] /usr/lib/mysql/plugin/auth_gssapi.so(_Z11plugin_initv+0x129)[0x7f4b7874e569] /usr/lib/mysql/plugin/auth_gssapi.so(+0x2330)[0x7f4b7874e330] /usr/sbin/mariadbd(+0x77b562)[0x5613ba982562] /usr/sbin/mariadbd(_Z11plugin_initPiPPci+0x887)[0x5613ba9834d7] /usr/sbin/mariadbd(+0x6a40e6)[0x5613ba8ab0e6] /usr/sbin/mariadbd(_Z11mysqld_mainiPPc+0x3f4)[0x5613ba8b0dc4] /lib/x86_64-linux-gnu/libc.so.6(+0x2718a)[0x7f4b7a2e618a] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85)[0x7f4b7a2e6245] /usr/sbin/mariadbd(_start+0x2a)[0x5613ba8a5daa] I suspect that some of the dependencies on the system (libc?) that updated causes GSSAPI to crash.
Bug#1035944: mariadb: upgrade issue: mariadb-server-10.5 fails to restart after upgrading mariadb-common
Thanks for reporting! Is this sporadic or does it reproduce every time? We have this upgrade scenario in CI without issues, thus asking about reproducibility.
Bug#1032104: linux: ppc64el iouring corrupted read
> > > Paul Gevers asked if the issues are gone as well with 6.1.12-1 > > > (or later 6.1.y series versions, which will land in bookworm). That > > > would be valuable information to know as well to exclude we do not > > > have the issue as well in bookworm. > > > > Were you able to verify this? Yes and new kernel did not fix it. I reviewed now all ppc64el autopkgtest runs of src:mariadb at https://ci.debian.net/packages/m/mariadb/testing/ppc64el/ This is still happening on latest kernel and latest src:mariadb in bookworm. The failing test varies, but they all have in common that they error on 'Database page corruption on disk'. autopkgtest [20:11:55]: starting date and time: 2023-04-08 20:11:55+ autopkgtest [20:12:17]: testbed running kernel: Linux 6.1.0-7-powerpc64le #1 SMP Debian 6.1.20-1 (2023-03-19) autopkgtest [20:12:39]: testing package mariadb version 1:10.11.2-1 Completed: Failed 6/1021 tests, 99.41% were successful. Failing test(s): main.innodb_ext_key main.statistics_upgrade_not_done Attached summary of downloading all recent logs and running: $ zgrep -e 'starting date' -e 'running kernel' -e 'testing package mariadb version' -e 'Completed: ' -e 'Failing test(s)' *.gz | tee mariadb-autopkgtest-ppc64el-summary.txt 30542346.log.gz:autopkgtest [16:38:18]: starting date and time: 2023-01-20 16:38:18+ 30542346.log.gz:autopkgtest [16:39:14]: testbed running kernel: Linux 5.10.0-20-powerpc64le #1 SMP Debian 5.10.158-2 (2022-12-13) 30542346.log.gz:autopkgtest [16:39:30]: testing package mariadb version 1:10.11.1-1 30542346.log.gz:Completed: All 1016 tests were successful. 31013059.log.gz:autopkgtest [23:16:23]: starting date and time: 2023-02-03 23:16:23+ 31013059.log.gz:autopkgtest [23:16:53]: testbed running kernel: Linux 5.10.0-20-powerpc64le #1 SMP Debian 5.10.158-2 (2022-12-13) 31013059.log.gz:autopkgtest [23:17:06]: testing package mariadb version 1:10.11.1-2 31013059.log.gz:Completed: All 1016 tests were successful. 31114152.log.gz:autopkgtest [10:00:31]: starting date and time: 2023-02-06 10:00:31+ 31114152.log.gz:autopkgtest [10:00:57]: testbed running kernel: Linux 5.10.0-21-powerpc64le #1 SMP Debian 5.10.162-1 (2023-01-21) 31114152.log.gz:autopkgtest [10:01:09]: testing package mariadb version 1:10.11.1-3 31114152.log.gz:Completed: Failed 2/1016 tests, 99.80% were successful. 31114152.log.gz:Failing test(s): main.xa_prepared_binlog_off main.update_use_source 31138628.log.gz:autopkgtest [06:52:36]: starting date and time: 2023-02-07 06:52:36+ 31138628.log.gz:autopkgtest [06:53:04]: testbed running kernel: Linux 5.10.0-21-powerpc64le #1 SMP Debian 5.10.162-1 (2023-01-21) 31138628.log.gz:autopkgtest [06:53:17]: testing package mariadb version 1:10.11.1-3 31138628.log.gz:Completed: All 1016 tests were successful. 31204767.log.gz:autopkgtest [12:32:51]: starting date and time: 2023-02-10 12:32:51+ 31204767.log.gz:autopkgtest [12:33:23]: testbed running kernel: Linux 5.10.0-21-powerpc64le #1 SMP Debian 5.10.162-1 (2023-01-21) 31204767.log.gz:autopkgtest [12:33:46]: testing package mariadb version 1:10.11.1-4 31204767.log.gz:Completed: Failed 2/1016 tests, 99.80% were successful. 31204767.log.gz:Failing test(s): main.innodb_ext_key main.order_by_innodb 31253808.log.gz:autopkgtest [19:05:34]: starting date and time: 2023-02-11 19:05:34+ 31253808.log.gz:autopkgtest [19:06:15]: testbed running kernel: Linux 5.10.0-21-powerpc64le #1 SMP Debian 5.10.162-1 (2023-01-21) 31253808.log.gz:autopkgtest [19:06:25]: testing package mariadb version 1:10.11.1-4 31253808.log.gz:Completed: All 1016 tests were successful. 31452860.log.gz:autopkgtest [09:50:34]: starting date and time: 2023-02-17 09:50:34+ 31452860.log.gz:autopkgtest [09:51:00]: testbed running kernel: Linux 5.10.0-21-powerpc64le #1 SMP Debian 5.10.162-1 (2023-01-21) 31452860.log.gz:autopkgtest [09:51:21]: testing package mariadb version 1:10.11.1-5 31452860.log.gz:Completed: Failed 6/1020 tests, 99.41% were successful. 31452860.log.gz:Failing test(s): main.ctype_utf8mb4_innodb main.index_merge_innodb 31480673.log.gz:autopkgtest [01:00:30]: starting date and time: 2023-02-18 01:00:30+ 31480673.log.gz:autopkgtest [01:01:00]: testbed running kernel: Linux 5.10.0-21-powerpc64le #1 SMP Debian 5.10.162-1 (2023-01-21) 31480673.log.gz:autopkgtest [01:01:17]: testing package mariadb version 1:10.11.2-1 31480673.log.gz:Completed: Failed 6/1021 tests, 99.41% were successful. 31480673.log.gz:Failing test(s): main.xa_prepared_binlog_off main.range_mrr_icp 31509348.log.gz:autopkgtest [05:09:32]: starting date and time: 2023-02-19 05:09:32+ 31509348.log.gz:autopkgtest [05:10:50]: testbed running kernel: Linux 5.10.0-21-powerpc64le #1 SMP Debian 5.10.162-1 (2023-01-21) 31509348.log.gz:autopkgtest [05:11:06]: testing package mariadb version 1:10.11.2-1 31509348.log.gz:Completed: Failed 3/1019 tests, 99.71% were successful. 31509348.log.gz:Failing test(s): main.ctype_utf8mb4_innodb
Bug#1032104: linux: ppc64el iouring corrupted read
> > On Sat, Mar 18, 2023 at 11:19:29PM -0700, Otto Kekäläinen wrote: > > > Any updates on this one? > > > > > > I am still seeing the main.index_merge_innodb failure in > > > https://buildd.debian.org/status/fetch.php?pkg=mariadb=ppc64el=1%3A10.11.2-2%7Eexp1=1678728871=0 > > > and rebuild > > > https://buildd.debian.org/status/fetch.php?pkg=mariadb=ppc64el=1%3A10.11.2-2%7Eexp1=1679174850=0. > > > > > > Logs show: Kernel: Linux 5.10.0-21-powerpc64le #1 SMP Debian > > > 5.10.162-1 (2023-01-21) ppc64el (ppc64le) > > > > Remember that with the 5.10.162 upstream version the io_uring code was > > rebased to the 5.15-stable one. So it is likely, and it maches the > > verison ranges, that the regression was introduced with this > > particular changes. Ideally someone with access to the given > > architecture, can verify that the issue is gone with the current > > 5.10.175 upstream (where there were several followup fixes, in > > particular e.g. a similar one for s390x), and if not, reports the > > problem to upstream. > > > > Paul Gevers asked if the issues are gone as well with 6.1.12-1 > > (or later 6.1.y series versions, which will land in bookworm). That > > would be valuable information to know as well to exclude we do not > > have the issue as well in bookworm. > > Were you able to verify this? No, not yet. I have not done new uploads to experimental after the one I mentioned and linked above from March 18th. The builds for unstable are passing because I forced the tests to run with regular fsync instead of native I/O in https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/fc1358087b39ac6520420c7bbae2e536bc86748d. I will test this again later but right now I don't want to do any extra uploads as the package is pending unblock and inclusion in Bullseye (Bug#1033811) and I don't want one single minor issue to jeopardize getting fixes for multiple major issues forward.
Bug#1032104: linux: ppc64el iouring corrupted read
Any updates on this one? I am still seeing the main.index_merge_innodb failure in https://buildd.debian.org/status/fetch.php?pkg=mariadb=ppc64el=1%3A10.11.2-2%7Eexp1=1678728871=0 and rebuild https://buildd.debian.org/status/fetch.php?pkg=mariadb=ppc64el=1%3A10.11.2-2%7Eexp1=1679174850=0. Logs show: Kernel: Linux 5.10.0-21-powerpc64le #1 SMP Debian 5.10.162-1 (2023-01-21) ppc64el (ppc64le)
Bug#1031773: mariadb-10.3.38.0+deb10u1: kmail fails after upgrading mariadb to 10.3.38.0+deb10u1
Forwarded: https://lists.launchpad.net/maria-discuss/msg06508.html This is most likely a duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031863
Bug#1029092: Don't update mysql-defaults in Debian testing/Bookworm too early
> On Tue, 17 Jan 2023 08:00:00 -0800 =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?= > wrote: > > This severity 'serious' bug should prevent the migration > > automatically. Close this bug when migration is free to proceed. > > I believe this has happened now. Do you think it should solve that issue > I was seeing? Potentially, but I need more info. This mysql-defaults definitely needs to migrate for the full repository view to be correct/complete. I was planning to do it 1-2 days after mariadb has migrated.
Bug#1030604: marked as done (mariadb breaks mariadb-10.6 autopkgtest: Variable 'innodb_compression_algorithm' can't be set to the value of 'lz4')
Control: found -1 1:10.11.2-1 Control: retitle -1 mariadb breaks mariadb-10.6 autopkgtest: provider plugins not installed Control: severity -1 normal Since https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/36 was merged it fixed Bug#1031116 (apt ordering broke Cacti autopkgtests) but now this came back - the mariadb-10.6 autopkgtests cannot pass as they will install mariadb-server version 1:10.11.2-1 which only works with the autopkgtests from 10.11 and the old autopkgtests in 10.6 will never pass running old tests with new binaries. This should just be ignored and eventually fixed by removing mariadb-10.6 from testing and unstable. This failure should just be ignored
Bug#1030510: Info received (Bug#1030510: Info received (Bug#1030510: Info received (mariadb: FTBFS on s390x: timeout)))
For the record, the failing Debian machines run: Linux ci-worker-s390x-01 5.10.0-21-s390x #1 SMP Debian 5.10.162-1 (2023-01-21) s390x GNU/Linux The passing Launchpad builders run: Linux bos02-s390x-013 5.4.0-137-generic #154-Ubuntu SMP Thu Jan 5 17:03:11 UTC 2023 s390x
Bug#1030604: marked as pending in mariadb
Control: tag -1 pending Hello, Bug #1030604 in mariadb reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/5545bb341808cef8a4227b55b0c75e331cc48c96 Have all compression plugins as Depends for mariadb-server (Closes: #1030604) This will ensure 100% backwards compatibility with previous versions of MariaDB in Debian, and also the old src:mariadb-10.6 autopkgtests pass. - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030604 - https://ci.debian.net/packages/m/mariadb-10.6/ This commit can later be reverted if needed and compression method plugins demoted back to Recommends. (this message was generated automatically) -- Greetings https://bugs.debian.org/1030604
Bug#1030510: Info received (Bug#1030510: Info received (Bug#1030510: Info received (mariadb: FTBFS on s390x: timeout)))
Control: severity -1 normal Control: tags -1 help The s390x build is still failing after 5 retries at https://buildd.debian.org/status/package.php?p=mariadb. The issue seems to be with Debian buildd, as the Launchpad s390x build passed just fine without the need to retry anything: https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mariadb-10.11/+builds?build_text=_state=all It seems to crash on different tests every time. I could disable the entire test suite, but that feels like a bad idea. I need help - if the s390x build does not pass, the 10.11 cannot enter Debian testing (Bookworm). (this email is for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030510)
Bug#1030510: Info received (Bug#1030510: Info received (mariadb: FTBFS on s390x: timeout))
And again same phenomenon in https://buildd.debian.org/status/fetch.php?pkg=mariadb=s390x=1%3A10.11.1-3=1675697634=0. Copy-pasting more context to track if the main.xml is the preceding test other times as well: main.group_by_innodb 'innodb'w2 [ pass ] 11 main.group_min_max_innodb 'innodb' w2 [ pass ] 21 main.host_cache_size_functionality 'innodb' w2 [ fail ] Found warnings/errors in server log file! Test ended at 2023-02-06 13:37:33 line Attempting backtrace. You can use the following information to find out ^ Found warnings in /<>/builddir/mysql-test/var/2/log/mysqld.1.err ok - found 'core' (0/5) Core generated by '/<>/builddir/sql/mariadbd' Output from gdb follows. The first stack trace is from the failing thread. The following stack traces are from all threads (so the failing one is duplicated). -- warning: Can't open file anon_inode:[io_uring] which was expanded to anon_inode:[io_uring] during file-backed mapping note processing warning: Can't open file anon_inode:[io_uring] which was expanded to anon_inode:[io_uring] during file-backed mapping note processing [New LWP 4037916] [New LWP 4037923] [New LWP 4037925] [New LWP 4037924] [New LWP 4037934] [New LWP 4038289] [New LWP 4038342] [New LWP 4038372] [New LWP 4037931] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1". Core was generated by `/<>/builddir/sql/mariadbd --defaults-group-su'. Program terminated with signal SIGABRT, Aborted. #0 0x03ffab01861a in ?? () from /lib/s390x-linux-gnu/libc.so.6 [Current thread is 1 (Thread 0x3ffabeea820 (LWP 4037916))] #0 0x03ffab01861a in ?? () from /lib/s390x-linux-gnu/libc.so.6 #1 0x02aa242907f4 in handle_fatal_signal (sig=) at ./sql/signal_handler.cc:355 #2 #3 0x03ffab0130d2 in ?? () from /lib/s390x-linux-gnu/libc.so.6 #4 0x03ffab015c32 in pthread_cond_wait () from /lib/s390x-linux-gnu/libc.so.6 #5 0x02aa2468bb52 in buf_dblwr_t::flush_buffered_writes (this=this@entry=0x2aa25aeaa80 , size=size@entry=64) at ./storage/innobase/buf/buf0dblwr.cc:576 #6 0x02aa2468c082 in buf_dblwr_t::flush_buffered_writes (this=0x2aa25aeaa80 ) at ./storage/innobase/buf/buf0dblwr.cc:719 #7 0x02aa24693334 in buf_flush_list (lsn=4396608790832, max_n=24) at ./storage/innobase/buf/buf0flu.cc:1508 #8 buf_flush_list (max_n=24, lsn=4396608790832) at ./storage/innobase/buf/buf0flu.cc:1478 #9 0x02aa23ef6d52 in buf_flush_buffer_pool () at ./storage/innobase/buf/buf0flu.cc:2546 #10 0x02aa23ee959c in logs_empty_and_mark_files_at_shutdown () at ./storage/innobase/log/log0log.cc:1163 #11 0x02aa24636174 in innodb_shutdown () at ./storage/innobase/srv/srv0start.cc:1949 #12 0x02aa245447a2 in innobase_end () at ./storage/innobase/handler/ha_innodb.cc:4284 #13 innobase_end () at ./storage/innobase/handler/ha_innodb.cc:4271 #14 0x02aa24293c9e in ha_finalize_handlerton (plugin=0x2aa26381790) at ./sql/handler.cc:596 #15 0x02aa24056e06 in plugin_deinitialize (plugin=0x2aa26381790, ref_check=ref_check@entry=true) at ./sql/sql_plugin.cc:1273 #16 0x02aa24059bd0 in reap_plugins () at ./sql/sql_plugin.cc:1344 #17 0x02aa2405a6b0 in plugin_shutdown () at ./sql/sql_plugin.cc:2052 #18 0x02aa23f3ecec in clean_up (print_message=) at ./sql/mysqld.cc:2000 #19 0x02aa23f4a4d8 in clean_up (print_message=true) at ./sql/mysqld.cc:1972 #20 mysqld_main (argc=, argv=) at ./sql/mysqld.cc:6024 #21 0x03ffaafab84a in ?? () from /lib/s390x-linux-gnu/libc.so.6 #22 0x03ffaafab932 in __libc_start_main () from /lib/s390x-linux-gnu/libc.so.6 #23 0x02aa23f3d378 in _start () main.xml w2 [ pass ] 19 worker[1] Test still running: main.innodb_ext_key worker[1] Test still running: main.innodb_ext_key worker[1] Test still running: main.innodb_ext_key worker[1] Test still running: main.innodb_ext_key worker[1] Test still running: main.innodb_ext_key worker[1] Trying to dump core for [mysqltest - pid: 4034646, winpid: 4034646] worker[1] Trying to dump core for [mysqld.1 - pid: 4034628, winpid: 4034628] main.innodb_ext_key 'innodb,off,unoptimized' w1 [ fail ] timeout after 7200 seconds Test ended at 2023-02-06 15:33:16 Test case timeout after 7200 seconds == /<>/builddir/mysql-test/var/1/tmp/analyze-timeout-mysqld.1.err == mysqltest: Could not open connection 'default' after 500 attempts: 2002 Can't connect to local server through socket '/<>/builddir/mysql-test/var/tm' (111) - found 'core' (1/5) Core generated by '/<>/builddir/sql/mariadbd' Output from gdb follows. The first stack trace is from the failing thread. The following stack traces are from all threads (so the failing one is duplicated). -- warning: Can't open file anon_inode:[io_uring] which was expanded to anon_inode:[io_uring] during file-backed mapping note processing warning: Can't open file anon_inode:[io_uring] which was expanded to
Bug#1030510: Info received (mariadb: FTBFS on s390x: timeout)
Control: retitle -1 mariadb: FTBFS on s390x: crash on munmap(), free(), aligned_free() For the record, the latest build https://buildd.debian.org/status/fetch.php?pkg=mariadb=s390x=1%3A10.11.1-3=1675662468=0 shows other test failures again, but the stack trace seem to have munmap(), free(), aligned_free() etc in common: main.bootstrap_innodb 'innodb' w2 [ fail ] Found warnings/errors in server log file! Test ended at 2023-02-06 05:41:47 line Attempting backtrace. You can use the following information to find out ^ Found warnings in /<>/builddir/mysql-test/var/2/log/mysqld.1.err ok - found 'core' (0/5) Core generated by '/<>/builddir/sql/mariadbd' Output from gdb follows. The first stack trace is from the failing thread. The following stack traces are from all threads (so the failing one is duplicated). -- [New LWP 2264728] [New LWP 2264825] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1". Core was generated by `/<>/builddir/sql/mariadbd --defaults-group-su'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x03ffb4448992 in kill () from /lib/s390x-linux-gnu/libc.so.6 [Current thread is 1 (Thread 0x3ffb536a820 (LWP 2264728))] #0 0x03ffb4448992 in kill () from /lib/s390x-linux-gnu/libc.so.6 #1 0x02aa06f107c4 in handle_fatal_signal (sig=) at ./sql/signal_handler.cc:367 #2 #3 0x02aa073fc26a in my_read (Filedes=, Buffer=0xd , Count=4096, MyFlags=) at ./mysys/my_read.c:63 #4 0x02aa06f10266 in output_core_info () at ./sql/signal_handler.cc:90 #5 0x02aa06f10792 in handle_fatal_signal (sig=) at ./sql/signal_handler.cc:351 #6 #7 0x03ffb450e632 in munmap () from /lib/s390x-linux-gnu/libc.so.6 #8 0x03ffb44a7790 in free () from /lib/s390x-linux-gnu/libc.so.6 #9 0x02aa07140022 in aligned_free (ptr=) at ./include/aligned.h:37 #10 pfs_free (ptr=, size=0, klass=0x2aa086c6900 ) at ./storage/perfschema/pfs_global.cc:83 #11 pfs_free (ptr=, size=0, klass=0x2aa086c6900 ) at ./storage/perfschema/pfs_global.cc:78 #12 pfs_free_array (klass=0x2aa086c6900 , n=n@entry=256, size=size@entry=32, ptr=) at ./storage/perfschema/pfs_global.cc:134 #13 0x02aa07135e82 in PFS_thread_allocator::free_array (this=, array=array@entry=0x2aa08f4fd30) at ./storage/perfschema/pfs_buffer_container.cc:659 #14 0x02aa071425da in PFS_buffer_scalable_container::cleanup (this=) at ./storage/perfschema/pfs_buffer_container.h:506 #15 PFS_buffer_scalable_container::cleanup (this=) at ./storage/perfschema/pfs_buffer_container.h:491 #16 cleanup_instruments () at ./storage/perfschema/pfs_instr.cc:233 #17 0x02aa0715000c in cleanup_performance_schema () at ./storage/perfschema/pfs_server.cc:296 #18 0x02aa071504f0 in shutdown_performance_schema () at ./storage/perfschema/pfs_server.cc:326 #19 0x02aa06bbf912 in mysqld_exit (exit_code=exit_code@entry=0) at ./sql/mysqld.cc:1943 #20 0x02aa06bca4fe in mysqld_main (argc=, argv=) at ./sql/mysqld.cc:6040 #21 0x03ffb442b84a in ?? () from /lib/s390x-linux-gnu/libc.so.6 #22 0x03ffb442b932 in __libc_start_main () from /lib/s390x-linux-gnu/libc.so.6 #23 0x02aa06bbd378 in _start () main.host_cache_size_functionality 'innodb' w2 [ fail ] Found warnings/errors in server log file! Test ended at 2023-02-06 05:44:47 line Attempting backtrace. You can use the following information to find out ^ Found warnings in /<>/builddir/mysql-test/var/2/log/mysqld.1.err ok - found 'core' (2/5) Core generated by '/<>/builddir/sql/mariadbd' Output from gdb follows. The first stack trace is from the failing thread. The following stack traces are from all threads (so the failing one is duplicated). -- [New LWP 2267523] [New LWP 2268734] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1". Core was generated by `/<>/builddir/sql/mariadbd --defaults-group-su'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x03ffa7e48992 in kill () from /lib/s390x-linux-gnu/libc.so.6 [Current thread is 1 (Thread 0x3ffa8d6a820 (LWP 2267523))] #0 0x03ffa7e48992 in kill () from /lib/s390x-linux-gnu/libc.so.6 #1 0x02aa0f2907c4 in handle_fatal_signal (sig=) at ./sql/signal_handler.cc:367 #2 #3 0x02aa0f77c26a in my_read (Filedes=, Buffer=0xd , Count=4096, MyFlags=) at ./mysys/my_read.c:63 #4 0x02aa0f290266 in output_core_info () at ./sql/signal_handler.cc:90 #5 0x02aa0f290792 in handle_fatal_signal (sig=) at ./sql/signal_handler.cc:351 #6 #7 0x03ffa7f0e632 in munmap () from /lib/s390x-linux-gnu/libc.so.6 #8 0x03ffa7ea7790 in free () from /lib/s390x-linux-gnu/libc.so.6 #9 0x02aa0f4c0022 in aligned_free (ptr=) at ./include/aligned.h:37 #10 pfs_free (ptr=, size=2841600, klass=0x2aa10a46700 ) at ./storage/perfschema/pfs_global.cc:83 #11 pfs_free (ptr=, size=2841600, klass=0x2aa10a46700 ) at
Bug#1030604: mariadb breaks mariadb-10.6 autopkgtest: Variable 'innodb_compression_algorithm' can't be set to the value of 'lz4'
Hi! The error message "Variable 'innodb_compression_algorithm' can't be set to the value of 'lz4'" is from the first test, and it fails. Actually all tests fail because in MariaDB 10.11 the compression methods are packaged in separate packages. The root cause here is that the test in 10.6 depends on simply 'mariadb-server'. With a new 'mariadb-server' from 10.11 the test of 10.6 will fail. The test would not fail if the autopkgtests originally had a dependency on 'mariadb-server-10.6'. It does not seem worth the effort to upload a new src:mariadb-10.6 just to fix this. It is a pure test issue and not a symptom of a real failure. Can we have a temporary override to shut down the src:mariadb-10.6 autopkgtests in Debian CI so that 10.11 can enter Debian testing/Bookworm and I can then file request to remove src:mariadb-10.6 from testing and unstable?
Bug#1030510: mariadb: FTBFS on s390x: timeout
After restarting the build there is no longer a timeout, but a crash: main.plugin_auth 'innodb'w1 [ fail ] Found warnings/errors in server log file! Test ended at 2023-02-05 09:41:56 line Attempting backtrace. You can use the following information to find out ^ Found warnings in /<>/builddir/mysql-test/var/1/log/mysqld.1.err ok - found 'core' (0/5) Core generated by '/<>/builddir/sql/mariadbd' Output from gdb follows. The first stack trace is from the failing thread. The following stack traces are from all threads (so the failing one is duplicated). -- [New LWP 460078] [New LWP 460124] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1". Core was generated by `/<>/builddir/sql/mariadbd --defaults-group-su'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x03ff99c48992 in kill () from /lib/s390x-linux-gnu/libc.so.6 [Current thread is 1 (Thread 0x3ff9ab6a820 (LWP 460078))] #0 0x03ff99c48992 in kill () from /lib/s390x-linux-gnu/libc.so.6 #1 0x02aa226907c4 in handle_fatal_signal (sig=) at ./sql/signal_handler.cc:367 #2 #3 0x02aa22b7c26a in my_read (Filedes=, Buffer=0x3ff9ab6a820 "", Count=4096, MyFlags=) at ./mysys/my_read.c:63 #4 0x02aa22690266 in output_core_info () at ./sql/signal_handler.cc:90 #5 0x02aa22690792 in handle_fatal_signal (sig=) at ./sql/signal_handler.cc:351 #6 #7 0x03ff99d0e632 in munmap () from /lib/s390x-linux-gnu/libc.so.6 #8 0x03ff99ca7790 in free () from /lib/s390x-linux-gnu/libc.so.6 #9 0x02aa228bfe6e in aligned_free (ptr=) at ./include/aligned.h:37 #10 pfs_free (ptr=, size=2048000, klass=0x2aa23e47900 ) at ./storage/perfschema/pfs_global.cc:83 #11 pfs_free (klass=0x2aa23e47900 , size=size@entry=2048000, ptr=) at ./storage/perfschema/pfs_global.cc:78 #12 0x02aa228b5fe6 in PFS_thread_allocator::free_array (this=, array=array@entry=0x2aa24cf4d30) at ./storage/perfschema/pfs_buffer_container.cc:715 #13 0x02aa228c25da in PFS_buffer_scalable_container::cleanup (this=) at ./storage/perfschema/pfs_buffer_container.h:506 #14 PFS_buffer_scalable_container::cleanup (this=) at ./storage/perfschema/pfs_buffer_container.h:491 #15 cleanup_instruments () at ./storage/perfschema/pfs_instr.cc:233 #16 0x02aa228d000c in cleanup_performance_schema () at ./storage/perfschema/pfs_server.cc:296 #17 0x02aa228d04f0 in shutdown_performance_schema () at ./storage/perfschema/pfs_server.cc:326 #18 0x02aa2233f912 in mysqld_exit (exit_code=exit_code@entry=0) at ./sql/mysqld.cc:1943 #19 0x02aa2234a4fe in mysqld_main (argc=, argv=) at ./sql/mysqld.cc:6040 #20 0x03ff99c2b84a in ?? () from /lib/s390x-linux-gnu/libc.so.6 #21 0x03ff99c2b932 in __libc_start_main () from /lib/s390x-linux-gnu/libc.so.6 #22 0x02aa2233d378 in _start () A previous restart also had: main.mysql_upgrade 'innodb' w1 [ fail ] Found warnings/errors in server log file! [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1". Core was generated by `/<>/builddir/sql/mariadbd --defaults-group-su'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x03ffaa0c8992 in kill () from /lib/s390x-linux-gnu/libc.so.6 [Current thread is 1 (Thread 0x3ffaafea820 (LWP 1668996))] #0 0x03ffaa0c8992 in kill () from /lib/s390x-linux-gnu/libc.so.6 #1 0x02aa26c107c4 in handle_fatal_signal (sig=) at ./sql/signal_handler.cc:367 #2 #3 0x02aa270fc26a in my_read (Filedes=, Buffer=0x696c646469722f6d , Count=4096, MyFlags=) at ./mysys/my_read.c:63 #4 0x02aa26c10266 in output_core_info () at ./sql/signal_handler.cc:90 #5 0x02aa26c10792 in handle_fatal_signal (sig=) at ./sql/signal_handler.cc:351 #6 #7 0x03ffaa18e632 in munmap () from /lib/s390x-linux-gnu/libc.so.6 #8 0x03ffaa127790 in free () from /lib/s390x-linux-gnu/libc.so.6 #9 0x02aa26e40022 in aligned_free (ptr=) at ./include/aligned.h:37 #10 pfs_free (ptr=, size=2304000, klass=0x2aa283c8f00 ) at ./storage/perfschema/pfs_global.cc:83 #11 pfs_free (ptr=, size=2304000, klass=0x2aa283c8f00 ) at ./storage/perfschema/pfs_global.cc:78 #12 pfs_free_array (klass=0x2aa283c8f00 , n=n@entry=32000, size=size@entry=72, ptr=) at ./storage/perfschema/pfs_global.cc:134 #13 0x02aa26e36680 in PFS_user_allocator::free_array (this=, array=array@entry=0x2aa297ac0a0) at ./storage/perfschema/pfs_buffer_container.cc:875 #14 0x02aa26e53786 in PFS_buffer_scalable_container::cleanup (this=) at ./storage/perfschema/pfs_buffer_container.h:506 #15 PFS_buffer_scalable_container::cleanup (this=) at ./storage/perfschema/pfs_buffer_container.h:491 #16 cleanup_user () at ./storage/perfschema/pfs_user.cc:63 #17 0x02aa26e4ffb8 in cleanup_performance_schema () at ./storage/perfschema/pfs_server.cc:275 #18 0x02aa26e504f0 in shutdown_performance_schema () at
Bug#1029136: MariaDB configuration files not properly migrated on switch to unversioned packages
> > This is now solved on > > https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/31 > > Mangling the maintainers scripts of another package is a delicate issue > as it's often fragile and can cause hard to debug failures in corner cases. > > Personally, I would have turned the versioned packages into empty > transitional packages. This would have made the upgrade process much > smoother and avoided this issue altogether (the new empty versioned > packages would have no maintainer scripts). > It's also common practice for such use cases. > > Any reason why you didn't consider this approach? I did write the code for empty packages and tested it (as visible in the merge request above) but it would have created much more moving parts and failures elsewhere. Fixing the maintainer scripts proved to be the most elegant solution.
Bug#1029136: MariaDB configuration files not properly migrated on switch to unversioned packages
This is now solved on https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/31
Bug#1029136: MariaDB configuration files not properly migrated on switch to unversioned packages
Hi! Here is the situation after 'apt full-upgrade -y': $ dpkg -l | grep -iE 'maria|mysql|galera' || true # List installed ii default-mysql-client 1.1.0 all MySQL database client binaries (metapackage) ii default-mysql-client-core 1.1.0 all MySQL database core client binaries (metapackage) ii default-mysql-server 1.1.0 all MySQL database server binaries and system database setup (metapackage) ii default-mysql-server-core 1.1.0 all MySQL database server binaries (metapackage) ii galera-4 26.4.11-1+b2 amd64Replication framework for transactional applications ii libdbd-mariadb-perl1.22-1+b1 amd64Perl5 database interface to the MariaDB/MySQL databases ii libmariadb-dev 1:10.11.1-2 amd64MariaDB database development files ii libmariadb-dev-compat:amd641:10.11.1-2 amd64MariaDB Connector/C, compatibility symlinks ii libmariadb-java2.7.6-1 all Java database driver for MariaDB and MySQL ii libmariadb3:amd64 1:10.11.1-2 amd64MariaDB database client library ii libmariadbd-dev1:10.11.1-2 amd64MariaDB embedded database, development files ii libmariadbd19:amd641:10.11.1-2 amd64MariaDB embedded database, shared library ii mariadb-backup 1:10.11.1-2 amd64Backup tool for MariaDB server ii mariadb-client 1:10.11.1-2 amd64MariaDB database client binaries rc mariadb-client-10.61:10.6.11-2 amd64MariaDB database client binaries ii mariadb-client-core1:10.11.1-2 amd64MariaDB database core client binaries ii mariadb-common 1:10.11.1-2 all MariaDB common configuration files ii mariadb-plugin-connect 1:10.11.1-2 amd64Connect storage engine for MariaDB ii mariadb-plugin-cracklib-password-check 1:10.11.1-2 amd64CrackLib Password Validation Plugin for MariaDB ii mariadb-plugin-gssapi-client:amd64 1:10.11.1-2 amd64GSSAPI authentication plugin for MariaDB client ii mariadb-plugin-gssapi-server 1:10.11.1-2 amd64GSSAPI authentication plugin for MariaDB server ii mariadb-plugin-mroonga 1:10.11.1-2 amd64Mroonga storage engine for MariaDB ii mariadb-plugin-oqgraph 1:10.11.1-2 amd64OQGraph storage engine for MariaDB ii mariadb-plugin-rocksdb 1:10.11.1-2 amd64RocksDB storage engine for MariaDB ii mariadb-plugin-s3 1:10.11.1-2 amd64Amazon S3 archival storage engine for MariaDB ii mariadb-plugin-spider 1:10.11.1-2 amd64Spider storage engine for MariaDB ii mariadb-server 1:10.11.1-2 amd64MariaDB database server binaries rc mariadb-server-10.61:10.6.11-2 amd64MariaDB database server binaries ii mariadb-server-core1:10.11.1-2 amd64MariaDB database core server files ii mariadb-test 1:10.11.1-2 amd64MariaDB database regression test suite ii mariadb-test-data 1:10.11.1-2 all MariaDB database regression test suite - data files ii mysql-common 5.8+1.1.0 all MySQL database common files, e.g. /etc/mysql/my.cnf ii python3-mysqldb1.4.6-2 amd64Python interface to MySQL $ find /etc -name '*mariadb*' -ls -or -name '*mysql*' -ls 45114 8 -rwxr-xr-x 1 root root 6387 Jan 18 09:40 /etc/init.d/mariadb 45118 4 -rw-r--r-- 1 root root 1859 Jan 18 09:40 /etc/logrotate.d/mariadb 42460 4 lrwxrwxrwx 1 root root 17 Jan 30 06:23 /etc/rc0.d/K01mariadb -> ../init.d/mariadb 42461 4 lrwxrwxrwx 1 root root 17 Jan 30 06:23 /etc/rc1.d/K01mariadb -> ../init.d/mariadb 42456 4 lrwxrwxrwx 1 root root 17 Jan 30 06:23 /etc/rc2.d/S01mariadb -> ../init.d/mariadb 42457 4 lrwxrwxrwx 1 root root 17 Jan 30 06:23 /etc/rc3.d/S01mariadb -> ../init.d/mariadb 42458 4 lrwxrwxrwx 1 root root 17 Jan 30 06:23 /etc/rc4.d/S01mariadb -> ../init.d/mariadb 42459 4 lrwxrwxrwx 1 root root 17 Jan 30 06:23 /etc/rc5.d/S01mariadb -> ../init.d/mariadb 42462 4 lrwxrwxrwx 1 root root 17 Jan 30 06:23 /etc/rc6.d/K01mariadb -> ../init.d/mariadb 42452 4 lrwxrwxrwx 1 root root 35 Jan 30 06:23 /etc/systemd/system/multi-user.target.wants/mariadb.service ->
Bug#1029136: MariaDB configuration files not properly migrated on switch to unversioned packages
Hi! I managed now to reproduce this. The purge step is not relevant, but simply the upgrade itself. In clean Docker container with Debian unstable: $ apt install -y mariadb-server-10.6 -> install successful $ apt full-upgrade -y -> does nothing $ service mariadb restart Stopping MariaDB database server: mariadbd. Starting MariaDB database server: mariadbd. $ apt install mariadb-server -y The following packages will be REMOVED: mariadb-client-10.6 mariadb-client-core-10.6 mariadb-server-10.6 mariadb-server-core-10.6 The following NEW packages will be installed: mariadb-client mariadb-client-core mariadb-server mariadb-server-core pv $ service mariadb restart mariadb: unrecognized service -> upgrade successful, but service stopped working - the service file has no executable bit anymore. $ dpkg -l | grep -iE 'maria|mysql|galera' ii galera-4 26.4.11-1+b2 amd64 Replication framework for transactional applications ii libdbd-mariadb-perl 1.22-1+b1 amd64Perl5 database interface to the MariaDB/MySQL databases ii libmariadb3:amd64 1:10.11.1-1amd64MariaDB database client library ii mariadb-client1:10.11.1-1amd64MariaDB database client binaries rc mariadb-client-10.6 1:10.6.11-2amd64MariaDB database client binaries ii mariadb-client-core 1:10.11.1-1amd64MariaDB database core client binaries ii mariadb-common1:10.11.1-1all MariaDB common configuration files ii mariadb-server1:10.11.1-1amd64MariaDB database server binaries rc mariadb-server-10.6 1:10.6.11-2amd64MariaDB database server binaries ii mariadb-server-core 1:10.11.1-1amd64MariaDB database core server files ii mysql-common 5.8+1.1.0 all MySQL database common files, e.g. /etc/mysql/my.cnf $ find /etc -name '*mariadb*' -type f -ls -rw-r--r-- 1 root root 6387 Jan 15 22:45 /etc/init.d/mariadb -rw-r--r-- 1 root root 1859 Jan 15 22:45 /etc/logrotate.d/mariadb -rw-r--r-- 1 root root 1126 Jan 8 01:45 /etc/mysql/mariadb.cnf -rw-r--r-- 1 root root 730 Jan 3 06:42 /etc/apparmor.d/usr.sbin.mariadbd -rw-r--r-- 1 root root 716 Jan 3 06:42 /etc/logcheck/ignore.d.paranoid/mariadb-server-10_6 -rw-r--r-- 1 root root 716 Jan 15 22:45 /etc/logcheck/ignore.d.paranoid/mariadb-server -rw-r--r-- 1 root root 2153 Jan 3 06:42 /etc/logcheck/ignore.d.server/mariadb-server-10_6 -rw-r--r-- 1 root root 2153 Jan 15 22:45 /etc/logcheck/ignore.d.server/mariadb-server -rw-r--r-- 1 root root 2153 Jan 3 06:42 /etc/logcheck/ignore.d.workstation/mariadb-server-10_6 -rw-r--r-- 1 root root 2153 Jan 15 22:45 /etc/logcheck/ignore.d.workstation/mariadb-server $ apt purge 'mariadb-*-10.6' -y The following packages will be REMOVED: mariadb-client-10.6* mariadb-server-10.6* $ find /etc -name '*mariadb*' -type f -ls -rw-r--r-- 1 root root 6387 Jan 15 22:45 /etc/init.d/mariadb -rw-r--r-- 1 root root 1859 Jan 15 22:45 /etc/logrotate.d/mariadb -rw-r--r-- 1 root root 1126 Jan 8 01:45 /etc/mysql/mariadb.cnf -rw-r--r-- 1 root root 730 Jan 3 06:42 /etc/apparmor.d/usr.sbin.mariadbd -rw-r--r-- 1 root root 716 Jan 15 22:45 /etc/logcheck/ignore.d.paranoid/mariadb-server -rw-r--r-- 1 root root 2153 Jan 15 22:45 /etc/logcheck/ignore.d.server/mariadb-server -rw-r--r-- 1 root root 2153 Jan 15 22:45 /etc/logcheck/ignore.d.workstation/mariadb-server -> purge works as expected
Bug#1029136: MariaDB configuration files not properly migrated on switch to unversioned packages
Hi! I have been frantically trying to reproduce the issue you reported. Would you be able to describe more in detail what was the situation before and after you upgraded and what commands exactly did you do to execute the upgrade (apt upgrade, apt full-upgrade, apt-get, aptitude)? We might very well have a broken upgrade scenario but for me to be able to fix it I need to have a way to reproduce it so I can validate a potential fix.
Bug#1029136: MariaDB configuration files not properly migrated on switch to unversioned packages
Hi! Thanks for reporting the issue. I saw this earlier and fixed it via https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/dd3a058ebec877da50aadc9f8909d61ac634430a - but cleary the fix does not fully work as you ran into this again. I will dive deeper. - Otto
Bug#1029092: Don't update mysql-defaults in Debian testing/Bookworm too early
Package: mysql-defaults Version: 1.1.0 Severity: serious Owner: Otto Kekäläinen Don't allow mysql-defaults into testing/Bookworm before MariaDB 1:10.11.1-1 has entered it first. There is no package 'mariadb-server-core' in MariaDB 1:10.6.11-2 and thus the defaults pointer would fail. This severity 'serious' bug should prevent the migration automatically. Close this bug when migration is free to proceed.
Bug#1024515: Acknowledgement (mariadb-10.6: FTBFS on s390x: test main.order_by_innodb failed with type 'ref')
I did a re-run today and surprisingly it passed: main.order_by_innodb 'innodb'w2 [ pass ] 84 https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.6=s390x=1%3A10.6.11-1=1670206361=0 Maybe the issue is sporadic? But also the first day I saw this I re-ran the build and it did not pass, so could also be the test behaviour was dependant on some dependency that updated in the past week?
Bug#1010508: Index Crash multiple times after update
Control: tags -1 moreinfo unreproducible This bug report lacks details to be able to reproduce it or even to link it with an upstream bug report. There is nothing that can be done unless the submitted provides more information or steps to reproduce.
Bug#1024515: mariadb-10.6: FTBFS on s390x: test main.order_by_innodb failed with type 'ref'
Source: mariadb-10.6 Version: 1:10.6.11-1 Tags: ftbfs User: debian-s...@lists.debian.org Usertags: s390x X-Debbugs-CC: debian-s...@lists.debian.org Severity: serious Justification: fails to build from source on official Debian architecture After upload of mariadb-10.6 1:10.6.11-1 I noticed that s390x builds at https://buildd.debian.org/status/package.php?p=mariadb-10.6 were failing: main.order_by_innodb 'innodb'w2 [ fail ] Test ended at 2022-11-20 00:18:24 CURRENT_TEST: main.order_by_innodb --- /<>/mysql-test/main/order_by_innodb.result 2022-11-03 10:20:33.0 + +++ /<>/mysql-test/main/order_by_innodb.reject 2022-11-20 00:18:24.074583262 + @@ -220,6 +220,6 @@ id select_type table type possible_keys key key_len ref rows Extra 1 PRIMARY t1 index NULL PRIMARY 4 NULL # Using index 1 PRIMARY t2 eq_ref PRIMARY,id2 PRIMARY 4 func # Using where -2 DEPENDENT SUBQUERY dd range id2,for_latest_sort for_latest_sort 6 NULL # Using where +2 DEPENDENT SUBQUERY dd ref id2,for_latest_sort id2 4 test.t1.id # Using where; Using filesort drop table t1,t2; # End of 10.2 tests I restarted the build, and failure repeated, so this is not sporadic. This is a regression as s390x builds used to work on MariaD 10.6.10-1: https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.6=s390x=1%3A10.6.10-1%2Bb1=1665890624=0 Please help by providing info on this bug report or - preferably - submit a MR to fix this: https://salsa.debian.org/mariadb-team/mariadb-server/-/wikis/Contributing-to-MariaDB-packaging-in-Debian
Bug#1007954: [debian-mysql] Bug#1007954: galera-4 FTBFS on IPV6-only buildds
Hi! Thanks for looking into this. Can you elaborate why you filed this on 26.4.8 and not latest 26.4.10? Builds are passing. Thus tests indicate that there is no issue. What is the broken thing exactly and since tests are passing, how will we verify that the broken thing is fixed or still broken?
Bug#1006702: [debian-mysql] Bug#1006702: mariadb-10.6: Baseline violation on at least i386 via CXXFLAGS
Control: Severity -1 wishlist Based on replies from Daniel and Marko this code section is indeed correct. Also, based on git blame the section you suggest to be removed was not added in a MariaDB version. However, instead of closing this bug report as invalid, I leave it open as a wishlist item in case somebody would have a suggestion / upstream Pull Request / downstream Merge Request on how to rewrite it in a better way or at least how to properly document it with inline comments to avoid confusion about how it works. Current build status and FTBFS bugs filed for mariadb-10.6 are listed at https://buildd.debian.org/status/package.php?p=mariadb-10.6 Currently PowerPC and PowerPC 64 are failing, but ppc64el is passing. Any contributions to further debug or even fix the remaining issues are naturally welcome!
Bug#1002087: Bug#1004151: Skip test ruby-mysql2/0.5.3-3 for mariadb-10.6
> On 21-01-2022 21:11, Otto Kekäläinen wrote: > > Currently mariadb-10.6 is blocked from migrating to testing due to > > test failure in ruby-mysql2/0.5.3-3 > > I just uploaded a fix. The bug report already had the solution since > January 5. Thanks! Please submit to https://salsa.debian.org/ruby-team/ruby-mysql2 too, now the change went past version control as a direct upload.
Bug#1002087: MariaDB 10.6 regressed ruby-mysql2
FYI: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004151 Filed skip-test request to release team to get mariadb-10.6 migrate from unstable to testing.
Bug#1002087: MariaDB 10.6 regressed ruby-mysql2
Status update: We are currently waiting for upstream ruby-mysql2 to make a new release 0.5.4 which would include the fix mentioned below. Tracking and comment at https://github.com/brianmario/mysql2/issues/1179#issuecomment-1013950778 On Tue, Jan 4, 2022 at 4:26 PM Daniel Black wrote: > > FYI message forward to > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002087 > > > On Thu, Dec 23, 2021 at 10:40 AM Daniel Black wrote: > > > >expected Mysql2::Error with message matching /Lost connection to > > MySQL server/, got # > to server during query> with backtrace: > > > > Our error message changed. > > > > ruby-mysql2 already fixed the test upstream - > > https://github.com/brianmario/mysql2/commit/cca57b97ad6d1b1b985376be110b89d2b487dea6 > > > > > > On Thu, Dec 23, 2021 at 4:47 AM Otto Kekäläinen wrote: > > > > > > Hello! > > > > > > Looking at https://tracker.debian.org/pkg/mariadb-10.6 it seems mariadb > > > 1.10.6.5-2 is currently blocked from progressing from Debian unstable to > > > testing due to Debian-CI/autopkgtests failures on package ruby-mysql2. > > > > > > This is a regression from 10.5. Could somebody please investigate? > > > > > > - Otto
Bug#1001385: [debian-mysql] Bug#1001385: mariadb-client-10.5: authentification fails while the credentials are ok
Control: severity -1 wishlist On Thu, Dec 9, 2021 at 5:00 AM Anthony Bourguignon wrote: ... > I’m having an issue with the mariadb-client in bullseye. I can’t connect > to a local server using the mariadb client. > > To reproduce the bug : > - Install bullseye > - Install mariadb-server and mariadb-client > - connect as root and create a database and a user : > create database testbug; > grant all privileges on testbug.* to 'testbug'@'127.0.0.1' > identified by 's3cr3t'; > - exit the client > - try to connect with those credentials : > mariadb -h 127.0.0.1 -u testbug -p testbug > > You can’t connect and get an error : > ERROR 1045 (28000): Access denied for user 'testbug'@'localhost' (using > password: YES) You granted permissions to 'testbug'@'127.0.0.1' but you are connecting from 'testbug'@'localhost'. Grant permissions to the hostname (not IP) and try again. Also report back here if that solved it for you, so we can close the bug report. Thanks!
Bug#996028: [debian-mysql] Bug#996028: InnoDB: corrupted TRX_NO after upgrading to 10.3.31
Control: severity -1 normal On Thu, Oct 21, 2021 at 9:24 PM Marc Gallet wrote: > I've been brought to this bug by apt-listbugs while doing upgrades > on my buster install, warning me of a grave bug. We have two users who have experienced a potentially corrupted database (out of hundreds of thousands or even potentially millions of users, depending how one wants to extrapolate the popcon data). A bug report has been filed and it is kept open in case somebody could provide a way to reproduce the bug or report something actionable. Otherwise neither the Debian packagers nor upstream developers (and upstream does not even know about this bug, since it is still vague and no bug report has been filed upstream) will do anything about the bug report. I am now downgrading this bug report severity to "normal" so that it will not raise false alarms for random users. > I have not attempted the upgrade yet, since, after reading this bug, I > see a risk of data corruption and I would like to avoid going into > recovery procedures (from backups) as a result of what should be a > stable upgrade. You should have a backup anyway, that is just good practice while maintaining database systems. When you want to upgrade, run 'apt upgrade'. If your database is already broken/corrupted, the upgrade will not fix it. You can easily test your database by restarting it (and see that it restarts), read the logs and related documentation. Official Debian package documentation is the README files in the packaging, and they contain more tips about best practices. I recommend you use them as the primary source of information and don't put too much weight on a single bug report.
Bug#996028: [debian-mysql] Bug#996028: #996028 InnoDB: corrupted TRX_NO after upgrading to 10.3.31
> So maybe I do have a corrupted database or something but I'm unsure what to do > next (I don't think I have an older backups of the database). Also it still > works just fine with 10.3.25. Run it with the old database, make a logical dump (with mysqldump) and import that logical dump into a fresh new installation maybe?
Bug#996028: [debian-mysql] Bug#996028: #996028 InnoDB: corrupted TRX_NO after upgrading to 10.3.31
Right. Here is for Buster: https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commit/8ccf2240960cbb609cedfeb269df22d43ccbba21 https://salsa.debian.org/mariadb-team/mariadb-10.3/-/pipelines/302376
Bug#996028: [debian-mysql] Bug#996028: #996028 InnoDB: corrupted TRX_NO after upgrading to 10.3.31
Hello! On Tue, Oct 12, 2021 at 4:51 AM Yves-Alexis Perez wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Mon, 2021-10-11 at 11:27 +0200, Jan Korbel wrote: > > Maybe this: https://bugs.freebsd.org/bugzilla//show_bug.cgi?id=257728 > > If I read the bug correctly, it points to > https://jira.mariadb.org/projects/MDEV/issues/MDEV-26537 and the commit > https://github.com/MariaDB/server/commit/d09426f9e60fd93296464ec9eb5f9d85566437d3 > > I'm not sure I can rebuild the mariadb package myselve but I can surely test a > package if someone builds it. I added this patch to the packaging in https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/2a8f83531a2ff22a31c61b8bef28dabf77b25b78 and once the CI completes (if it runs without errors) you will be able to download the packages from the build artifacts published at https://salsa.debian.org/mariadb-team/mariadb-10.5/-/pipelines/302326 in step "build".
Bug#996028: [debian-mysql] Bug#996028: InnoDB: corrupted TRX_NO after upgrading to 10.3.31
> The problem is in the ibdata1 file (about 450MB). Deleted other database > directories and it still crashes, deleted ibdata1 and it runs. > > How to bisect mariadb from git? Tried: > $ git bisect good mariadb-10.3.29 > $ git bisect bad mariadb-10.3.31 > the build process showed version 10.2 so I aborted it. > > Checked out mariadb-10.3.30 but dpkg-buildpackage failed with: > dh_install: mariadb-plugin-cassandra missing files: > etc/mysql/conf.d/cassandra.cnf Some dependency was missing and Cassandra was not built. Note that the upstream repository is not identical to the one in Debian regarding the contents of debian/ directory. MariaDB builds without a cache take 30 mins each and there are all kinds of things going on. Doing bisect (fully correctly) on MariaDB is hard even for experienced developers. Your time is probably better spent doing some other kind of debugging. I recommend that you file a bug about this upstream, and try to attach relevant info from the error log, maybe a strace output etc. Upstream devs will guide you on what to debug next. One thing you could also try is to start the server with 10.3.29 and ensure that you have a clean shutdown (SET GLOBAL innodb_fast_shutdown=0; SHUTDOWN) and only after that start with the new 10.3.31 binary. Ref - https://mariadb.com/kb/en/shutdown/#see-also - https://www.percona.com/blog/2020/05/07/prepare-mysql-for-a-safe-shutdown/
Bug#996028: [debian-mysql] Bug#996028: InnoDB: corrupted TRX_NO after upgrading to 10.3.31
Hello! Thanks for reporting. Could you please check if this has been reported upstream at jira.mariadb.org? There isn't much we can do about InnoDB internals in Debian packaging.
Bug#990708: marked as pending in mariadb-10.5
Control: tag -1 pending Hello, Bug #990708 in mariadb-10.5 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/8f7e9fbf5873ffa904f15bd3dc1823fd2240e08a Ease switching from galera-3 to galera-4 on upgrades from buster Add Breaks: galera-3 (<< 26.4) to mariadb-server-10.5 Closes: #990708 (this message was generated automatically) -- Greetings https://bugs.debian.org/990708
Bug#990708: [debian-mysql] Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch
On Sat, Jul 10, 2021 at 12:37 AM Andreas Beckmann wrote: > > On 10/07/2021 09.16, Otto Kekäläinen wrote: > > Seems this issue only happens with apt – not when using apt-get. > > Yuck. Can you ask the apt developers whether this is intended? I always > expected apt-get and apt to be functionally equivalent (i.e. to always > take the same decisions when installing/upgrading/removing packages > since they use the same resolver in the background). > (If they are not, testing apt, too, means doubling the number of > piuparts tests...) Filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990922 > Have you tried default-mysql-server + (roundcube-core (or roundcube) or > cacti)? This yields the unwanted behavior (removing default-mysql-server > + mariadb-server-10.3 without installing mariadb-server-10.5)) with > apt-get in my piuparts tests both with and without --install-recommends. > I can find more examples that only work with --install-recommends. Tested Roundcube + default-mysql-server upgrades with both apt and apt-get, and with and without --no-install-recommends in https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/c3f53fe664517bbce7f8ae67244e018f9086534c All passed fine.
Bug#990708: [debian-mysql] Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch
Hello! Seems this issue only happens with apt – not when using apt-get. Olaf's scenario with apt-get upgrades fine: https://salsa.debian.org/mariadb-team/mariadb-10.5/-/jobs/1748579 The exact same with apt-get -> apt fails: https://salsa.debian.org/mariadb-team/mariadb-10.5/-/jobs/1748579 https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/c8ed387f91be4f7a98ccb768935a4725a9f10cd4
Bug#990708: [debian-mysql] Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch
Weird. I renamed the test and extended it bit to have logging and be uniform in general, and now it passes (without your patch): https://salsa.debian.org/mariadb-team/mariadb-10.5/-/jobs/1748275 I was expecting that adding the new step in Salsa-CI would show failure, and then adding your patch would fix it. I'll try to switch from apt-get to apt and see if this problem occurs only with apt, but not apt-get.
Bug#990708: [debian-mysql] Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch
On Wed, Jul 7, 2021 at 6:37 AM Andreas Beckmann wrote: > > On 06/07/2021 01.25, Otto Kekäläinen wrote: > > Thanks Andreas for testing potential changes! > > So far this looks good, I see no more cases of default-mysql-server > being held at the buster version (and thus mariadb-server-10.3 instead > of mariadb-server-10.5 being installed). > > > If you file them as MRs at > > https://salsa.debian.org/mariadb-team/galera-4 and > > https://salsa.debian.org/mariadb-team/mariadb-10.5 you'll get the > > additional CI testing run on top of the for free for extra validation. > > you can find a 990708 branch in both repositories Thanks! I am currently working on the mariadb-10.5 repo branch 990708 to finalize it. I will force push a new version soon. In the meantime you might want to think about the galera-4 branch 990708 because Salsa-CI shows it regressed: https://salsa.debian.org/mariadb-team/galera-4/-/jobs/1744367
Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch
> Thanks for clarifying. That was not obvious since the filename of the > plugin library did not change. And another reason that dropping the > virtual galera package should not do any harm. > (If the plugin would have changed the name (e.g. used a proper > SOVERSION), -3 and -4 should be co-installable and we would not have > this problem now.) Actually, I don't really like calling it "plugin" any > more. (A probably good example of packaged plugins would be proftpd*.) Ideally, yes. Filed https://github.com/codership/galera/issues/599 so we don't forget this. > PS: Otto, what do you think about dropping the epoch from > src:mariadb-10.6 onwards and applying it only to the binary packages > that don't change their names? If you want to do this, get in touch once > you start preparing 10.6 Seems a bit messy to have the epoch in some packages but not all. Also if we want to start doing this, it would need to start with MariaDB 10.7 and be done both upstream and in Debian so that they stay in sync and we don''t end up with users "upgrading" from MariaDB 10.6 from Debian.org repos to MariaDB 10.5 in MariaDB.org repos.
Bug#990708: [debian-mysql] Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch
> BTW, the following apt option might be helpful for debugging upgrade > issues in your CI jobs: > >Debug::pkgProblemResolver "true"; In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988089 we went as far as running apt with: apt dist-upgrade -o Debug::pkgDepCache::AutoInstall=1 -o Debug::pkgDepCache::Marker=1 -o Debug::pkgProblemResolver=1 ..but this easily gets too verbose. Ideally apt had a mode that if it fails, it would output a proper error message with a "trace", but in normal cases stays short and sweet not to clutter the logs too much.
Bug#990708: [debian-mysql] Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch
> > Some general understanding question: Would mariadb-server-10.5 work with > galera-3, too? (with only the Depends being relaxed to 'Depends: > galera-4 | galera-3, ...', without recompilation or similar actions) > (Bonus question: would mariadb-server-10.3/buster work with > galera-4/bullseye with only the dependencies similarily relaxed?) > That could allow for even easier solutions. > Galera 3 works with MariaDB 10.1-10.3. Galera 4 works with MariaDB 10.4-10.6. Galera 4 has new API, thus does not work with MariaDB 10.3. MariaDB needs Galera only if the feature is used. In future might change Depends to Suggests.
Bug#990708: [debian-mysql] Bug#990708: Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch
> I do have this in a VM so I think we can easily repro this. > > // Fresh VM install from debian-10.9.0-i386-netinst.iso > # history > 1 visudo > 2 rm /etc/motd > 3 poweroff > 4 apt install mariadb-server > 5 dpkg -l|grep mariadb > 6 sed -i 's/buster/bullseye/g' /etc/apt/sources.list > 7 apt update > 8 apt upgrade > 9 apt dist-upgrade // output below >10 dpkg -l|grep mariadb // output below >11 apt dist-upgrade // output below I added a CI job that runs about these and indeed it ends up removing mariadb-server, and thus the upgrade does not progress. https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/3c93860e3c065c44e007405915fa762468c82afa https://salsa.debian.org/mariadb-team/mariadb-10.5/-/jobs/1743608 Now this is reproducible, good.
Bug#990708: [debian-mysql] Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch
Thanks Andreas for testing potential changes! If you file them as MRs at https://salsa.debian.org/mariadb-team/galera-4 and https://salsa.debian.org/mariadb-team/mariadb-10.5 you'll get the additional CI testing run on top of the for free for extra validation. There is a mariadb-10.5 Bullseye update pending already, so this is excellent time to put in more changes as long as they are justified (these are). We also plan to make a mariadb-10.3 stable update to Buster, so putting a critical fix is also an option.
Bug#990708: [debian-mysql] Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch
> How would one use galera-3 in bullseye? There is no mariadb-10.3 in > buster, only 10.5 which depends on galera-4 which blocks galera-3 from > being installed. > (Even if galera-3 gets removed from bullseye, it will stay in buster > (and sid if you want)) One would use upstream repositories for MariaDB 10.3 on Bullseye (but get Galera from Debian proper). > What do you need the virtual galera package for? My gut feeling is that > this is the source of our problems because it forms some kind of a > conflicts cycle. Yes, we probably don't need the virtual package for Galera. I guess it has been around since the start and was used because all existing packaging at that time form upstream Codership and Percona had such a package, and the replacement had to offer it as well. I think that by now in 2021 we could probably drop it.
Bug#990708: [debian-mysql] Bug#990708: Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch
On Mon, Jul 5, 2021 at 1:12 PM Olaf van der Spek wrote: > > On Mon, Jul 5, 2021 at 9:24 PM Otto Kekäläinen wrote: > > I wish somebody could contribute with exact steps on how to reproduce > > the issue. So far I've gotten some half attempts at that but they > > haven't been actionable for me. > > Hi Otto, > > I'd point to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988089 > Not sure why it's not reproducible with those steps. I don't see *the* steps, but I see a lot of messages about many different steps. If you have them, why not copy-paste the steps here in email so I can copy-paste them into a Debian Buster Docker container and run the upgrade to isolate the regression?
Bug#990708: [debian-mysql] Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch
Hello! I was able to reproduce this, and addressed it in https://salsa.debian.org/mariadb-team/galera-4/-/commit/27a142792b5e02e66b8f1adf9a7b896c5722dd17 + added Salsa-CI testing for this specific scenario so that it would not regress again, but seems there is still some second scenario that does not upgrade properly. I wish somebody could contribute with exact steps on how to reproduce the issue. So far I've gotten some half attempts at that but they haven't been actionable for me. My plan was to keep Galera-3 in Debian stable / Ubuntu stable as for the duration that MariaDB 10.3 is supported upstream, as MariaDB does not offer Galera by themselves, so it is better to have it available in distro. - Otto
Bug#988089: MariaDB upgrade issues from Debian 10 to Debian 11
> Hello! > > There is an updated Galera-4 in Debian unstable now. If you want to > contribute to the effort, you could now do testing and verify that the > fix delivered works. I filed now http://bugs.debian.org/989513 but would still welcome help. There needs to be more testing that the current unstable version is the final one.
Bug#988089: MariaDB upgrade issues from Debian 10 to Debian 11
Hello! There is an updated Galera-4 in Debian unstable now. If you want to contribute to the effort, you could now do testing and verify that the fix delivered works. On Sun, May 9, 2021 at 8:41 PM Otto Kekäläinen wrote: > > Thanks for running the debug commands. Would you like to also read and > analyze them and try to find out what is going on and thus what the > solution would be? > > And maybe submit a Merge Request on what should be changed in the > debian/control file maybe? > > In this message I describe how I tested a new debian/control file > without having to rebuild the whole package: > https://lists.debian.org/debian-devel/2021/03/msg00206.html > > > On Sun, May 9, 2021 at 1:30 AM Olaf van der Spek wrote: > > > > Op zo 9 mei 2021 om 08:40 schreef Otto Kekäläinen : > > > Here is a debian-devel thread where I learnt new ways to run apt in > > > debug mode to better see why it chooses to upgrade/remove certain > > > packages, it might be helpful here too: > > > https://lists.debian.org/debian-devel/2021/03/msg00139.html > > > https://lists.debian.org/debian-devel/2021/03/msg00131.html > > > > # apt upgrade -o Debug::pkgDepCache::AutoInstall=1 -o > > Debug::pkgDepCache::Marker=1 -o Debug::pkgProblemResolver=1 > > Reading package lists... Done > > Building dependency tree... Done > > Reading state information... Done > > MarkInstall mariadb-server:amd64 < 1:10.3.27-0+deb10u1 -> 1:10.5.9-1 > > @ii umU Ib > FU=0 ...
Bug#988629: marked as pending in mariadb-10.5
Control: tag -1 pending Hello, Bug #988629 in mariadb-10.5 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/011ffd142e7c7c40b827491d7db1a62ea3085a11 Bugfix: Revert upstream code change to fix armhf build (Closes: #988629) (this message was generated automatically) -- Greetings https://bugs.debian.org/988629
Bug#988089: [debian-mysql] Bug#988089: Bug#988089: mariadb-server: MariaDB uninstalled on dist-upgrade Debian 10 -> 11
Hello! On Sun, May 16, 2021 at 4:18 PM Otto Kekäläinen wrote: > > >> > But as said, the bug #988089 can only be fixed by a change in galera-4 >> > debian/control. Changing the mariadb-10.5 debian/control to >> > recommends:galera-4 is a separate change. >> Ok but I have no idea how this should be handled then. > > > I outlined the exact galera-4 debugging steps in my email on May 13th. The > solution can be found and also tested/validated easily with those steps. I had some spare time today and followed those steps, resulting in this MR: https://salsa.debian.org/mariadb-team/galera-4/-/merge_requests/5 Would somebody like to review/test it?
Bug#988089: marked as pending in galera-4
Control: tag -1 pending Hello, Bug #988089 in galera-4 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/mariadb-team/galera-4/-/commit/9f425977a2c29f8d8571f04a35221fe6dacab257 Bugfix: Don't uninstall MariaDB on Galera 3 to 4 upgrade (Closes: #988089) - Ensure 'apt dist-upgrade' from Galera 3 to 4 keeps MariaDB Server installed and upgraded. In the case of Buster to Bullseye it should uninstall MariaDB 10.3 and install MariaDB 10.5. - Extend Salsa-CI to test this to ensure it will not regress in future. Proof: ``` # Debian release: Buster # Apt: all sources disabled # Testing with manually downloaded http://ftp.debian.org/debian/dists/sid/main/binary-amd64/Packages.xz # apt-get -o Debug::pkgProblemResolver=1 --with-source ./Packages dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Starting pkgProblemResolver with broken count: 10 Starting 2 pkgProblemResolver with broken count: 10 Investigating (0) mariadb-client-core-10.5:amd64 < none -> 1:10.5.9-1 @un uN Ib > Broken mariadb-client-core-10.5:amd64 Conflicts on virtual-mysql-client-core:amd64 < none @un H > Conflicts//Breaks against version 8.0.23-3+b1 for mysql-client-core-8.0 but that is not InstVer, ignoring Considering mariadb-client-core-10.3:amd64 -3 as a solution to mariadb-client-core-10.5:amd64 0 Added mariadb-client-core-10.3:amd64 to the remove list Broken mariadb-client-core-10.5:amd64 Breaks on mariadb-client-core-10.3:amd64 < 1:10.3.27-0+deb10u1 @ii mK Ib > Considering mariadb-client-core-10.3:amd64 -3 as a solution to mariadb-client-core-10.5:amd64 0 Added mariadb-client-core-10.3:amd64 to the remove list Fixing mariadb-client-core-10.5:amd64 via remove of mariadb-client-core-10.3:amd64 Fixing mariadb-client-core-10.5:amd64 via remove of mariadb-client-core-10.3:amd64 Investigating (0) mariadb-client-10.5:amd64 < none -> 1:10.5.9-1 @un uN Ib > Broken mariadb-client-10.5:amd64 Conflicts on virtual-mysql-client:amd64 < none @un H > Conflicts//Breaks against version 8.0.23-3+b1 for mysql-client-8.0 but that is not InstVer, ignoring Considering mariadb-client-10.3:amd64 -2 as a solution to mariadb-client-10.5:amd64 0 Added mariadb-client-10.3:amd64 to the remove list Broken mariadb-client-10.5:amd64 Breaks on mariadb-client-10.3:amd64 < 1:10.3.27-0+deb10u1 @ii mK Ib > Considering mariadb-client-10.3:amd64 -2 as a solution to mariadb-client-10.5:amd64 0 Added mariadb-client-10.3:amd64 to the remove list Fixing mariadb-client-10.5:amd64 via remove of mariadb-client-10.3:amd64 Fixing mariadb-client-10.5:amd64 via remove of mariadb-client-10.3:amd64 Investigating (0) galera-4:amd64 < none -> 26.4.7-3 @un uN Ib > Broken galera-4:amd64 Conflicts on galera:amd64 < none @un H > Considering galera-3:amd64 0 as a solution to galera-4:amd64 0 Holding Back galera-4:amd64 rather than change galera:amd64 Investigating (0) mariadb-server-10.5:amd64 < none -> 1:10.5.9-1 @un uN Ib > Broken mariadb-server-10.5:amd64 Depends on galera-4:amd64 < none | 26.4.7-3 @un uH > (>= 26.4) Considering galera-4:amd64 0 as a solution to mariadb-server-10.5:amd64 0 Holding Back mariadb-server-10.5:amd64 rather than change galera-4:amd64 Investigating (0) mariadb-server-core-10.5:amd64 < none -> 1:10.5.9-1 @un uN Ib > Broken mariadb-server-core-10.5:amd64 Conflicts on virtual-mysql-server-core:amd64 < none @un H > Conflicts//Breaks against version 8.0.23-3+b1 for mysql-server-core-8.0 but that is not InstVer, ignoring Considering mariadb-server-core-10.3:amd64 -2 as a solution to mariadb-server-core-10.5:amd64 0 Added mariadb-server-core-10.3:amd64 to the remove list Broken mariadb-server-core-10.5:amd64 Breaks on mariadb-server-10.3:amd64 < 1:10.3.27-0+deb10u1 @ii mK Ib > Considering mariadb-server-10.3:amd64 -4 as a solution to mariadb-server-core-10.5:amd64 0 Added mariadb-server-10.3:amd64 to the remove list Broken mariadb-server-core-10.5:amd64 Breaks on mariadb-server-core-10.3:amd64 < 1:10.3.27-0+deb10u1 @ii mK Ib > Considering mariadb-server-core-10.3:amd64 -2 as a solution to mariadb-server-core-10.5:amd64 0 Added mariadb-server-core-10.3:amd64 to the remove list Fixing mariadb-server-core-10.5:amd64 via remove of mariadb-server-core-10.3:amd64 Fixing mariadb-server-core-10.5:amd64 via remove of mariadb-server-10.3:amd64 Fixing mariadb-server-core-10.5:amd64 via remove of mariadb-server-core-10.3:amd64 Investigating (1) mariadb-server:amd64 < 1:10.3.27-0+deb10u1 -> 1:10.5.9-1 @ii umU Ib > Broken mariadb-server:amd64 Depends on mariadb-server-10.5:amd64 < none | 1:10.5.9-1 @un uH > (>= 1:10.5.9-1) Considering mariadb-server-10.5:amd64 0 as a solution to mariadb-server:amd64 0 Removing mariadb-server:amd64 rather than
Bug#988089: marked as pending in galera-4
Control: tag -1 pending Hello, Bug #988089 in galera-4 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/mariadb-team/galera-4/-/commit/2fc32e6a1aee2c0dc624e93c6551f14c1e5bd43a Bugfix: Don't uninstall MariaDB on Galera 3 to 4 upgrade (Closes: #988089) - Ensure 'apt dist-upgrade' from Galera 3 to 4 keeps MariaDB Server installed and upgraded. In the case of Buster to Bullseye it should uninstall MariaDB 10.3 and install MariaDB 10.5. - Extend Salsa-CI to test this to ensure it will not regress in future. Proof: ``` # Debian release: Buster # Apt: all sources disabled # Testing with manually downloaded http://ftp.debian.org/debian/dists/sid/main/binary-amd64/Packages.xz # apt-get -o Debug::pkgProblemResolver=1 --with-source ./Packages dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Starting pkgProblemResolver with broken count: 10 Starting 2 pkgProblemResolver with broken count: 10 Investigating (0) mariadb-client-core-10.5:amd64 < none -> 1:10.5.9-1 @un uN Ib > Broken mariadb-client-core-10.5:amd64 Conflicts on virtual-mysql-client-core:amd64 < none @un H > Conflicts//Breaks against version 8.0.23-3+b1 for mysql-client-core-8.0 but that is not InstVer, ignoring Considering mariadb-client-core-10.3:amd64 -3 as a solution to mariadb-client-core-10.5:amd64 0 Added mariadb-client-core-10.3:amd64 to the remove list Broken mariadb-client-core-10.5:amd64 Breaks on mariadb-client-core-10.3:amd64 < 1:10.3.27-0+deb10u1 @ii mK Ib > Considering mariadb-client-core-10.3:amd64 -3 as a solution to mariadb-client-core-10.5:amd64 0 Added mariadb-client-core-10.3:amd64 to the remove list Fixing mariadb-client-core-10.5:amd64 via remove of mariadb-client-core-10.3:amd64 Fixing mariadb-client-core-10.5:amd64 via remove of mariadb-client-core-10.3:amd64 Investigating (0) mariadb-client-10.5:amd64 < none -> 1:10.5.9-1 @un uN Ib > Broken mariadb-client-10.5:amd64 Conflicts on virtual-mysql-client:amd64 < none @un H > Conflicts//Breaks against version 8.0.23-3+b1 for mysql-client-8.0 but that is not InstVer, ignoring Considering mariadb-client-10.3:amd64 -2 as a solution to mariadb-client-10.5:amd64 0 Added mariadb-client-10.3:amd64 to the remove list Broken mariadb-client-10.5:amd64 Breaks on mariadb-client-10.3:amd64 < 1:10.3.27-0+deb10u1 @ii mK Ib > Considering mariadb-client-10.3:amd64 -2 as a solution to mariadb-client-10.5:amd64 0 Added mariadb-client-10.3:amd64 to the remove list Fixing mariadb-client-10.5:amd64 via remove of mariadb-client-10.3:amd64 Fixing mariadb-client-10.5:amd64 via remove of mariadb-client-10.3:amd64 Investigating (0) galera-4:amd64 < none -> 26.4.7-3 @un uN Ib > Broken galera-4:amd64 Conflicts on galera:amd64 < none @un H > Considering galera-3:amd64 0 as a solution to galera-4:amd64 0 Holding Back galera-4:amd64 rather than change galera:amd64 Investigating (0) mariadb-server-10.5:amd64 < none -> 1:10.5.9-1 @un uN Ib > Broken mariadb-server-10.5:amd64 Depends on galera-4:amd64 < none | 26.4.7-3 @un uH > (>= 26.4) Considering galera-4:amd64 0 as a solution to mariadb-server-10.5:amd64 0 Holding Back mariadb-server-10.5:amd64 rather than change galera-4:amd64 Investigating (0) mariadb-server-core-10.5:amd64 < none -> 1:10.5.9-1 @un uN Ib > Broken mariadb-server-core-10.5:amd64 Conflicts on virtual-mysql-server-core:amd64 < none @un H > Conflicts//Breaks against version 8.0.23-3+b1 for mysql-server-core-8.0 but that is not InstVer, ignoring Considering mariadb-server-core-10.3:amd64 -2 as a solution to mariadb-server-core-10.5:amd64 0 Added mariadb-server-core-10.3:amd64 to the remove list Broken mariadb-server-core-10.5:amd64 Breaks on mariadb-server-10.3:amd64 < 1:10.3.27-0+deb10u1 @ii mK Ib > Considering mariadb-server-10.3:amd64 -4 as a solution to mariadb-server-core-10.5:amd64 0 Added mariadb-server-10.3:amd64 to the remove list Broken mariadb-server-core-10.5:amd64 Breaks on mariadb-server-core-10.3:amd64 < 1:10.3.27-0+deb10u1 @ii mK Ib > Considering mariadb-server-core-10.3:amd64 -2 as a solution to mariadb-server-core-10.5:amd64 0 Added mariadb-server-core-10.3:amd64 to the remove list Fixing mariadb-server-core-10.5:amd64 via remove of mariadb-server-core-10.3:amd64 Fixing mariadb-server-core-10.5:amd64 via remove of mariadb-server-10.3:amd64 Fixing mariadb-server-core-10.5:amd64 via remove of mariadb-server-core-10.3:amd64 Investigating (1) mariadb-server:amd64 < 1:10.3.27-0+deb10u1 -> 1:10.5.9-1 @ii umU Ib > Broken mariadb-server:amd64 Depends on mariadb-server-10.5:amd64 < none | 1:10.5.9-1 @un uH > (>= 1:10.5.9-1) Considering mariadb-server-10.5:amd64 0 as a solution to mariadb-server:amd64 0 Removing mariadb-server:amd64 rather than
Bug#988089: marked as pending in galera-4
Control: tag -1 pending Hello, Bug #988089 in galera-4 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/mariadb-team/galera-4/-/commit/05fad203bd9fdb2239a55f4d1ddd83334251e839 Bugfix: Don't uninstall MariaDB on Galera 3 to 4 upgrade (Closes: #988089) - Ensure 'apt dist-upgrade' from Galera 3 to 4 keeps MariaDB Server installed and upgraded. In the case of Buster to Bullseye it should uninstall MariaDB 10.3 and install MariaDB 10.5. - Extend Salsa-CI to test this to ensure it will not regress in future. Proof: ``` # Debian release: Buster # Apt: all sources disabled # Testing with manually downloaded http://ftp.debian.org/debian/dists/sid/main/binary-amd64/Packages.xz # apt-get -o Debug::pkgProblemResolver=1 --with-source ./Packages dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Starting pkgProblemResolver with broken count: 10 Starting 2 pkgProblemResolver with broken count: 10 Investigating (0) mariadb-client-core-10.5:amd64 < none -> 1:10.5.9-1 @un uN Ib > Broken mariadb-client-core-10.5:amd64 Conflicts on virtual-mysql-client-core:amd64 < none @un H > Conflicts//Breaks against version 8.0.23-3+b1 for mysql-client-core-8.0 but that is not InstVer, ignoring Considering mariadb-client-core-10.3:amd64 -3 as a solution to mariadb-client-core-10.5:amd64 0 Added mariadb-client-core-10.3:amd64 to the remove list Broken mariadb-client-core-10.5:amd64 Breaks on mariadb-client-core-10.3:amd64 < 1:10.3.27-0+deb10u1 @ii mK Ib > Considering mariadb-client-core-10.3:amd64 -3 as a solution to mariadb-client-core-10.5:amd64 0 Added mariadb-client-core-10.3:amd64 to the remove list Fixing mariadb-client-core-10.5:amd64 via remove of mariadb-client-core-10.3:amd64 Fixing mariadb-client-core-10.5:amd64 via remove of mariadb-client-core-10.3:amd64 Investigating (0) mariadb-client-10.5:amd64 < none -> 1:10.5.9-1 @un uN Ib > Broken mariadb-client-10.5:amd64 Conflicts on virtual-mysql-client:amd64 < none @un H > Conflicts//Breaks against version 8.0.23-3+b1 for mysql-client-8.0 but that is not InstVer, ignoring Considering mariadb-client-10.3:amd64 -2 as a solution to mariadb-client-10.5:amd64 0 Added mariadb-client-10.3:amd64 to the remove list Broken mariadb-client-10.5:amd64 Breaks on mariadb-client-10.3:amd64 < 1:10.3.27-0+deb10u1 @ii mK Ib > Considering mariadb-client-10.3:amd64 -2 as a solution to mariadb-client-10.5:amd64 0 Added mariadb-client-10.3:amd64 to the remove list Fixing mariadb-client-10.5:amd64 via remove of mariadb-client-10.3:amd64 Fixing mariadb-client-10.5:amd64 via remove of mariadb-client-10.3:amd64 Investigating (0) galera-4:amd64 < none -> 26.4.7-3 @un uN Ib > Broken galera-4:amd64 Conflicts on galera:amd64 < none @un H > Considering galera-3:amd64 0 as a solution to galera-4:amd64 0 Holding Back galera-4:amd64 rather than change galera:amd64 Investigating (0) mariadb-server-10.5:amd64 < none -> 1:10.5.9-1 @un uN Ib > Broken mariadb-server-10.5:amd64 Depends on galera-4:amd64 < none | 26.4.7-3 @un uH > (>= 26.4) Considering galera-4:amd64 0 as a solution to mariadb-server-10.5:amd64 0 Holding Back mariadb-server-10.5:amd64 rather than change galera-4:amd64 Investigating (0) mariadb-server-core-10.5:amd64 < none -> 1:10.5.9-1 @un uN Ib > Broken mariadb-server-core-10.5:amd64 Conflicts on virtual-mysql-server-core:amd64 < none @un H > Conflicts//Breaks against version 8.0.23-3+b1 for mysql-server-core-8.0 but that is not InstVer, ignoring Considering mariadb-server-core-10.3:amd64 -2 as a solution to mariadb-server-core-10.5:amd64 0 Added mariadb-server-core-10.3:amd64 to the remove list Broken mariadb-server-core-10.5:amd64 Breaks on mariadb-server-10.3:amd64 < 1:10.3.27-0+deb10u1 @ii mK Ib > Considering mariadb-server-10.3:amd64 -4 as a solution to mariadb-server-core-10.5:amd64 0 Added mariadb-server-10.3:amd64 to the remove list Broken mariadb-server-core-10.5:amd64 Breaks on mariadb-server-core-10.3:amd64 < 1:10.3.27-0+deb10u1 @ii mK Ib > Considering mariadb-server-core-10.3:amd64 -2 as a solution to mariadb-server-core-10.5:amd64 0 Added mariadb-server-core-10.3:amd64 to the remove list Fixing mariadb-server-core-10.5:amd64 via remove of mariadb-server-core-10.3:amd64 Fixing mariadb-server-core-10.5:amd64 via remove of mariadb-server-10.3:amd64 Fixing mariadb-server-core-10.5:amd64 via remove of mariadb-server-core-10.3:amd64 Investigating (1) mariadb-server:amd64 < 1:10.3.27-0+deb10u1 -> 1:10.5.9-1 @ii umU Ib > Broken mariadb-server:amd64 Depends on mariadb-server-10.5:amd64 < none | 1:10.5.9-1 @un uH > (>= 1:10.5.9-1) Considering mariadb-server-10.5:amd64 0 as a solution to mariadb-server:amd64 0 Removing mariadb-server:amd64 rather than
