upgrading from 1.1.15 to 2..0.17 Ubuntu 18.04

[SteveZand]

Here are some tips for people like me who still need to upgrade their old version of the board.

I picked up my server from the datacenter, since I also had to upgrade Ubuntu.

After upgrading to Ubuntu version 18.04 LTS, PHP 7.2.24, MySQL 5.7.29

I tried to run the old version of smf , which off course gave lot of errors.

So i tried to run the smf installer 2.0.17 which started find, but suddenly midway halted with an unclear error-code, 1292 i believe. I couldn't find any solution online.

So I tried smf installer 2.0.15 which also didn't succeed,  I got some MySQL error.

So I thought instead of trying to install an older version of PHP on the server, lets run smf from xampp-win32-5.6.36-0-VC11 and let smf connect to the server MySQL database instead of the xampp MariaDB database which is also incompatible with the Smf upgrade script.

Than again I got some errors, which where cause by the strict Sql mode of MySql.

One of the errors was:

Incorrect date value: '0000-00-00' for column 'eventDate' at row 1

These SQL modes are standerd configured on Ubuntu MySQL

Code Select Expand

ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

You should at least disable these two:

Code Select Expand


-ONLY_FULL_GROUP_BY
-STRICT_TRANS_TABLES


More info about SQL modes here [nofollow]


After trying to upgrade for the umpteenth time and the script again halted with an unclear error-code, with no warning that I was still busy.
I tried to DROP the smf database for re-importing the backup.

Than I noticed that the database wasn't immediately dropped, so i used in MySQL to see what process was locking the smf database,

I saw that the upgrade script query to alter a table was still running.

Code Select Expand



SHOW FULL PROCESSLIST;

1660 | steve | 192.168.1.10:12246 | forum | Query   |  405 | copy to tmp table | ALTER TABLE smf_messages
                                 CHANGE COLUMN subject subject varchar(255) NOT NULL default '' |

1660 = process id
405 = number of seconds the script is running



Several of these alter table queries took more than 4 minutes each to complete, because I have a pretty large board.

No warning at all from the upgrade page only a small error-code, which make you falsely think, that the upgrade halted with an error-code.

So what I did the next time I run the upgrade script, every-time it seemed like the script halted with an error-code I run

Code Select Expand


SHOW FULL PROCESSLIST;


To check if the query was finished. when it was I did a refresh of the page and the script continued.

Finally after many hours of frustration I was able to upgrade the board to version 2.0.17. 

[shawnb61]

Helpful post for very large boards.  I see two major takeaways:
- Set the sql mode to '' before upgrade.  An empty string should be fine. 
- On large boards, some queries can run for several minutes.  Any time the server disappears for > 30 seconds, your browser gives you a warning.  Your browser doesn't know if it died or not, just that it hasn't heard back in 30 seconds... 

Under most circumstances, just waiting is the right course of action.  But how do you know for sure?  Your suggestion of querying the processes is a good way to tell whether it died or whether it's still working on a long-running query. 

[SteveZand]

- On large boards, some queries can run for several minutes.  Any time the server disappears for > 30 seconds, your browser gives you a warning.  Your browser doesn't know if it died or not, just that it hasn't heard back in 30 seconds... 

The thing is that it isn't your browser which times out. It's the script itself which gives you a unclear error-code, 1292, something like this:

Code Select Expand


Fixing guest voter tallys on existing polls...done

   Error!
          1292


And than nothing happens for minutes.

Clicking the "Continue" button also doesn't work!

Which makes you assume that the script halted with some script error! And that's very confusing.

The script only continues as the MySQL query is finished and you refreshes the page (F5), not intuitive at all.


I think that for many people with a large bord a commanline upgrade tool would be a much better option then a web-script.


But nevertheless I know your doing a lot of hard work and I like many really appreciate this! 

[shawnb61]

The 1292 is fallout from the sql_mode being too strict ("incorrect date value"), and was a real failure.  It really stopped. 

You can, in fact, run the upgrade via the command line.  It has some quirks, but it works.  (For some things CLI is better, for others, the browser is better.)

The message that is confusing is the "Server has not responded for 30 seconds" message (pic below).  When you see this, all the browser knows is that it hasn't heard back from the server.  This could be an outright failure or a query just taking too long.  It almost always makes sense just to give it more time when you see these - for large forums, a lot more time.   THESE errors are much more clear via CLI - a failure would stop outright, whereas a long-running query would still be running.  Via browser, your suggestion would be helpful here - check the processes before giving up.

[SteveZand]

You can, in fact, run the upgrade via the command line.  It has some quirks, but it works.

How? And what are the quirks? :-)

[shawnb61]

CLI reports lots of errors that aren't really errors.  It has some issues, in particular with large updates spanning multiple versions, like 1.0 => 1.1 => 2.0.  It works, but you may find some settings not properly updated & have to find/fix them manually.  The best thing about CLI is you know FOR SURE when things fail or not...

In general, the browser is better on all these fronts, but, as you have seen, sometimes it doesn't know when the server gave up on it. 

Basically, you copy the files over just like a browser upgrade.  Then, on the CLI, you navigate to that folder and:

php upgrade.php <switches>

For a list of switches:

php upgrade.php ?

Some hosts may want you to provide the path for php, e.g.:

/opt/php56/bin/php upgrade.php ?

[SteveZand]

Ok, tnx :-)