It's a problem with your MySQL server. Try to repair all your MySQL tables using a tool like phpmysql before attempting any upgrade.

phpMyAdmin has a repair tool. I tried it on the test installation that I had tried to upgrade. The upgrade still failed, or continued to fail.

How can I be sure that I won't get this message if I try to upgrade my real insntallation?

I also did a new install of 6.7.5, used phpMyAdmin's repair. Tried to upgrade to 6.8.2, and got the same error.

@drherz wrote earlier:

phpMyAdmin has a repair tool. I tried it on the test installation that I had tried to upgrade. The upgrade still failed, or continued to fail.

How can I be sure that I won't get this message if I try to upgrade my real insntallation?

The only way you will know is when you upgrade. The truth is that the php version your test server is using may not meet the requirements. For production servers the hosting service are usually fairly good at ensuring the php version is updated.

Make a backup of your production website database. Then upgrade. If it crashes then you can just reload from your backedup copy.

I actually experienced a similar issue with a test server, but everything was fine on the production server. Just backup and update.

I'm still at php 5.6. 7.0 is available. Should I step up to that?

Seriously look at the MySQL error message you get. It clearly says your database is broken and you need to repair it. This is a problem inside MySQL, not a problem that b2evo can create.

Now if you did repair and the database is broken again rig after that it probably means your server hard drive is Dying. I have seen this in the past.

You really need to talk to you web host / server admin about this.

Ps: and yes broken tables may appear to work until you upgrade because upgrade touches the whole table instead of just adding lines at the ends as normal use might do.

Niltze!

Upon upgrading from b2evo-6.7.8 to 6.8.2, I got exactly the same error as the b2evo-user who initiated this thread.

I had DB backups, notwithstanding. After several attempts, varying slightly the installation procedure, outcome was the same fail described by b2evo-user above. Accordingly, settled for the least disruptive upgrade to 6.7.9 to address the urgent security issue.

Software/hardware Infrastructure:
1) Instance runs on Google Compute Engine (GCE) - on a custom Debian Jessie (stable distribution) cloud instance - on Reiser4 root filesystem.
2) Custom build of Apache web server 2.4.2x
3) Custom build of PHP 7.0.x
mysql Ver 15.1 Distrib 10.1.1x-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

I will attempt an upgrade on a local virtual machine where I may swipe MySQL for MariaDB.

PS Attempting to normalize the database after a backup recovery (and prior to upgrade) results in attached snapshot:

Best Professional Regards.

Francoise, what is says is "incorrect key file," I'm not a database guy. I use b2evo to blog, and chose it because it was reported to be a robust yet simple solution for my blogging purposes.

I don't have any idea who generated the key file, or what that means. What's obvious to you is not necessarily obvious to your users. And most of us don't want to waste the time tracking this down.

What I know is that I have multiple instance of 6.7.5, and even created a new instance, and all of them are failing in the same way, more or less. Brand new database, Brand new tables, courtesy of b2evo, downloaded from b2evo's site, ftp'd to mine. Repaired or not, giving me the same error.

I've shared the error with GreenGeeks. The only thing they've told me is that my table isn't all UTF-8. I'll copy GreenGeeks on your message above, but it seems to me that the main constant here is 6.7.5.

It just shouldn't be this hard.

And now I'm also concerned with the fragility of this system. I just don't want to have the worry that every time I try to upgrade, I could lose access to my data because of something that might have happened years ago.

@drherz wrote earlier:

And now I'm also concerned with the fragility of this system.[].

Should not be 'concerned' - as it appears to be a bug.

I have upgraded other users' system versions dating from b2evolution 3.x to recent versions and this is the first time I encountered the puzzling error you (and I, at least) are experiencing.

Best Professional Regards.

Hey, here's what my tech people at GreenGeeks say, and this was with my clean install of 6.7.5

Hi,

According to the upgrade log the issue is related with your database - the table evo_antispam doesn't exist
MySQL error!
Table 'theherze_atest.evo_antispam' doesn't exist(Errno=1146)
We haven't backup of this database so can't restore the missed table.
Please get back to us if you need any further assistance and let us know how else we can help.
Thank you and have a great day,

Ivan Djakov
GreenGeeks Support Team

Ticket Details

Niltze, @FPlanque-

Upgrading b2evolution 6.7.9 to 6.8.1 in VirtualBox 5.1.8 environment:

In another test upgrade in a local virtual machine running Debian Stretch/Sid on Reiser4 root filesystem, I get the same DB error that @drherz opened this thread with.

1) mysql Ver 15.1 Distrib 10.0.28-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
2) PHP 5.6.26-1
3) Server version: Apache/2.4.23 (Debian)

Please note that I also have another open source LAMP CMS currently in the virtual machine running normally.

Hopefully I will be locally testing upgrade with MySQL -- instead of MariaDB -- later and will report outcome.

Best Professional Regards.

The issue appears to be that b2evolution, starting with 6.8.1, does not play nice with MariaDB 10.st.xy.

I have successfully upgraded previously restored b2evolution 6.7.9 to version 6.8.1 in a local VirtualBox 5.1.8 environment running Debian Jessie (stable) on Reiser4 root file system. Only difference is that I installed MySQL 5.5.53-0+deb8u1 (Debian) rather than the various versions of MariaDB in prior Debian Jessie (stable) and Debian Sid (unstable) instances.

