large upgrade from 1.1.13 to 2.0.7 - massive Problems - Error at step 1

[devnul]

Dear Community,

while trying to upgrade my smf-1.1.13 to current 2.0.7, I encounter some showstopping problems.
(Test-)Environment is a dedicated machine in my LAN, running linux, mysql, apache with php5, httpd on port 8044. So I have access to everything there.
php.ini is set for very long running scripts and input (both 3600) and memory limit is 1 GB.

First the error about outdated language files:
The update-script extract the first 4KB from the given language files in Themes/default/languages/.  Then it looks for a version-string and extract that with a regex. It compares the found language-version with current smf version. This MUST fail, because the actual downloadable lang-files (german and english) have version numbers from 2.0 to 2.0.6, while upgrade.php defines "2.0.7" as SMF_LANG_VERSION.
For this I've made a workaround by replacing all

Code Select Expand

if (empty($match[1]) || $match[1] != SMF_LANG_VERSION)
with

Code Select Expand

if (empty($match[1]) || substr($match[1],0,3)!=substr(SMF_LANG_VERSION,0,3) )
in upgrade.php. That works so far.

But after logging in as admin and choosen the upgrade options (no DB backup, because I have already one; Extra-Output=On) and pressed "OK", the script need about 30 seconds and then terminates with an "unknown error".

Database Changes
Executing database changes
Please be patient - this may take some time on large forums. The time elapsed increments from the server to show progress is being made!
Executing upgrade script 1 of 2.
Executing: "Updating and creating indexes..." (1 of 19 - of this script)

Error!
Unknown Error!

14% Overall Progress
0.4% Step Progress
Time Elapsed: 11 mins, 5 seconds.

Now I stuck. The apache error log has no entries when running this (slightly modified) upgrade script.
I've searched this site for solutions, but found nothing relevant.
Any suggestions, hints, known bugs?

Thanks in advance,
devnull

[margarett]

Was 1.1.13 running correctly in your local machine before starting the upgrade?

[devnul]

Was 1.1.13 running correctly in your local machine before starting the upgrade?

yes, it does.  I've currently restored the files and DB to test it again. The old version is running as expected.

I've searche a bit in the upgrade code and found the error is thrown by upgrade_1-1.sql in line 4050. But this does not explain, where or what the real error is.

...

[margarett]

I wouldn't advise you to go down that route...
It's clear that the upgrade can have issues, yes. But none are currently known. And it has for sure upgraded *thousands* of forums out there.

It would be wiser to try and understand why do you have an "Unknown Error" and what does that represent...
First of all: which upgrade package are you using? My upgrade package has a file upgrade_1-1.sql that ends in line 2655

[devnul]

...
First of all: which upgrade package are you using? My upgrade package has a file upgrade_1-1.sql that ends in line 2655

Please excuse, if my words sounds not as respectful, as they should be. Unfortunally I'm not a native english speaker 
And sorry for the wrong filename, the error is indeed thrown by upgrade.php, line 4050.  I should show more discipline, when communicate such stuff. The headline "Updating and creating indexes..." points to upgrade_1-1.sql, where I where lost in the SQL Statements for a moment 

[Herman's Mixen]

i would not recommend that route as 1.1.13 is pretty old... first patch the 1.1.x branche to 1.1.19 from there you can go to 2.0.7 as there where some database changes don't know in wich one of the 1.1.x branche...

so large upgrade 1.1.14, ....15 .... 16 ...17 ....18 ... 19... from here you can now go to 2.0.7...
do everything in english while you are upgrading when you finshed your 2.0.7 upgrade process you can easily add the new "German" language from your admin panel and set it active...

[margarett]

Actually it should work directly from that version (although not totally sure, but the converter should work from 1.0 )

Anyway, here are related topics
http://www.simplemachines.org/community/index.php?topic=496787.0
http://www.simplemachines.org/community/index.php?topic=482762.0

Another one that was able to bypass this error by insisting
http://www.simplemachines.org/community/index.php?topic=452154.0

Finally, if it still happens after carefully running repair_settings, activate debug mode in the upgrade tool and please give us the output
As you can see, the solution was to run repair_settings and fix the paths before running the upgrade tool

[devnul]

thanks for your answers, guys. I'll try all this tomorrow. My local time is 3:20 am and I'll go to bed now. CU then

[devnul]

First of all THANK YOU ALL.

...
As you can see, the solution was to run repair_settings and fix the paths before running the upgrade tool

I've done repair_settings and it shows me, how the settings and paths should be. Unfortunally it is not able to store the edited values. Apache error.log says:

Code Select Expand

PHP Fatal error:  Cannot redeclare smf_db_replacement__callback() (previously declared in /srv/www/htdocs/forum/repair_settings.php:971)
in /srv/www/htdocs/forum/repair_settings.php on line 971, referer: http://forum.homeserver.local:8044/forum/repair_settings.php but I was able to workaround that, by editing the DB directly with phpmyadmin.

The main settings are found in the table <db_prefix>settings and the theme paths in <db_prefix>themes. I've found the relevant entries by issue the SQL statements

Code Select Expand

SELECT * FROM <table> WHERE `variable`  LIKE "%\_url" OR `variable` LIKE "%\_dir" (replace <table> with the real table name, ...settings or ...themes, as mentioned above) and then editing the values manually. This was about 24 entries, so it was easy to handle. To avoid trouble, I've also set <db_prefix>settings.enableCompressedOutput and <db_prefix>settings.queryless_urls to 0.  The field queryless_urls will be deleted by the upgrade, but Idon't knew that at this time 

After doing all that, the upgrade runs through successfully. So, it seems, the wrong paths and urls of the unused themes (default, classic, babylon) caused the error. Again, thank you for beating me, to look on correct paths. I suggest to integrate this hint and a link to repair_settings in the upgrade tool.
Now I can start to apply my mods. The forum is integrated in a larger site, where a login is already done, when calling the forum. So I can rely on this and must bypass it to forums authentification. But this will be another thread 

[margarett]

Thank you for letting us know. And glad you sorted it out

It seems you also identified an issue with repair_settings that we'll check immediately.