Version error on moving sonarqube to a new server

SonarQube Server / Community Build
1

Version sonarqube-10.1.0.73491 has been deployed on a RH7 server for some time. It was using postgres 13.

  1. It became unstable and stopped running after a recent yum update
  2. We were required to update to RH8 in the near future, so I created a server and moved the old database to that machine.
  3. I also moved the install folder for sonarqube to the new machine.
  4. Basically this is the same configuration as on the previous machine. I had to install the latest postgres 13 rpm but did not have issues with that.
  5. When I started up sonarqube I get a message that is sourced from org.sonar.server.platform.DatabaseServerCompatibility. Its complaining about The version of SonarQube is too old. Please upgrade to the Long Term Support version first.
  6. Now there are no LTS versions between 10.1 and 10.4 that I can see. I had already been force to do the upgrade to 9.9 LTS last year.
  7. What does this message mean and how can I fix it? I need to get this back in operation.

Log outpput

StepRegistryImpl'
    2024.03.15 13:25:14 DEBUG web[][o.s.c.p.PriorityBeanFactory] Autowiring by type from bean name 'MigrationSteps' via factory method to bean named 'jdk.internal.loader.ClassLoaders$AppClassLoader@5ffd2b27-org.sonar.server.platform.db.migration.version.v00.DbVersion00'
    2024.03.15 13:25:14 DEBUG web[][o.s.c.p.PriorityBeanFactory] Autowiring by type from bean name 'MigrationSteps' via factory method to bean named 'jdk.internal.loader.ClassLoaders$AppClassLoader@5ffd2b27-org.sonar.server.platform.db.migration.version.v100.DbVersion100'
    2024.03.15 13:25:14 DEBUG web[][o.s.c.p.PriorityBeanFactory] Autowiring by type from bean name 'MigrationSteps' via factory method to bean named 'jdk.internal.loader.ClassLoaders$AppClassLoader@5ffd2b27-org.sonar.server.platform.db.migration.version.v101.DbVersion101'
    2024.03.15 13:25:14 DEBUG web[][o.s.c.p.PriorityBeanFactory] Autowiring by type from bean name 'jdk.internal.loader.ClassLoaders$AppClassLoader@5ffd2b27-org.sonar.server.platform.db.migration.history.MigrationHistoryMeddler' via constructor to bean named 'MigrationSteps'
    2024.03.15 13:25:14 DEBUG web[][o.s.c.p.PriorityBeanFactory] Autowiring by type from bean name 'jdk.internal.loader.ClassLoaders$AppClassLoader@5ffd2b27-org.sonar.server.platform.db.migration.history.MigrationHistoryImpl' via constructor to bean named 'jdk.internal.loader.ClassLoaders$AppClassLoader@5ffd2b27-org.sonar.db.DefaultDatabase'
    2024.03.15 13:25:14 DEBUG web[][o.s.c.p.PriorityBeanFactory] Autowiring by type from bean name 'jdk.internal.loader.ClassLoaders$AppClassLoader@5ffd2b27-org.sonar.server.platform.db.migration.history.MigrationHistoryImpl' via constructor to bean named 'jdk.internal.loader.ClassLoaders$AppClassLoader@5ffd2b27-org.sonar.server.platform.db.migration.history.MigrationHistoryMeddler'
    2024.03.15 13:25:14 DEBUG web[][o.s.c.p.PriorityBeanFactory] Creating shared instance of singleton bean 'jdk.internal.loader.ClassLoaders$AppClassLoader@5ffd2b27-org.sonar.server.platform.DatabaseServerCompatibility'
    2024.03.15 13:25:14 DEBUG web[][o.s.c.p.PriorityBeanFactory] Creating shared instance of singleton bean 'jdk.internal.loader.ClassLoaders$AppClassLoader@5ffd2b27-org.sonar.server.platform.db.migration.version.DatabaseVersion'
    2024.03.15 13:25:14 DEBUG web[][o.s.c.p.PriorityBeanFactory] Autowiring by type from bean name 'jdk.internal.loader.ClassLoaders$AppClassLoader@5ffd2b27-org.sonar.server.platform.db.migration.version.DatabaseVersion' via constructor to bean named 'MigrationSteps'
    2024.03.15 13:25:14 DEBUG web[][o.s.c.p.PriorityBeanFactory] Autowiring by type from bean name 'jdk.internal.loader.ClassLoaders$AppClassLoader@5ffd2b27-org.sonar.server.platform.db.migration.version.DatabaseVersion' via constructor to bean named 'jdk.internal.loader.ClassLoaders$AppClassLoader@5ffd2b27-org.sonar.server.platform.db.migration.history.MigrationHistoryImpl'
    2024.03.15 13:25:14 DEBUG web[][o.s.c.p.PriorityBeanFactory] Autowiring by type from bean name 'jdk.internal.loader.ClassLoaders$AppClassLoader@5ffd2b27-org.sonar.server.platform.DatabaseServerCompatibility' via constructor to bean named 'jdk.internal.loader.ClassLoaders$AppClassLoader@5ffd2b27-org.sonar.server.platform.db.migration.version.DatabaseVersion'
    2024.03.15 13:25:14 WARN  web[][o.s.c.a.AnnotationConfigApplicationContext] Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jdk.internal.loader.ClassLoaders$AppClassLoader@5ffd2b27-org.sonar.server.platform.DatabaseServerCompatibility': Initialization of bean failed; nested exception is The version of SonarQube is too old. Please upgrade to the Long Term Support version first.
    2024.03.15 13:25:14 ERROR web[][o.s.s.p.w.PlatformServletContextListener] Web server startup failed
    org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jdk.internal.loader.ClassLoaders$AppClassLoader@5ffd2b27-org.sonar.server.platform.DatabaseServerCompatibility': Initialization of bean failed; nested exception is The version of SonarQube is too old. Please upgrade to the Long Term Support version first.
