2.1.4 upgrade fails

[shawnb61]

I suspect both the css load & the repair_settings issues are due to the http vs https problems.

[Sir Osis of Liver]

I'm now unable to run repair_settings in this install, getting 500 error.  Not seeing anything in server log.  Forcing https in .htaccess has no effect.  I've removed all mod settings from settings table, tried using absolute path to style.css in index.template.php, still can't get css to load.

[Sir Osis of Liver]

Got it working.  repair_settings requires DbExtra-mysql.php, must remove Subs-Db-mysql.php if present.  Neither is in 1.1 package.  Forum is running ok, no errors, was able to register.  It's seeing 0 attachments, so that was not a result of the upgrade.  That can't be fixed unless OP has a better db dump.

[shawnb61]

OK, back to the original topic...

Do you have a fully working copy of 1.1?  (Attachments issues aside...)

No mod tables or columns?
Columns have defaults?   (at least as much as you see in db_compare?)
All tables & columns utf8mb3?
$db_character_set 'utf8'?
global_character_set 'UTF-8'?

If so, back everything up, again again, update PHP to something current, & run the 2.1.4 upgrader.  The whole point of this was to attempt to reproduce the reported bug.

Can you reproduce it?

I cannot - and I have tried multiple times.

[Sir Osis of Liver]

