Summary
When trying to Upgrade from Version 10.12 to 11.0.2 on Ubuntu 24.04 LTS using the mattermost ppa (and psql 16) in a self hosted environment the Upgrade Fails.
Steps to reproduce
sudo apt update
sudo apt full upgrade
Expected behavior
Finished Update without any errors
Observed behavior
Mattermost (11.0.2-0) is being set up…
dpkg: Error while processing the package mattermost (–configure):
Installing post-installation script of package mattermost - Subprocess returned error code 1
Error occurred while processing:
mattermost
E: Sub-process /usr/bin/dpkg returned an error code (1)
In config.json, delete the line about ExperimentalHideArchivedChannels and check your password from etc/mattermost/mmomni.yml and ensure the Datasource is using mmuser:{yourpasswrod from mmomni.yml}. You might need to set the password on the DB.
Then do an in place upgrade of PostgreSQL 13 to PostgreSQL 14 as that is the DB version it is looking for. Once that is done you can start mattermost but you have to reconfigure somethings like the URL, files, etc
I would not recommend anyone doing the omnibus upgrade until this is fixed as it will take down your system for a while
Mattermost on-prem, SUSE Linux Enterprise Server 15SP7, Postgres 17.6. Mattermost won’t start after upgrade from Mattermost Version: 10.12.0 to 11.0.2. Never any issues upgrading before - and no problem to upgrade to Mattermost Version: 10.12.1
Can’t find any ExperimentalView.. or ExperimentalHide… in config.json
Any idea on how to fix this? My server attempted the upgrade today and now it won’t start because o the error code 1 (went from 10.12.0 to 11.0.2). My config file has just the “ExperimentalViewArchivedChannels”: true, so does it need to deleted or otherwise changed? Running on Ubuntu 24.04.3 LTS with Postgres 18.
I ended up restoring from backup. I tried to do their migration, the do tool did’not install correctly or something, worked though that, then it installed the migration tool but did not put in the path, so had to find where the executable was and add that, then had to figure out the DSNs on both as we do use special char in the passwords. So had to figure that out, got the output file, then had to install the pgimport (whatever) tool ran that then had errors on that and found several issues in there, and then at that point ran into it would not run, so ended up restoring from backup as of now.
It appears to be an issue connecting to the DB. I am seeing the following error in the mattermost.log around the time of the upgrade:
{“timestamp”:“2025-10-22 17:55:03.884 Z”,“level”:“info”,“msg”:“Server is initializing…”,“caller”:“platform/service.go:178”,“go_vers
ion”:“go1.24.6”}
{“timestamp”:“2025-10-22 17:55:03.884 Z”,“level”:“info”,“msg”:“Current version is 11.0.2 (18457083734/Mon Oct 13 06:31:26 UTC 2025/79
77e7e6dae3e13ded929a1bef2897d455456e5e/f42f8a18a93dc63807a5e8949e306020ec70c3b6)”,“caller”:“platform/service.go:181”,"current_version
":“11.0.2”,“build_number”:“18457083734”,“build_date”:“Mon Oct 13 06:31:26 UTC 2025”,“build_hash”:“7977e7e6dae3e13ded929a1bef2897d4554
56e5e”,“build_hash_enterprise”:“f42f8a18a93dc63807a5e8949e306020ec70c3b6”,“service_environment”:“production”}
{“timestamp”:“2025-10-22 17:55:03.884 Z”,“level”:“info”,“msg”:“Enterprise Build”,“caller”:“platform/service.go:196”,"enterprise_build
":true,“is_trial”:false}
{“timestamp”:“2025-10-22 17:55:03.884 Z”,“level”:“info”,“msg”:“Successfully connected to cache backend”,“caller”:“platform/service.go
:229”,“backend”:“lru”,“result”:“OK”}
{“timestamp”:“2025-10-22 17:55:03.892 Z”,“level”:“error”,“msg”:“Failed to ping DB”,“caller”:“sql/sql_utils.go:51”,“database”:“master”
,“dataSource”:“postgres://:@localhost/mattermost_test?binary_parameters=yes&connect_timeout=10&sslmode=disable”,“retrying in
seconds”:2,“error”:“pq: password authentication failed for user “mmuser””}
Doing a database listing in postgres shows no such database. mmuser has full access privilege to mattermost database.
We figured out the issue on our server. Check what version of postgres is tied to port 5432. If it is not 14.0, it will fail on the install. We found we had multiple postgres versions running on the same server from 13.22 to 18.x, and the postgres cluster was running on the oldest version. This was an issue on Ubuntu 22.04 and greater. Follow these instructions to upgrade your cluster (https://www.paulox.net/2022/04/28/upgrading-postgresql-from-version-13-to-14-on-ubuntu-22-04-jammy-jellyfish/) to get to the latest version after dropping all the newer clusters. Comes up like a champ.