2

Hey there.

Are there any other SonarQube instances on the same database in the target machine? Perhaps you aren’t targeting the correct one with your JDBC URL (sonar.jdbc.url)

3

No there is only the database I moved. its is a brand new vm. I dont see any other db with pgadmin

4

What happens if you try to start your existing version (SonarQube v10.1) against the database?

5

Actually the log shown above is from 10.1. Its the same with 10.4

6

Okay. My next troubleshooting suggestion would be for you to run this query and report back the result:

SELECT MAX(version) FROM schema_migrations;

7

That table has 53 rows, the query returned:
’
SELECT MAX(version) FROM schema_migrations;

“6206”
’

8

Strangely enough I do see numbers in that table that are higher:

“101026”

9

That’s very interesting – 6206 would correspond to an instance upgraded to 9.3. 101026 would indicate having upgraded to 10.1.

Do you still have the old database active where you could run this same query? A database that has been upgraded further should at least to 6804 (SonarQube 9.9 LTS).

10

The old database has 988 rows.
SELECT MAX(version) FROM schema_migrations; gives
’
“6804”
’
the tail end of the table is here:

’
“6804”
“100000”
“100001”
“100002”
“100003”
“100004”
“100005”
“100006”
“100007”
“100008”
“100009”
“100010”
“100011”
“100012”
“100013”
“100014”
“100015”
“100016”
“101000”
“101001”
“101002”
“101003”
“101004”
“101005”
“101006”
“101007”
“101008”
“101009”
“101010”
“101011”
“101012”
“101013”
“101014”
“101015”
“101016”
“101017”
“101018”
“101019”
“101020”
“101021”
“101022”
“101023”
“101024”
“101025”
“101026”
’

I dont really know what is happening here

11

It really seems like the source and target database don’t match. Maybe you can dump the old database again and start over importing that into the new database?

Typically a pg_dump and pg_restore suffice.

12

thanks I will try that

13

Colin, so I did try that. I do not get the version error anymore. I did a /setup and it says database is up to date. when I log in it does not show any projects even though the database appears to have all the data in it.
I did the backup and restore with pgAdmin.
it says How do you want to create your project?

14

Does it show that the SonarQube instance is actually well connected to the database? You can look for a big warning at the bottom of your SonarQube instance, or check the global Administration > System information.