Upgrade manually from 1.7.9 to 1.8 not working

I’m running Xibo on a dedicated Ubuntu 14.04 server. I just installed 1.7.9 last week (about two days before 1.8 was released). Since we really have not started using it yet, I want to upgrade to 1.8 but I do not want to use Docker. I have followed the instructions and I’m getting an error when I go to the url as it is trying to redirect me to the login page and that does not exist. Then I go to /install and get another error telling me that “The CMS has already been installed”.

Any thoughts or ideas?

Update - If I remove the settings.php I get the regular “Welcome to the Xibo Installation” page. Unfortunately when I click on the next button I get a page not found /install/2

Update 2 - found many other issues that were not previously disclosed. First I had to install ZMQContext. Here is a good script for Ubuntu, install zeromq in ubuntu 14.04 · GitHub just need to change the bash location. Then I had to enable php5-zmq. Then manually run the vendor/bin/xmr.phar to get xmr enabled. Then make sure that the rewrite module is enabled in Apache. Then change the /var/www config in the apache2.conf to allow for .htaccess rewrites. Then and only then could I get past the /install/2 404 not found error. The post below is what clued me in to look at the rewrite.

Update 3 - Now I am able to use my old settings.php file and get to the login screen. I login and see the list of everything to run through the upgrade. Unfortunately it is erroring out on step 51 and skipping this step will not allow it to go past.

1.8.0-alpha Upgrade XMDS - Part 2
SQLSTATE[42S21]: Column already exists: 1060 Duplicate column name ‘bytesRequested’

Well, after steps 51-54 failed, then several others failed (no I didn’t write them down), the upgrade finished. Note, after you click to skip a step, you then have to go back to the top and click the Start button again. Then I was brought back to a login screen. I was able to login but there was no data in any table. I ended up reverting back to a previous snapshot of the vm and now back using 1.7.9.

I’d still be interested in hearing thoughts on what may have gone wrong.

I think all the environment changes you’ve mentioned are covered in the documentation.

Going forward, we can’t guarantee to provide support for custom CMS installations as the requirements for the CMS grow beyond a simple LAMP stack, so switching to Docker is strongly recommended.

As to why the upgrade steps failed, it’s hard to say without seeing what was in your system to start with, however in general you shouldn’t skip past steps unless you fully understand why that step failed, and that it has done so in a way that means future steps that may depend upon it aren’t impacted.

@alex That all makes sense, to some extent.

I understand using docker in lots of instances. In this case, it is very easy for me to spin up a new vm and load what ever I need on it. That is the case with this install. It’s on a Ubuntu 14.04 server, running all by itself. I guess I’ll cross that bridge about docker when I have to.

On the failed steps. I can clone this machine and run through it again anytime. With snapshots, it is easy to revert back when something goes wrong or you want to try it a different way. I’m happy to do that if you think it would help you track down what might have happened.

Let me know.

You’ve basically just described the benefits of running in Docker - easy upgrade, easy rollback.

What your VM doesn’t give you however is the exact same environment in which the CMS has been developed and tested in. Variations therefore in how you choose to configure things will ultimately mean that things like this upgrade don’t run smoothly for you, or at the very least are less likely to.

Setting up Docker inside a VM on Ubuntu is less than 5 minutes work, and you can import your existing 1.7 series install in. You won’t then need to worry about the PHP dependencies, getting XMR and XTR working etc


I did take your suggestion and setup a new server running Ubuntu 16.04 and installed Docker. It was very easy to get the Xibo container up and running. What I have found that I don’t like is that I cannot easily get to all the code, database, etc. I have to trust that it is fine inside the container. Little old fashion / manual I guess…LOL.

I also am running where I force https, so I’ll be making another post to highlight how I had to modify your instructions on Xibo 1.8.0 with Docker on Ubuntu 16.04.

My last question is how do I make sure the Xibo container automatically starts up when the server is rebooted?

It will start automatically by default.

Force HTTPS is covered in the original guide. You simply choose that option when running the Lets Encrypt setup.

I don’t want to use LetsEncrypt for this server. In this case we own wildcard certificates and I want to use that. I documented my changes in another post.

Thanks. I had a quick look. Your post still references Lets Encrypt however, so it might be worth editing that.

Also how does that configuration score on SSL Labs test? If it’s going as a guide it would be good to ensure it gets an A there :slight_smile:

Haha, great catch. Got that LetsEncrypt reference outta there.

The Xibo server does not have access from the Internet, but I do have another similarly configured server that uses the same kind of forwarding. I ran that through SSL Labs test and it scores a B (because it accepts RC4 cipher). Once that was disabled, it scores an A

Did that change (disabling RC4) make it in to the Guide?

Yep it did :slight_smile:

1 Like