I was able to work around this (in a test VM, after upgrading it from 20.04 to 24.04) with adapted instructions from a blogpost [1], by temporarily installing postgresql-14 from the PGDG repository for doing the 14 -> 16 upgrade:

# apt install postgresql-common
# /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh
# apt install postgresql-14
# pg_dropcluster 16 main –stop
# pg_upgradecluster 14 main
# pg_dropcluster 14 main
# apt purge postgresql-14 postgresql-client-14
# rm /etc/apt/sources.list.d/pgdg.sources
# apt update

I have yet to try this on my actual server with actual data. Please be careful if you attempt this with a production database.

*[1] https://www.directedignorance.com/blog/upgrading-postgresql-14-to-16-on-ubuntu

== Summary ==
On my computer with an ancient Nvidia chipset (Geforce 7025/nForce 630a), running `sysctl suspend` (or suspending from the Gnome menu) causes the system to start suspending, but it freezes halfway, leaving fans and hard drives spinning. There’s no way to resume from this frozen state apart from forcing a reboot (with a hardware reset button/poweroff).

== Steps to reproduce ==
* boot with modeset enabled
* run `sysctl suspend`

== What I expect to happen ==
For the system to suspend, shutting down all fans and hard drives.

== What happens ==
The system begins to suspend, but freezes halfway, leaving the display on and fans and hard drives spinning, but the keyboard unresponsive.

== Workaround ==
Disable kernel modesetting by adding ”nomodeset” to the kernel commandline.

== Affected kernels ==
Prior to upgrades the system was running HWE kernel 5.15.0, so I tried the 5.15 series, and found that I could now suspend and wake the machine again just as before. I worked my way up the versions:

* 5.15.50: unaffected
* 5.15.165: unaffected
* 5.19.17: unaffected
* 6.4.0: unaffected
* 6.6.0: unaffected
* 6.6.48: unaffected
* 6.7.0: first to fail

I also tried the current newest mainline kernel 6.10.7, and the issue is still present there.

== Background ==
I have an old desktop machine now functioning as a NAS, and yesterday I upgraded it from Ubuntu 20.04 first to 22.04, and then all the way up to 24.04. The upgrade went smoothly, and this is the only issue I’ve come across since.

In the BIOS settings of the affected machine there are three ”suspend mode” alternatives to choose from: ”S1 (POS) only”, ”S3 only” and ”Auto”. I’ve always had it on ”Auto”, but with this issue I also tested both ”S1 only” and ”S3 only”, with no effect.

The issue is also present when booting from the installation media (USB) into a live environment.

I’ve previously upgraded my laptop to 24.04, and there suspending still works as it did before the ugprade, so this is probably hardware-specific; the laptop is a modern one with all-Intel hardware.

Googling around, I could smelled hints of this being once again related to the troublesome Nvidia chipset, so I tried nomodeset with the stock 6.8.0 kernel (6.8.0-41 currently) and voilà! Suspend and wake were working again.

Well, except for the display, which stayed black. But I couldn’t say if this was the way it was before, because the NAS is normally running headless.

I’m just making this note here publicly, since I was first going to pose this as a question, but then managed to solve it by myself:

For background, I recently switched my Mattermost from a tar archive installation to installing it from the package repository, and simultaneously switched it from using a MySQL database to using PostgreSQL, all in one fell swoop by exporting the old content, doing a fresh install, and then importing. This appears to have mostly worked, with just user profile images having been lost, and passwords requiring a reset, both of which (I’ve gleaned from various places) were to be expected.

However, all bot accounts also seem to have been converted into normal user accounts somewhere during this process. So far the only issue I’ve discovered resulting from this is this entry getting logged repeatedly:

Failed to get system bot    caller="app/post.go:2205" component=post_reminders error="SqlBotStore.Get: Bot does not exist., resource "Bot" not found, id: <my system bot's id>"

I solved this by running

sudo -u mattermost mmctl user convert --bot "<bot id>" # replace <bot id> with your real system bot account id

Since that seems to have gone well (the error messages stopped), I went ahead and converted the rest of the bot accounts back to true bots likewise.

For anyone else stumbling across this thread when googling for this annoying problem: the issue here is that using special characters in your password on the DataSource line is broken: Can’t use special character in password in the DataSource property · Issue #1541 · mattermost/mattermost · GitHub

As stupid as that is, the easiest way to work around it is to set a password consisting of just alphanumeric characters. You shouldn’t have much use for it outside this anyway, so as not to make it ridiculously insecure.

I’m on amd64 too, and yep, it’s working just fine after switching to 2024.7/candidate. Excellent, thank you!

Yeah, still not working for me either. Restarting HA snap just results in the same traceback getting logged as before.

Settings > Devices & services > HACS shows it’s up to date (or at least at that same version, 1.34.0). I can’t find a ”Configuration” or ”HACS update” view under the HACS service, only the one with related Service info, Automations and so on (possibly because HACS is ”Not loaded”, which is the issue).

I don’t know if the host system has any bearing on this, but mine is running Ubuntu 20.04, and I’ll happily provide any other info if needed.

Here’s the full traceback I have, unfiltered. It refers to pydantic, and it looks like something people have worked around by forcing pydantic to version 1.10.16. I barely speak any Python at all though, so I wouldn’t know what other implications this has, if any, but I hope it’s at least a clue.

ha.log

Puu kaatunut kuntoradalle.

Suosikkijuustoni on Valion 15-prosenttinen Polar (Valsa). Viime kuukaudet se on jostain syystä aina ollut kahtia haljenneena pakkauksesta otettuna. En tiedä onko vika logistiikassa vai tuotantopäässä, mutta teiltä onnistunee tuon syyn selvittäminen. Ostan juustoni useimmiten samasta myymälästä (Oulun Linnanmaan Prisma), eli myöskään käsittelyvirhe siellä ei ole poissuljettu.

Eihän tuo makuun tai syömäkelpoisuuteen vaikuta millään lailla, mutta tuo halkeilu tekee juustosta huonosti höylättävän, varsinkin kun ruukaan höylätä tiiliskiven päästä. Haljenneesta köntistä veistetyt siivut katkeilevat halkeamakohdista pikku pätkiksi.

Nämä sateenkaarimaiset juovat (kuvassa oikealla, puiden edustalla) löysin vasta jälkikäteen tästä kuvasta, eli paikan päällä en näitä huomannut; ehkä polarisoivien aurinkolasien takia, jollei sitten kyse ole vain kameran tuottamasta artefaktista. Ajattelin kuitenkin tarjota tunnistettavaksi, kun en keksinyt että mistä ilmiöstä on kyse. Lähinnä tuli mieleen jääsumuhalo, mutta vaikka täällä viime yönä pakkasta olikin, niin kuvaa ottaessani ilman lämpötila oli jo +2…3 °.