The 1.1.21 install seems to be working normally in php 5.4, not logging any errors.  .htaccess is forcing https.  Registration now works (it wasn't) and new attachments can be posted.  I deleted all the mod settings in settings table, and removed mod tables from database.  Paths were all screwed up, but finally got them fixed.  It looks and works like a clean 1.1.21 install.  Will check the things you mentioned tomorrow, and if OP confirms that everything's working and content is intact, I'll try upgrading it.

[Sir Osis of Liver]

Ok, this is what I've done -

• Delete all mod tables from 1.1.21 database, contains 41 core tables
• Delete mod settings from settings table
• Clean 1.1.21 install running normally, no mods, default theme.  Everything works except old attachments, no errors
• Uploaded 2.1.4 upgrade package, run upgrade in php 8.1

Fails with same error -

Executing upgrade script 1 of 3.
Executing: "Adding and updating member data..." (4 of 19 - of this script)

Table 'thekrash_ducati1121.smf_instant_messages' doesn't exist

1.1.21 database contains pm_recipients and personal_messages, does not contain instant_messages or im_recipients.

[shawnb61]

Hmmm...

Can you share mysql info - version?  MariaDB/Percona?

Is this the same environment as prior result, or a new environment?

[Sir Osis of Liver]

Version Information:
Forum version: SMF 2.1.4 (more detailed)
Current SMF version: SMF 2.1.4
GD version: 2.3.3
MySQL engine: MariaDB
MySQL version: 10.11.11-MariaDB-cll-lve
SMF file based caching: 2.1.4
SQLite3 database based caching: 3.45.2
PHP: 8.1.31 (more detailed)
Server version: LiteSpeed

[Sir Osis of Liver]

IIRC (this is getting confusing) the original upgrade was done on production install on GoDaddy vps, failed with same errors, different platform.  I've commented out the two RENAME TABLEs, upgrade is running normally.

[Sir Osis of Liver]

Upgrade completed without issues, will check the install now but looks ok.

[shawnb61]

OMG, it's Maria DB...

If smf_personal_messages exists & smf_instant_messages does NOT exist...  And you attempt a:

Code Select Expand

RENAME TABLE smf_instant_messages TO smf_personal_messages;
Using Mysql:
    #1050 - Table 'smf_personal_messages' already exists

This is as expected, & the upgrader handles this properly (and has, for many years).

Using MariaDB:
    #1146 - Table 'van1121.smf_instant_messages' doesn't exist

Yikes...  They're actually returning different errors than MySQL...  This is bad enough I'm kinda shocked MariaDB works at all, TBH... 

To the best of my knowledge, SMF has never formally acknowledged support for MariaDB.  Quirks like this are exactly the reason why.  We've had LOTS of issues in the past with the upgrader & MariaDB.  You're normally OK once you get past the upgrader.

I know that there have been discussions about how to best support MariaDB going forward.  But this is a whole new level of behavioral difference.

Whether this is a bug or not depends on whether you consider MariaDB supported.  There is no formal SMF statement on MariaDB beyond "it usually works"...

@Sesquipedalian - for your awareness...

From the support threads here at SMF, I see two issues with MariaDB.

First, is that some MariaDB implementations have reserved words that conflict with SMF column names.  This causes syntax errors, primarily in installs, upgrades & I believe package installs will have the same issues.  Anywhere columns are added or altered. 

Second, is that their numbering scheme has strayed from MySQL.  ~10.0.2 is somewhat equivalent to ~5.6.   There are several places in SMF code where versions are checked.  This is either used to enable/disable features or to use alternate code.  SMF checks against MySQL version #s, not MariaDB version #s, and there will be issues there.  As a hypothetical example, if MariaDB starts supporting a specific feature in 10.0.5, which mySQL has in 5.7, MariaDB 10.0.2 users will experience "bugs" as SMF thinks the feature is supported, as 10.0.2 > 5.7. 

IMO, these are two fairly significant issues that must be resolved before MariaDB can be formally supported. 

[Sir Osis of Liver]

We ran upgrade on GoDaddy vps, it was not running MariaDB.  That's where we first got the error.

[shawnb61]

The above is reproducible.

If you can reproduce it in MySQL, please share the steps.

Unless you want to spend time to reproduce on GoDaddy, I'd say all that is a writeoff. 

[Sir Osis of Liver]

We did reproduce it in mysql, in the original upgrade on the GD vps.  Ran upgrade by the book.  Here's the server setup -

https://ducatimonsterforum.org/phpinfo.php

Upgrade was run in php 8.3.  Original mysql version was 3.0, not mariadb.  At some point, most likely when php was upgraded, mysqli was upped to 8.2.27, but don't know that for sure.

[shawnb61]

A note on the above...   The deeper problem with MariaDB issuing "#1146 - Table 'van1121.smf_instant_messages' doesn't exist" is that that is indistinguishable from the real error, e.g., if the tables were truly missing.

You cannot just ignore an 1146 exactly like SMF currently ignores a 1050...

I.e., if the target table already exists, it's safe to ignore the rename error, which is what the upgrader curently does.  The table exists so you're fine.  However, if the error indicates that the source table does NOT exist, that might be OK or it might NOT be OK... 

So if you were to try to fix, you cannot use the existing upgrader mechanisms at all.  You'd have to add logic to the old 1.1 upgrade scripts to detect which tables exist & which don't, etc... 

Specifically to support MariaDB 1.1 upgrades. 

[Sir Osis of Liver]

I think we're overthinking here.  The original upgrade failed with this error on a mysql platform, and now fails in mariadb.  AFAIK the error has never been reported here.  That leads me to believe there's something squirrelly about the original 1.1.21 database, which has been subjected to considerable abuse over many years, and more recently on GoDaddy.  I removed all the mod tables, and all mod and extraneous settings from settings table, and still got the error.  Only thing I can suggest is import the attached settings table into a clean 1.1.21 install and see if upgrade fails in mysql.

[shawnb61]

So, not a bug then, correct?

[Sir Osis of Liver]

Well, that's what we're trying to determine.  The upgrader is apparently incorrectly trying to upgrade a 1.1 forum as if it were 1.0. 

[shawnb61]

The upgrader is apparently incorrectly trying to upgrade a 1.1 forum as if it were 1.0.

That's been explained multiple times in these two threads.  The upgrader ALWAYS starts with the FROM version, to ensure it's solid.  Always has.  E.g., if you do a 2.0 => 2.1 upgrade, it runs two steps, the 2.0 step and the 2.1 step.  If you do a 1.0 => 2.0 upgrade, it will run three steps, 1.0, 1.1 & 2.0. 

You know this.  You've run upgrades before.  One step per file. 

This works, because the upgrader is intended to be able to be rerun. 

Well, that's what we're trying to determine.

The answer there is no.  I haven't been able to reproduce it (outside of MariaDB).  And yes, I've run many 1.1 => 2.1 and even 1.1 => 3.0 upgrades since this discussion started. 

They run fine.  Like they always have....   If the bug were as you described, nobody would have ever been able to upgrade from 1.1, ever...  Right?

You know that bugs must be reproducible.  And there is a big difference between seeing an issue once and being able to reproduce it.

Please - just go ahead & run a 1.1 upgrade in MySQL... 

[Sir Osis of Liver]

I've already run the upgrade in mariadb with those two steps commented out, ran fine, everything works, not logging any errors.  Will try running upgrade again in mysql on GoDaddy server using cleaned up 1.1.21 database if that's what OP wants to do, else I can have him import upgraded database from my server into his production install.  It's not my forum, I don't have control panel or database access, so I'm limited in what I can do.