Followed the upgrade instructions to the letter. made a backup of settings php, dumped my sgl to a file and cleaned the Xibo directory right out. Extracted the 1.76CMS stuff into it and copied back the settings.php file. I tweaked my php.ini this time to allow large file uploads and after testing that with all installation requirements ticked off, and clicking next to go to the second stage it says upgrade successful but does not direct me to login again as the instructions state.
If I then close the upgrade page and then try to log in again I just arrive back at the Welcome to Upgrade page and nothing works. If I proceed through the upgrade process again I then get a message again saying upgrade successful but also another message saying it cant delete install.php - but of course that was already deleted when the first upgrade attempt āallegedlyā completed successfullyā¦
I have read that it may be a browser cache issue but sorry, that is not the case - tried clearing the cache several times, even tried in a different browser but still the same - just get taken back to the Welcome to the Xibo Upgrade page and nothing in the left sidebar does anythingā¦
Tried restarting Apache2 - no difference.
Iām just permanently stuck in Welcome to Upgrade modeā¦
I have just gone through the process from scratch again.
After copying the 1.70 āUpgradeā into the clean webserver Xibo directory and copying in my backed up setting.php file I then navigate to server/xibo. I then get asked to login which I do with my usual admin account. The welcome to Xibo upgrade page appears. All requirements are ticked off. I click next and receive a message saying upgrade successful but thatās it - no direction to login again as the release notes suggest will happen. I also notice that on the top right corner of the page next to my login avatar icon there is an exclamation mark. Clicking the exclamation mark opens a message box saying āthere is a problem with this installationā - the upgrade must be able to delete the installation.php file or similar wording. But when I look in the Xibo folder the installation.php file HAS been deletedā¦
For now I have just simply restored my original 1.7.4 Xibo web directory back again and it continues to work fine just as it did before - but it would be good to get the 1.7.6 version working if anyone has any ideas as to why it gets stuck in Upgrade mode?
Sounds like the filesystem permissions are wrong and thatās preventing the upgrade completing.
You need to make sure that the user your webserver runs as has permission to write/delete files in your installation directory - at least while the upgrade runs.
If you want to prevent that afterwards you can but things like uploading fonts wonāt work as expected in that case.
Also if the 1.7.4 CMS works against the database after youāve run the upgrade on it then 100% it hasnāt been upgraded as thereās a version check in there that would prevent that happening. So Iād be more suspicious that something is preventing the database being written to. Perhaps the permissions you granted on it are wrong?
Thanks for the ideas Alex. I tend to agree that itās more likely a database issue. I think the permissions on the webserver directory must be fine - my original install was trouble free, the system has worked since and coincidentally it was only a couple of days back that I did install an extra font into the CKE; also the upgrade is able to delete the installation.php file so the webserver user must have write permission on that directory yes?
However it does seem odd that the original install of install of 1.74 didnāt have any problems writing to the databaseā¦ Iāll check through everything āpermission wiseā though.
Cheers
Chris
The last step in the upgrade is to run this:
UPDATE `version` SET `app_ver` = '1.7.6', `XmdsVersion` = 4, `XlfVersion` = 2;
Which essentially says āweāve done, donāt come back into the upgrade againāā¦ if the upgrade screen isnāt clearing down then it seems likely that this statement failed to run for some reason.
If you have a way to run SQL on your installation you could look in the version table after the upgrade and see what it says - this might give us a better idea whats happening.
Other than this, iām afraid I donāt have anything to suggest beyond what Alex has already said
OK thanks for that.
I have checked permissions on the www/htdocs/xibo directory and all seems fine. It is also the case that the install.php file does get deleted so clearly no permission problem there.
I looked at the Mysql xibo database and it seems owner and group are both mysql with both having rw permissions. its also the case that the database has been modified by the xibo client over the past few months as new layouts ect have been added. To be on the safe side I did chmod 777 on the database. Tried the upgrade again and once again get a message syaing āUpgrade Successfulā but next to my login icon is an exclamation mark which when clicked open a box saying āthere is a problem with this installation, the install.php should be deletedā but of course when I check the Xibo folder the installation.php file has been deleted. If I then try and logout I get taken back to the upgrade screnn adn progressing through it again results in a message about checking that the webserver can unlink the installation.php fileā¦
Iāll see if I can get a copy of the version table after the upgrade and post it here. I note that I am not the only one to have had this problem.
Iām not aware of this being a general problem. There may have been one of two other cases but on a user base of tens of thousands of installations that doesnāt make it a āknown issueā so to speak.
That said you still need it working.
Weāre going to need the information Dan has requested before we can help further.
Also I meant by āMysql Permissionsā not the permissions on the files themselves (you wonāt want those chmod 777!), but the MySQL grant on the database when you created it.
OK here is the copy of my version table from mysql immediately after the upgrade to 1.7.6 fail
MariaDB [physign]> SELECT * FROM version;
Ā±--------Ā±------------Ā±-----------Ā±----------+
| app_ver | XmdsVersion | XlfVersion | DBVersion |
Ā±--------Ā±------------Ā±-----------Ā±----------+
| 1.7.4 | 4 | 2 | 89 |
Ā±--------Ā±------------Ā±-----------Ā±----------+
1 row in set (0.00 sec)
I can see that the 3 files - version.MYD version.MYI and version.frm in the database directory have not been modified since they were installed they still have dates Jun11th 2015 (.MYD & .frm) and Jul2nd 2015 (.MYI)
Itās rather unclear to me as to why these files were added to the db without problem when the installation was first done, but the upgrade installation fails to now access themā¦
I note also that after clicking next on the first page of the upgrade I see a message that states āupgrading database version 89 to 89ā - same version number?? along with a box to check that I have a copy of my database saved somewhere - which I have so I tick it
The mysql user and password are as defined in the settings.php file which I am copying into the xibo folder along with the 1.7.6 upgradeā¦ I can use the exact same credentials to access the db at a mysql shell prompt.
Thanks for you time in assisting
Chris
What version of MySQL is your MariaDB installation equivalent to?
We donāt test with or support MariaDB so it may be some incompatibility there causing an issue.
The 89 is successfully written to the database table (the patch level) but you can clearly see that itās not been able to write the app version to the table successfully. Does MariaDB give any error logging to show any queries that may have failed to run properly?
MariaDB version 5.5.46 running on SuSe 13.1. I believe that the MDB version numbers are supposed to align with the mysql ones. Iāll have a poke around and see what I can come up with in the way of MDB logs. At least I am learning stuff about sql databases along the way 
EDIT:
Ok so I have now enabled query logging in MariaDB and I can see some errors relating to upgrade.
In particular at the end of a big block of text listing all the nn.sql files is the following :-
ā84.sqlā;}upgradeTo|s:2:ā89ā;username|s:13:āphysign-adminā;userid|s:1:ā1ā;ErrorMessage|s:45:āupgrade does not support the function: logoutā;ā WHERE session_id = 'eu6****
There are also some other errors such as :-
41 Query INSERT INTO log (logdate, type, page, function, message, requesturi, remoteaddr, useragent, userid, displayid, scheduleid, layoutid, mediaid) VALUES (ā2016-02-08 16:40:33ā, āerrorā, āclockā, āā, āupgrade does not support the function: GetClock\n256\nUser Error\n/srv/www/htdocs/xibo/lib/app/pagemanager.class.php\n155\nā, ā/xibo/index.php?p=clock&q=GetClock&ajax=true&_=1454949573346ā, ā144.173.133.46ā, āMozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0ā, ā1ā, ā0ā, ā0ā, ā0ā, āā)
However as 2 clients are also connecting to the server there is a lot of ānoiseā in the log file. I will shut down the clients later clean the log file out and then run the upgrade again in order to just capture the upgrade activity.
Thanks for your help and patience so far
Chris
You are restoring your backup between upgrade attempts right?
If itās upgrading from 89 to 89 then no upgrade steps will run so the version would never be changed. Youāll need to be sure you go back to your 1.7.4 database backup before re-running the upgrade.
Ah - no I havenāt been doing that. I assumed as the first attempt to upgrade failed, and that as the original database still seems to work with the 1.7.4 xibo directory re-instated, that I was good to go with trying the upgrade againā¦ 
Chris
Given the database seems to have been upgraded in part then restoring to the known-good 1.7.4 backup would be the best idea I think. Then if you can get a log of whatever it is failing during the upgrade we can progress. Thanks
OK this is interesting - I have now restored my āpre upgrade attemptā of the original sql dump of the database that was running 1.7.4 into a new database that I have named physign176.
I thought I would check to see whether the DBVersion was indeed something lower than 89 but in fact it is 89!
MariaDB [physign176]> select * from version
-> ;
Ā±--------Ā±------------Ā±-----------Ā±----------+
| app_ver | XmdsVersion | XlfVersion | DBVersion |
Ā±--------Ā±------------Ā±-----------Ā±----------+
| 1.7.4 | 4 | 2 | 89 |
Ā±--------Ā±------------Ā±-----------Ā±----------
Now I am baffledā¦
However I will try pointing my settings.php to this database and run the upgrade on a clean log file.
Thereās no point in running an upgrade against that as it wonāt do anything.
So somehow your āpre-upgradeā database has had an upgrade run against it. The only way now to figure out what has and hasnāt been done is to step through 88.sql and 89.sql and see which of the statements have already been run and which havenāt - then run all the intermediate steps to bring it up to date.
Wait no 89 is 1.7.4 release so thatās fine.
If itās saying it wants to upgrade from 89 to 89 then you donāt have a 1.7.6 installation there - itās 1.7.4
ā¦ which it seems was exactly the problem - if you run an award for stupidity then I will consider myself well and truly nominated!
I can only offer the excuse of trying to deal with too many different things at the same time. It rather looks like I hadnāt actually downloaded 1.7.6 at all, but then later assumed I had and used the 1.7.0 targz archive which must have been left there from the original 1.7.4 install. Having just gone through the procedure with the 100% definitely 1.7.6 installation I now see database upgrading from 89 to 91.
The only thing that saves my honour slightly is that the install still does not logout on completion and I still see the exclamation mark top right with the message that the installation.php should be deleted - but closing the browser window and then navigating back to the login page does now show me a 1.7.6 login page; so this is obviously just a slight glitch in the end of the install check\cleanup stage.
Given the time you have spent so far in assisting with this Iām more than happy to try running the installation process again on a clean logfile, and assist in any other way I can if you wish to try and troubleshoot this minor problem? Otherwise I am sorted now and can only thank you for your patience and time over this.
You are a gentleman!
Cheers
Chris