Hi,
I want to upgrade my xibo server (apache2 V1.8.12) to the new version but i am stuck on this page :
“The CMS is temporarily off-line as an upgrade is in progress. Please check with your system administrator for updates or refresh your page in a few minutes.”
Are there any additional steps required for an upgrade to V2?
Thank you.
You need to run the database migrations.
From the console, inside your Xibo install directory you’d run
php vendor/bin/phinx phinx.php migrate
You should see migrations run and complete, and then the web interface will be unlocked.
Indeed it’s works with this line :
php vendor/bin/phinx migrate
I didn’t found this information on the documentation.
Thanks alot !
I am having the same issue after upgrading to v2. I am running xibo with docker on ubuntu 16.04. When i go to my /opt/xibo directory where i have it installed and try to run the “php vendor/bin/phinx migrate” when i try to run this it says that it could not open the file vendor/bin/phins. Any help?
With Docker the migrations are run for you. You don’t need to run them manually.
If you get the logs from the cms-web container (docker-compose logs -f cms-web) you should see them having been run - or still running potentially - together with any errors.
So far it has taken almost 20 hours. Should it be taking this long? I can post the log out put.
cms-web_1 mysqldump: Got Error 1146 “table ‘cms.lktagedisplaygroup’ doesn’t exist when using LOCK TABLES” is the only error that it shows.
C:\wamp\www\xibo-cms>php vendor/bin/phinx migrate
Warning: require(C:\wamp\www\xibo-cms\vendor\bin/…/app/phinx.php): failed to open stream: No such file or directory in C:\wamp\www\xibo-cms\vendor\bin\phinx on line 27
Fatal error: require(): Failed opening required ‘C:\wamp\www\xibo-cms\vendor\bin/…/app/phinx.php’ (include_path=’.;C:\php\pear’) in C:\wamp\www\xibo-cms\vendor\bin\phinx on line 27
Please hep me out in fixing this?
It shouldn’t take 20 hours no.
Please post the complete logs for the cms-web container, redacting anything sensitive and I will take a look.
Attaching to xibo_cms-web_1
cms-web_1 | Waiting for MySQL to start - max 300 seconds
cms-web_1 | MySQL started
cms-web_1 | Updating settings.php
cms-web_1 | settingId
cms-web_1 | 1
cms-web_1 | Existing Database, checking if we need to upgrade it
cms-web_1 | Phinx by CakePHP - https://phinx.org. 0.9.2
cms-web_1 |
cms-web_1 | using config file .varwwwcmsphinx.php
cms-web_1 | using config parser php
cms-web_1 | using migration paths
cms-web_1 | - /var/www/cms/db/migrations
cms-web_1 | warning no environment specified, defaulting to: production
cms-web_1 | ordering by creation time
cms-web_1 |
cms-web_1 | Status [Migration ID] Started Finished Migration Name
cms-web_1 | ----------------------------------------------------------------------------------
cms-web_1 | up 20180130073838 2019-03-20 15:45:08 2019-03-20 15:45:08 InstallMigration
cms-web_1 | up 20180131113100 2019-03-20 15:45:08 2019-03-20 15:45:08 OldUpgradeStep85Migration
cms-web_1 | up 20180131113853 2019-03-20 15:45:08 2019-03-20 15:45:08 OldUpgradeStep86Migration
cms-web_1 | up 20180131113941 2019-03-20 15:45:08 2019-03-20 15:45:08 OldUpgradeStep87Migration
cms-web_1 | up 20180131113948 2019-03-20 15:45:08 2019-03-20 15:45:08 OldUpgradeStep88Migration
cms-web_1 | up 20180131113952 2019-03-20 15:45:08 2019-03-20 15:45:08 OldUpgradeStep92Migration
cms-web_1 | up 20180131113957 2019-03-20 15:45:08 2019-03-20 15:45:08 OldUpgradeStep120Migration
cms-web_1 | up 20180131114002 2019-03-20 15:45:08 2019-03-20 15:45:08 OldUpgradeStep121Migration
cms-web_1 | up 20180131114007 2019-03-20 15:45:08 2019-03-20 15:45:08 OldUpgradeStep122Migration
cms-web_1 | up 20180131114013 2019-03-20 15:45:08 2019-03-20 15:45:08 OldUpgradeStep123Migration
cms-web_1 | up 20180131114017 2019-03-20 15:45:08 2019-03-20 15:45:08 OldUpgradeStep124Migration
cms-web_1 | up 20180131114021 2019-03-20 15:45:08 2019-03-20 15:45:08 OldUpgradeStep125Migration
cms-web_1 | up 20180131114025 2019-03-20 15:45:08 2019-03-20 15:45:08 OldUpgradeStep126Migration
cms-web_1 | up 20180131114030 2019-03-20 15:45:08 2019-03-20 15:45:08 OldUpgradeStep127Migration
cms-web_1 | up 20180131114050 2019-03-20 15:45:08 2019-03-20 15:45:08 OldUpgradeStep128Migration
cms-web_1 | up 20180131114058 2019-03-20 15:45:08 2019-03-20 15:45:08 OldUpgradeStep129Migration
cms-web_1 | up 20180131114103 2019-03-20 15:45:08 2019-03-20 15:45:08 OldUpgradeStep130Migration
cms-web_1 | up 20180131114107 2019-03-20 15:45:08 2019-03-20 15:45:08 OldUpgradeStep131Migration
cms-web_1 | up 20180131114110 2019-03-20 15:45:08 2019-03-20 15:45:08 OldUpgradeStep132Migration
cms-web_1 | up 20180131114114 2019-03-20 15:45:08 2019-03-20 15:45:09 OldUpgradeStep133Migration
cms-web_1 | down 20180131114118 OldUpgradeStep134Migration
cms-web_1 | down 20180131114123 OldUpgradeStep135Migration
cms-web_1 | down 20180131122645 OneRegionPerPlaylistMigration
cms-web_1 | down 20180131123038 PlaylistTagsMigration
cms-web_1 | down 20180131123248 WidgetFromToDtMigration
cms-web_1 | down 20180212143336 DaypartSystemEntriesAsRecords
cms-web_1 | down 20180213173846 MailFromNameSettingMigration
cms-web_1 | down 20180219141257 DisplayGroupClosureIndexToNonUnique
cms-web_1 | down 20180223180534 DataSetColumnFilterAndSortOptionsMigration
cms-web_1 | down 20180302182421 WidgetCreatedAndModifiedDtMigration
cms-web_1 | down 20180313085749 MediaTableEditedIdIndexMigration
cms-web_1 | down 20180320154652 PlaylistAddDynamicFilterMigration
cms-web_1 | down 20180327153325 RemoveUserLoggedInMigration
cms-web_1 | down 20180514114415 FixCaseOnHelpTextFieldMigration
cms-web_1 | down 20180515123835 LayoutPublishDraftMigration
cms-web_1 | down 20180529065816 DataSetTruncateFixMigration
cms-web_1 | down 20180529073531 DisplayAsVncLinkMigration
cms-web_1 | down 20180621134013 AddWidgetSyncTaskMigration
cms-web_1 | down 20180621134250 EventLayoutPermissionSettingMigration
cms-web_1 | down 20180906115552 AddForeignKeysToTagsMigration
cms-web_1 | down 20180906115606 AddForeignKeysToPermissionsMigration
cms-web_1 | down 20180906115712 AddForeignKeysToWidgetMediaMigration
cms-web_1 | down 20180906131643 ForgottenPasswordReminderMigration
cms-web_1 | down 20180906131716 DataSetRssMigration
cms-web_1 | down 20181011160130 SimpleSettingsMigration
cms-web_1 | down 20181113173310 RemoveFinanceModuleMigration
cms-web_1 | down 20181113180337 SplitTickerModuleMigration
cms-web_1 | down 20181126113231 Release1812Migration
cms-web_1 | down 20181210092443 RemoveImageUriModuleMigration
cms-web_1 | down 20181212114400 CreatePlayerVersionsTableMigration
cms-web_1 | down 20181217135044 EventSyncMigration
cms-web_1 | down 20190121092556 PlayerUpgradeAndOverrideConfigMigration
cms-web_1 | down 20190125170130 PlayerSoftwareVersionFieldMigration
cms-web_1 | down 20190129103831 AddLinuxDisplayProfileMigration
cms-web_1 | down 20190212115432 AddDefaultTransitionDurationSettingMigration
cms-web_1 | down 20190213162212 AddHorizontalMenuSettingMigration
cms-web_1 | down 20190220165703 AddScheduleRecurrenceMonthlyRepeatsOnMigration
cms-web_1 | down 20190227101705 MakeDisplayLicenseColumnUniqueMigration
cms-web_1 | down 20190228120603 AddDynamicCriteriaTagsMigration
cms-web_1 | down 20190301115046 AdjustGenericfileValidExtensionsMigration
cms-web_1 |
cms-web_1 | We will upgrade it, take a backup
cms-web_1 | mysqldump: Got error: 1146: “Table ‘cms.lktagdisplaygroup’ doesn’t exist” when using LOCK TABLES
cms-web_1 | Running database migrations
cms-web_1 | Phinx by CakePHP - https://phinx.org. 0.9.2
cms-web_1 |
cms-web_1 | using config file .varwwwcmsphinx.php
cms-web_1 | using config parser php
cms-web_1 | using migration paths
cms-web_1 | - /var/www/cms/db/migrations
cms-web_1 | warning no environment specified, defaulting to: production
cms-web_1 | using adapter mysql
cms-web_1 | using database cms
cms-web_1 |
cms-web_1 | == 20180131114118 OldUpgradeStep134Migration: migrating
cms-web_1 |
cms-web_1 |
cms-web_1 | [PDOException]
cms-web_1 | SQLSTATE[42S21]: Column already exists: 1060 Duplicate column name ‘isDispl
cms-web_1 | ayNotification’
cms-web_1 |
cms-web_1 |
cms-web_1 | migrate [-c|–configuration CONFIGURATION] [-p|–parser PARSER] [-e|–environment ENVIRONMENT] [-t|–target TARGET] [-d|–date DATE] [-x|–dry-run]
cms-web_1 |
cms-web_1 | Importing ca-certs
cms-web_1 | cp: can’t stat ‘/var/www/cms/ca-certs/.pem’: No such file or directory
cms-web_1 | cp: can’t stat '/var/www/cms/ca-certs/.crt’: No such file or directory
cms-web_1 | WARNING: ca-certificates.crt does not contain exactly one certificate or CRL: skipping
cms-web_1 | Configuring Maintenance
cms-web_1 | Removing web/install/index.php from production container
cms-web_1 | Starting cron
cms-web_1 | Starting webserver
cms-web_1 | AH00558: httpd: Could not reliably determine the server’s fully qualified domain name, using 172.20.0.4. Set the ‘ServerName’ directive globally to suppress this message
So for the first error from mysqldump, I would assume you have a crashed or missing table. Did someone perhaps delete the idb file for that table from the shared/db folder?
Beyond that, the migrations fail saying that there is already a column “isDisplayNotification”. That should only happen if you’ve previously run upgrades in 1.8 that failed or partially completed.
To resolve, you’d need to fix the error with the missing table first. Once that is corrected, you’ll need to initially remove the column shown from the database and that should allow the migration to run.
in the shared/db/cms folder i can see both the .frm and the .idb files for the the table in question. as for the isDisplayNotification error there was an error with the database the last time we upgraded. We had to restore the db from an older backup.
Also looking at the backup we have of the old database the iktagdisplaygroup.idb or iktagdisplagroup.frm do not exist.
If the files are there, then perhaps the table is crashed. You could try repairing the table first.
Can you recommend anything else to run? or how to go about repairing the table from there?
You would need to use MySQL’s own routines to repair the table, or in the worst case drop it and recreate it based on the schema for the version of 1.8 that you are trying to upgrade from.
What directory is the actual db? I am trying to do the repairs and mysql is having trouble locating where the database and tables are.
Inside the container, it’s in the MySQL default (/var/lib/mysql).
You shouldn’t be trying to repair it from outside.
If i am in there there is no trace of any database relating to xibo.
Then either you’re using an external database rather than the one provided by the containers, or you’re not inside the MySQL container.
If there’s corruption in your database, and it seems there is, then if you want us to look at it we may be able to do so on a paid basis. Otherwise I can only really offer you general guidance.
If you aren’t able to make it work, I’d suggest rolling back to your pre-upgrade backup and checking the status of the tables in the database at that point.