Well, I made a backup of the old site first.
Copied over the upgrade files, extracted from the 2.0.9 large upgrade file.
When I run the "upgrade.php", I get an unknown error at 14% of step 1.
Now, in order to get back to where I started, I have to reinstall the entire backup (solid 1.5 hours for that), as the upgrade process put the site in "maintenance mode" which prevents me from accessing the site to bring it back up again.
Yes, I should not have allowed the script to put the site in "maintenance mode". Lesson learned.
So, question is, how do I get from 1.1.20 to 2.0.9 now?
Maintenance mode wouldn't help you to go back online. After the upgrade has started, the database format is not compatible with 1.1.x anymore. What you *must* do is to pick a full backup before you start ;) (which you did)
You can try the upgrade again, it should continue. But that error would probably pop up again... That's what we need to debug
edit: check this post/topic here http://www.simplemachines.org/community/index.php?topic=523072.msg3700978#msg3700978
Well, I tried to run the "repair_settings.php" script and it shows everything, but the options for restore all hooks, remove all hooks, remove this file, and save settings do not appear on the page, at all.
Is there another "repair_settings.php" script for 1.1.20? The page for the one I got from the site says it is for SMF 2.0.
No, the tool is unique. It "detects" if you're on 1.1.x or 2.0.x
As you're on 1.1.x there are no buttons for hooks (they only exist in 2.0.x) ;)
Now, not having the "save" button is another story entirely...
Also, the suggested settings are equal to the current settings or are there differences?
Here are the errors coming from PHP in the php error log. We are running PHP 5.6.5.
[06-Feb-2015 22:29:52 UTC] PHP Notice: Undefined index: database_error in /usr/local/apache/share/htdocs/smf/Sources/Subs-Db-mysql.php on line 594
[06-Feb-2015 22:29:52 UTC] PHP Fatal error: Call to undefined function allowedTo() in /usr/local/apache/share/htdocs/smf/Sources/Subs-Db-mysql.php on line 595
I am also not seeing the screen/options about themes.
The settings, being shown in what is there seems to be correct, except for the missing 'cache' directory, which is expected.
Yes, I understand the missing "hooks" options should not be there. Literally, the last line on the screen is "Attachment Directory". Nothing follows that.
That function exists in Security.php.
But Subs-Db-mysql.php doesn't exist in 1.1.x
So you need to run repair_settings *before* starting the upgrade and while having the 1.1.x files in place. The idea is to be sure that everything is in place before starting the upgrade.
When repair_settings breaks in half it's always because of messed files/versions...
Okay, that got the upgrade running. Now I am facing a timeout issue at 43%. Not surprising to me, as I have nothing but issues with SMF's 30 second timeout with everything.
You guys really need to make that a tunable! My board has over 2 millions posts in it and 20,000+ users.
How can I get the upgrade to finish without timing out on me every thirty seconds?
ummm..... the SMF "timeout" is purposeful and is to avoid overloading the server. It should automatically continue on to the next bit after a 5 second wait...
if you are getting a DIFFERENT time out that doesn't refresh.... it may be related to your SERVER not responding...
Unfortunately there's no better way to do it... The upgrade is an intense process and, for some reason, your server doesn't take the beating it's getting...
You can increase this timeout by editing upgrade.php
// General options for the script.
$timeLimitThreshold = 3;
That time is seconds x 10. So you can try to increase it to, eg, 6, which should allow 60 seconds of wait.
The server I am working with, at the moment, is a dog. It is a test system to see how the upgrade goes. If all goes well, then I get to attempt it on a live server.
Thank you for the support. If you do not hear from me, then all went well.
Just FYI. It is at altering the 'messages' table and is having to a "copy to_tmp table" to do it. That copy will take about 12 minutes.
Hmmm that's interesting to know, actually. I always thought that the server was really "dying" but it seems that the upgrader isn't really giving it enough time to complete.
So, what's your current value of $timeLimitThreshold?
I set it to 60. So far I am 35 minutes into the 'messages' table 'repair by sorting' function.
Seems to be moving along just fine. Now at 62.7% of the "adjusting text fields". Another adjustment to the 'messages' table? Dang.
Okay, a third pass through the 'messages' table, at 64.7%. Still running.
This could take quite a while at about 1 hour per 'alter table' for the 'messages' table.
Quote from: Skuzzy on February 09, 2015, 12:29:19 PMThank you for the support. If you do not hear from me, then all went well.
If all does go well, please at least swing by and mark the thread solved. ;D
You are right.
Took just less than 10 hours for the test upgrade to complete. Now I need to check the configuration and see how I can get back functionality we had before.
Then I get to do it one more time, for real. :)
Quote from: Skuzzy on February 09, 2015, 12:03:45 PM
My board has over 2 millions posts in it and 20,000+ users.
My forum has about 115,000 posts and 3000 users - much less.
I increased the timeout to 5 minutes, but even that wasn't enough. The table it's timing out on is the search cache. I very much wish I'd emptied all the caches before starting this. Can I do it manually by truncating a table? Which table is this?
smf_log_search* ;)
There is no "log_cache" table in SMF :o
I said log_search*, which means log_search_something (as there are 4 log_search_something tables)
I deleted the message you're responding to so I could move the discussion back over to the other thread. I posted here by accident.
Here it is again:
Quote
Ugh - the table log_cache (which I guessed was the table the script times out on - and while I'm typing this message you confirmed) is not in the database, weirdly. Did upgrade.php delete it?
I'm afraid I need to start again - delete everything, reclone the site, empty all caches, run repair_settings.php, move the SMF 2.0 files over, run upgrade.php. :(
How did the table get deleted??
It's weird, though - I have other tables that have much more data than this one. The sessions table is over 1GB. Maybe I should truncate that one, too?
I'm going to try copying just the structure of log_cache from the update site, truncate the sessions table, and restart. Hopefully it will complete.
"log_cache" was a typo. I meant "log_search". In any case, it didn't work. I need to start again. :(
I'm having continuing problems, but I went back to posting in the original thread. Here's the link, if anyone is interested (or kind enough to help):
http://www.simplemachines.org/community/index.php?topic=536615
The problem I was having with the upgrade script hanging had a different cause. FYI (for anyone else upgrading to SMF 2.0 from an early version of SMF 1.1)...
I was upgrading from SMF 1.1 Beta 3 to SMF 2.0.10. I had to first upgrade to SMF 1.1.21 for the SMF 2.0 upgrade script to work. This is because the early versions of SMF 1.1 used one search cache table, log_search, while the latest versions of SMF 1.1.21 - and SMF 2.0 - use four: log_search_*. The upgrade script was hanging when it tried to update the search cache because it was looking for four tables, finding only one, and not handling the error gracefully.