The database was created using collation version 2.35, but the operating system provides version 2.36

Hello all,
I need your help to resolve this issue.

Nov 22 08:24:44 gvmd[187111]: WARNING: database “gvmd” has a collation version mismatch
Nov 22 08:24:44 gvmd[187111]: DETAIL: The database was created using collation version 2.35, but the operating system provides version 2.36.
Nov 22 08:24:44 gvmd[187111]: HINT: Rebuild all objects in this database that use the default collation and run ALTER DATABASE gvmd REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.

Does anyone have a procedure to resolve this issue?
I will be attentive to your answers

1 Like

I also encountered the same problem when starting msf.I hope that some friends who have already solved this problem can help us solve it. Thank you very much

Hi @Gr1m and welcome to the forum.

By msf do you mean Metasploit? If so that’s different than Greenbone so we won’t be able to help with that specifically, but this and the above might similar issue, so my next questions to you and @cgqc are which Linux distribution are you using (name and version)?

1 Like

This below solution worked for me :

Connect to postgres

sudo -u postgres psql

List all databases to ensure your database exists


Alter gvmd & postgres database to refresh Collation version


Exit postgres

\q or exit

Restart GSM services

systemctl daemon-reload && systemctl restart gvmd.service gsad.service

Check if warnings are fixed


If you have no warnings your problem should be fixed
Hope this helps


Some more (background) info about this / the reasons for this message from PostgreSQL / operating system (Debian) side is available here:

The cause for that (IIUC) is that the database was created when libc6 was at version 2.35 and it has since been upgraded to 2.36.

See also


A (major) libc6 upgrade is not something that will happen on Stable, so this issue may only occur with people running Testing or Unstable.


But it will happen when people upgrade their stable machines to bookworm once it is released.

AFAIK, that upgrade procedure is different and those users will not run into this issue.

Disclaimer for the future (e.g. arriving via a search engine here):

While it seems to be currently “safe” do just raise / update the collation on further glibc upgrades additional checks / research and evaluation of the database might be required:


2 posts were split to a new topic: Can not access ospd-openvas.service after resolving gvmd database collation mismatch