(After first phase/screen, I selected bottom orange rectangular button labeled "Try to Repair/Upgrade database now!";
and subsequent second phase/screen attached followed -- showing successful upgrade.)

Accordingly, GreenGeeks hosting is likely running MariaDB and thus beginning with b2evolution 6.8.1, there is a nasty conflict with her.

Best Professional Regards.

As a final note, backing up the MySQL 5.5.53-0+deb8u1 (Debian) just upgraded b2evolution-6.8.1 database in its Debian Jessie (stable) virtual machine instance host, I am able to successfully restore DB to a MariaDB 10.st.xy deployment running in a Debian Sid (Unstable) instance.

I am using community version of Zmanda backup 3.0 < http://www.zmanda.com/download-zrm.php >

Hopefully the above discussion sheds some light into the issue that others may (will ;-) experience.

Best Professional Regards.

@nanahuatl Thank you for your tests.

So, to summarize, am I understanding correctly that your tests come to these conclusions:

• Works with MySQL
• With MariaDB, there is a bug and when we try to rename the table, MariaDB says "Incorrect Key file" ?

@fplanque wrote earlier:

@nanahuatl Thank you for your tests.

So, to summarize, am I understanding correctly that your tests come to these conclusions:

• Works with MySQL
• With MariaDB, there is a bug and when we try to rename the table, MariaDB says 'Incorrect Key file'?

Exactly, @Fplanque.

Specifically -- for this upgrade case:

MySQL error!

Incorrect key file for table 'evo_antispam__keyword'; try to repair it(Errno=1034)

Cheers!

Just to confirm, I raised this again with Green Geeks. They did confirm the following:

Hello David,

On our servers we are using 10.0.28-MariaDB mysql version which is similar 5.6 mysql version. I am not familiar with this cms and not sure if it is compatible with new version but if it was working for previous b2evolution version, I think it should work for the new version b2evolution too. I have checked softaculous under cpanel and there is only available version 6.7.9 for your b2evolution cms. I would recommend you to try to upgrade it using softaculous feature but please make sure that you are using correct path for this cms into a setting.

https://gyazo.com/3d6afea14ee46629c0c48039be6c11de
https://gyazo.com/a9ff4a75190ae389ce1dd87cf4c02273

If you are able to run this upgrade on your local PC, you can replace current files with new version and import a new info info into your database on our server.

@drherz wrote earlier:

Just to confirm, I raised this again with Green Geeks. They did confirm the following:
[...]
I have checked softaculous under cpanel and there is only available version 6.7.9 for your b2evolution cms.

That's correct, b2evolution 6.7.9 does not touch MariaDB for the upgrade (verified by applying only delta difference from 6.7.8 a week ago to my deployments ;-). But starting with b2evolution 6.8.1 introduces conflict with MariaDB in your host.
[...]
@drherz wrote earlier:

If you are able to run this upgrade on your local PC

b2evolution 6.7.9 addresses the most pressing security issue for the moment. But...

Notwithstanding, as long as you have MySQL in your local computer and/or virtual machine stack, the the b2evolution upgrade to 6.8.2 will work. Then making a local backup of your updated database (and changed files) and uploading those to your host, respectively, will work.

Just make sure to verify settings in b2evolution/conf/_basic_config.php for remote instance -- as they may vary from your local and/or virtual machine hosting MySQL. And double-check permissions for the remote MariaDB instance relevant for your applications.

Best Professional Regards.

@nanahuatl Thank You so much. I really appreciate your attention, but you've just gone over my technical head. I suppose I will wait until I get the nod that an upgrade to 6.8.x will work with MariaDB, or just hang out until 7.x.x comes out and hope I can go straight to that.

It turns out recent versions of MariaDB do NOT support changing fields and indexes in a single SQL query. Older version of MariaDB did support that. MySQL and most other DBs support that. We think it's a bug in maria DB v10+.

Workaround: split the SQL query in 2 separate steps: https://github.com/b2evolution/b2evolution/commit/e9f788843845563b7ef9cbf1877fe277c028a344

Will be in next release.

@fplanque wrote earlier:

[] recent versions of MariaDB do NOT support changing fields and indexes in a single SQL query.[] We think it's a bug in maria DB v10+.

Workaround: split the SQL query in 2 separate steps: https://github.com/b2evolution/b2evolution/commit/e9f788843845563b7ef9cbf1877fe277c028a344

Will be in next release.

Added comments and modifications (found at your link above) by editing file:
/b2evolution/install/_functions_evoupgrade.php
prior to an attempted b2evolution upgrade from 6.7.8 to 6.8.2

And above modification introduced -- at the same spot in the upgrade routine -- a show stopper error:

Table 'evo_antispam__keyword' already exists(Errno=1050)

Your query:

RENAME TABLE evo_antispam TO evo_antispam__keyword

First, I want to thank you both for your attention to this. It has certainly set my mind at ease. I did manage a work around on one of my databases, I uploaded a new version of 6.8.2 and then pointed it to the database I had tried to upgrade with earlier (no backup; so something had to give), I think it was at this point, I renamed the table back to evo_antispam so it could find that and rename it to the one with the keyword ending. I don't know why it worked, and it didn't work when I played with my other installations. For those I had a backup though; so I'm happy waiting using 6.7.9 until the next version comes out.