Update CMS 2.3.10 to 3.0.0 -> CMS is temporarily offline

Get Help
1

Hi,

we tried to update our CMS from 2.3.10 to 3.0.0.

But unforntunately after the update there is only a window saying “The CMS is temporarily offline due to an update in progress. Please check with your system administrator for updates or refresh the page in a few minutes.”.

It does not change after an hour. Is there a way to verify whats going on?
We use a Linux/Docker setup.

We tried it again after restoring the 2.3.10, same outcome → “The CMS is temporarily offline…”

The Portainer log for the web-cms shows this:

We will upgrade it, take a backup

mysqldump: Error: ‘Access denied; you need (at least one of) the PROCESS privilege(s) for this operation’ when trying to dump tablespaces

Running database migrations

Phinx by CakePHP - https://phinx.org. 0.9.2

using config file .varwwwcmsphinx.php

using config parser php

using migration paths

  • /var/www/cms/db/migrations

warning no environment specified, defaulting to: production

using adapter mysql

using database cms

== 20200311110512 AddIsDrawerColumnMigration: migrating

== 20200311110512 AddIsDrawerColumnMigration: migrated 0.0415s

== 20200311110535 CreateActionTableMigration: migrating

== 20200311110535 CreateActionTableMigration: migrated 0.0077s

== 20200319093235 ChangeInterruptLayoutMigration: migrating

== 20200319093235 ChangeInterruptLayoutMigration: migrated 0.0173s

== 20200401121544 AddSystemUserSettingMigration: migrating

== 20200401121544 AddSystemUserSettingMigration: migrated 0.0028s

== 20200407143200 AddCodeColumnToLayoutMigration: migrating

== 20200407143200 AddCodeColumnToLayoutMigration: migrated 0.0379s

== 20200422101006 AddDataSetRowLimitMigration: migrating

== 20200422101006 AddDataSetRowLimitMigration: migrated 0.0752s

== 20200427085958 AddReportScheduleStartEndMigration: migrating

== 20200427085958 AddReportScheduleStartEndMigration: migrated 0.0233s

== 20200530103029 DisplayRemoteLinksMigration: migrating

== 20200530103029 DisplayRemoteLinksMigration: migrated 0.0821s

== 20200604103141 CommandImprovementsMigration: migrating

== 20200604103141 CommandImprovementsMigration: migrated 0.1029s

== 20200612141755 OauthUpgradeMigration: migrating

== 20200612141755 OauthUpgradeMigration: migrated 0.0467s

== 20200720092246 AddSavedReportSchemaVersionMigration: migrating

== 20200720092246 AddSavedReportSchemaVersionMigration: migrated 0.0154s

== 20200916134817 RemoveOldScreenshotsMigration: migrating

== 20200916134817 RemoveOldScreenshotsMigration: migrated 0.0029s

== 20200917140227 DisplayGroupCreatedModifiedDates: migrating

In PdoAdapter.php line 134:

SQLSTATE[22007]: Invalid datetime format: 1292 Incorrect datetime value: '0

000-00-00 00:00:00’ for column ‘createdDt’ at row 1

Regards

2

Thank you for your post.
I have passed this onto our development team who will investigate further. Here is the link to the reported issue:

3

Thank you for reporting this - good catch :fishing_pole_and_fish:

We’ve updated the image, please can you do a docker-compose pull once you have a v3 xibo-docker files in place, and then try again?

4

Hi Dan,

tried this, new error:

== 20201007080829 AddFoldersMigration: migrating

In PdoAdapter.php line 134:

SQLSTATE[42S01]: Base table or view already exists: 1050 Table ‘folder’ alr

eady exists

5

That is the very next migration after the one you had an error with, so I think perhaps you haven’t restored to your 2.3.10 database?

We only add the folders table once in all the migration files, so somehow that table has been added before.

6

Hi Dan,

I tried the following now:

Zwischenablage01
Zwischenablage011065×311 71.9 KB

7

Sorry that isn’t quite the right way around - you will already have the old release-3.0.0 image stored locally, so you need to do:

I hope that makes more sense now :crossed_fingers:

8

Did exactly these steps, but getting still:

== 20201007080829 AddFoldersMigration: migrating

In PdoAdapter.php line 134:

SQLSTATE[22007]: Invalid datetime format: 1292 Incorrect datetime value: '0

000-00-00 00:00:00’ for column ‘createdDt’ at row 1

9

Hi Dan,

I tried this fix: Xibo (docker on Ubuntu 18.04) update from 2.3.10 to 3.0.0-rc3 stuck on db migration

Adding the following to the docker-compose.yml:

command: mysqld --sql_mode=“ONLY_FULL_GROUP_BY,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION”

Zwischenablage01
Zwischenablage011024×260 56.5 KB

Now, no error occurs during migration, but

Homepage schedule.view nicht gefunden.

comes up after login. This is already reported here: 404 script errors and schedule.view is not available after 3.0.0 upgrade and migration

Zwischenablage02
Zwischenablage02360×504 34.9 KB

But I can access the CMS using a “deep-link”, like: http://server-ip/schedule/view

I think I will wait a bit, until we update our production envioroment.

10

We’re having a difficult time recreating this issue upgrading (although others have encountered it too!). Would it be possible to PM me a backup of your database so that I can try to upgrade it locally and see the problem for myself? If that is OK, you could upload it to https://transfer.xibo.org.uk and then PM me the link?

The schedule.view issue we’ve solved and will make an update for. Thanks.

11

Have sent you our DB via PM.

1 Like
12

Thanks a lot for that - it has helped us locate and solve the migration issue!

We have built a new container which we will release as 3.0.1 in due course, in the meantime we’ve added the MySQL workaround to our docker file archive for the 3.0.0 release.

There are two ways to fix the schedule.view issue - either update your docker-compose.yml file and replace release-3.0.0 with release30, do a docker-compose pull and then an up… or edit your user and select one of the homepages defined there.

Thanks again for all the help with this!

Best wishes,
Dan

13

Hi Dan,

I tried it again, did everything as always, now V3.0.0 comes up and I can login w/o changing anything!

Best regards!

1 Like
14

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.