Copy the datebase and open the copy with a text editor then

replace all occurrences of post_ptyp with post_ityp

save and import

Maybe :)

No. The error is here:

MySQL error!
Incorrect key file for table 'evo_items__item'; try to repair it(Errno=1034)

This is a MySQL error. Not a b2evolution error.

If you have errors like that at every upgrade it is not because of b2evolution but because your server is not reliable. (Typical scenario: the server often gets rebooted by turning power off and on without a proper shutdhown).

So what you need to do is use the DB maintenance tools (like Phpmyadmin) to repair your DB or ask your web host to do it.

Well, this is a new webhost, I just moved a bunch of sites away from hostgator (should have gotten away from there a long time ago). So I've experienced similar upgrade errors on 3 different webhosts over the last 6 years or so.

I ran the database repair function and I got the following:

[myuser_b2evotest1.evo_antispam] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_antispam__iprange] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_basedomains] status: OK
[myuser_b2evotest1.evo_bloggroups] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_blogs] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_blogusers] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_categories] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_coll_settings] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_comments] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_comments__prerendering] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_comments__votes] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_cron__log] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_cron__task] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_email__address] status: OK
[myuser_b2evotest1.evo_email__campaign] status: OK
[myuser_b2evotest1.evo_email__campaign_send] status: OK
[myuser_b2evotest1.evo_email__log] status: OK
[myuser_b2evotest1.evo_email__returns] status: OK
[myuser_b2evotest1.evo_files] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_filetypes] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_global__cache] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_groups] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_groups__groupsettings] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_hitlog] status: OK
[myuser_b2evotest1.evo_i18n_original_string] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_i18n_translated_string] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_items__item] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_items__item_settings] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_items__itemtag] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_items__prerendering] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_items__status] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_items__subscriptions] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_items__tag] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_items__type] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_items__version] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_links] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_links__vote] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_locales] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_messaging__contact] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_messaging__contact_groups] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_messaging__contact_groupusers] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_messaging__message] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_messaging__prerendering] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_messaging__thread] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_messaging__threadstatus] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_plugin_captcha_qstn_14_ip_question] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_plugin_captcha_qstn_14_questions] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_pluginevents] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_plugins] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_pluginsettings] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_pluginusersettings] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_postcats] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_regional__city] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_regional__country] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_regional__currency] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_regional__region] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_regional__subregion] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_sessions] status: OK
[myuser_b2evotest1.evo_settings] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_skins__container] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_skins__skin] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_slug] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_subscriptions] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_syslog] status: OK
[myuser_b2evotest1.evo_track__goal] status: OK
[myuser_b2evotest1.evo_track__goalcat] status: OK
[myuser_b2evotest1.evo_track__goalhit] status: OK
[myuser_b2evotest1.evo_track__keyphrase] status: OK
[myuser_b2evotest1.evo_users] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_users__fielddefs] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_users__fieldgroups] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_users__fields] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_users__invitation_code] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_users__organization] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_users__postreadstatus] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_users__reports] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_users__user_org] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_users__usersettings] note: The storage engine for the table doesn't support repair
[myuser_b2evotest1.evo_widget] note: The storage engine for the table doesn't support repair

Also, when I run "check database" there are no errors shown...

EDIT: Interesting.. the database is a mix of InnoDB and MyISAM tables.. the InnoDB tables are the ones saying they don't support repair.. No idea why there is a mix of tables. This particular b2evo installation is relatively new and is the original installation version (5.2.2).. i.e. It's never been updated yet.

The mix of innoDB and MyISAM is normal.

If you can't repair a table that MySQL says is broken, you can try to export it, delete it and re-import it.

Who's your new webhost? How long has your site been running on their servers so far?

@fplanque wrote earlier:

If you can't repair a table that MySQL says is broken, you can try to export it, delete it and re-import it.
Who's your new webhost? How long has your site been running on their servers so far?

This particular site is being hosted on a trial basis at hostwithlove.com and has been there for approx 3 months now. They have a solid reputation so we're giving them a try on a monthly basis. Prior to that it was at hostgator but their service is getting worse every month while their prices continue to rise.

I should add that this particular db upgrade is being done as a test. I dumped the live blog database via command-line, imported it into a test database via command-line, and then attempted the b2evo upgrade on the test db. Isn't that essentially what you're recommending when you mentioned export, delete, re-import?

@jibberjab wrote earlier:

I should add that this particular db upgrade is being done as a test. I dumped the live blog database via command-line, imported it into a test database via command-line, and then attempted the b2evo upgrade on the test db. Isn't that essentially what you're recommending when you mentioned export, delete, re-import?

Yes it is. Maybe there was a problem during re-import?

How about trying this: re-import anew, then check/repair as much as possible in PhpMyAdmin and only then run the upgrade?

I can try it again, but I've already dropped, re-exported, and reimported a few times and am getting the same result each time.

If there is a problem with that particular table, check/repair doesn't work anyway. All the tables that are InnoDB say they don't support check/repair. From my earlier post, this is what I get when attempting repair on that table:

[myuser_b2evotest1.evo_items__item] note: The storage engine for the table doesn't support repair

Also worth noting is the live database / live blog works just fine.. no errors, no failed pages, so I'm not sure I trust the message that says the db has a problem.

This time I exported a new copy of the live db, dropped the test db, imported the new dump, and ran the repair function. I got the exact same repair results as I showed in my 2nd post in this thread. This time, I tried the normalization procedure first, and I get yet another error:

Normalizing DB charsets...
Loading module: _core/model/__core.install.php
Loading module: collections/model/_collections.install.php
Loading module: files/model/_files.install.php
Loading module: sessions/model/_sessions.install.php
Loading module: messaging/model/_messaging.install.php
Loading module: maintenance/model/_maintenance.install.php
Normalizing evo_antispam... OK
Normalizing evo_antispam__iprange... OK
Normalizing evo_basedomains... OK
Normalizing evo_bloggroups...
An unexpected error has occurred!

If this error persists, please report it to the administrator.

Go back to home page
Additional information about this error:

MySQL error!

Unknown column 'bloggroup_perm_item_type' in 'evo_bloggroups'(Errno=1054)

Your query:

ALTER TABLE `evo_bloggroups`

      MODIFY bloggroup_perm_poststatuses    set('review','draft','private','protected','deprecated','community','published','redirected') COLLATE ascii_general_ci NOT NULL default '',

      MODIFY bloggroup_perm_item_type       ENUM('standard','restricted','admin') COLLATE ascii_general_ci NOT NULL default 'standard',

      MODIFY bloggroup_perm_edit            ENUM('no','own','lt','le','all') COLLATE ascii_general_ci NOT NULL default 'no',

      MODIFY bloggroup_perm_cmtstatuses     set('review','draft','private','protected','deprecated','community','published') COLLATE ascii_general_ci NOT NULL default '',

      MODIFY bloggroup_perm_edit_cmt        ENUM('no','own','anon','lt','le','all') COLLATE ascii_general_ci NOT NULL default 'no'

This time I exported a new copy of the live db, dropped the test db, imported the new dump, and ran the repair function. I got the exact same repair results as I showed in my 2nd post in this thread. This time, I tried the normalization procedure first, and I get yet another error:

On what version did you do that?

At this point I have doubts about the fact your original DB is a 100% clean and compliant 5.2.2 DB.

Please try to upgrade your 5.2.2 install to 5.2.2. yes I really mean upgrade 5.2.2 to 5.2.2. You do this by force selecting the upgrade option in the 5.2.2 install/index.php script. It will tell you that it's already up to date but in addition it will check if your DB is 100% compliant to what it expects and attempt to repair. Again, I am talking about using the 5.2.2 version here and running the installer it contains. (Also: do NOT mix the install folder of a version with the inc folder of another. Do all this test away from your 6.6 code).

Note: I added an "optional step" here: http://b2evolution.net/man/upgrade-instructions to suggest doing this. We'll try to provide a tool to do this automatically from the backoffice in future versions.

(I really can't figure out how this system adds image attachments. They seem to change order and placement every time I preview the post, so I'm doing this reply in 3 parts)

Ok, I downloaded a fresh 5.2.2-stable installer, SCPd it to a new test folder on my server, unzipped it and then moved the contents of the 'blogs' folder up 2 folders so it sits in the root. I dropped the test db, dumped a new copy of the live 5.2.2 db, and imported it into the test db. I ran the 5.2.2 installer and selected the upgrade option. It gave me what you see in the first image. Important to note, the "Upgrade failed" message at the bottom showed up at that point without me clicking on the "Upgrade database!" button that you see there.

(cont'd below)

At this point I clicked the "Upgrade database!" button to see what would happen. The results are in the second image.

At this point I dumped the newly upgraded 5.2.2 db and imported it into a fresh db. I downloaded the 6.6.3 installer, SCPd it to the server in its own folder, unzipped, moved all contents of 'b2evolution' folder up 1 folder (the new installer has a different file/folder structure than older versions) and I then proceeded with upgrade. It prompted me to define the db, username, and passwd as expected and also gave me the same message about normalizing after installation. I then proceeded with upgrade and I got the same error msg as before:

Upgrading b2evolution...
Checking files...

Preparing to install /.htaccess in the base folder...
Upgrading data in existing b2evolution database...
Loading module: _core/model/__core.install.php
Loading module: collections/model/_collections.install.php
Loading module: files/model/_files.install.php
Loading module: sessions/model/_sessions.install.php
Loading module: messaging/model/_messaging.install.php
Loading module: maintenance/model/_maintenance.install.php

Checking DB schema version... 11285 : OK.
Upgrading locales table... OK.
Creating message prerendering cache table... OK.
Upgrading categories table... OK.
Create table for User post read status... OK.
Create table for System log... OK.
Creating DB schema version checkpoint at 11300... OK. (Elapsed upgrade time: 1 seconds)
Upgrading cron tasks table... OK.
Upgrade table system log... OK.
Upgrade groups table... OK.
Updating general settings... OK.
Creating table for User invitation codes... OK.
Creating table for User organizations... OK.
Creating table for relations users with organizations... OK.
Upgrading Item Settings... OK.
Upgrade table files... OK.
Upgrade table posts... OK.
Upgrade table post prerendering cache... OK.
Upgrade table post versions... OK.
Upgrade table comments... OK.
Upgrade table comment prerendering cache... OK.
Upgrade table messages... OK.
Upgrade table message prerendering cache... OK.
Upgrade table user field definitions... OK.
Upgrade table cron tasks... OK.
Upgrading users table... OK.
Updating users pass storage... OK.
Creating DB schema version checkpoint at 11310... OK. (Elapsed upgrade time: 5 seconds)
Update locales to utf-8 charset... OK.
Upgrade table files... OK.
Add new video file types... OK.
Creating DB schema version checkpoint at 11320... OK. (Elapsed upgrade time: 5 seconds)
Upgrade table blogs... OK.
Creating DB schema version checkpoint at 11330... OK. (Elapsed upgrade time: 6 seconds)
Upgrading blogs table... OK.
Creating DB schema version checkpoint at 11340... OK. (Elapsed upgrade time: 6 seconds)
Update category ordering... OK.
Creating DB schema version checkpoint at 11350... OK. (Elapsed upgrade time: 6 seconds)
Upgrade table posts...
An unexpected error has occurred!

If this error persists, please report it to the administrator.

Go back to home page
Additional information about this error:

MySQL error!

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

Your query:

ALTER TABLE evo_items__item
      CHANGE post_ptyp_ID post_ityp_ID int(10) unsigned NOT NULL DEFAULT 1,
      DROP INDEX post_ptyp_ID ,
      ADD INDEX post_ityp_ID ( post_ityp_ID )

At the end of your comment 2 out of 3, you should run the upgrade again and have it say that everything is clean.

Once you trust that process, you should definitely apply it on your production DB too. Because there is no doubt your current DB is NOT a 5.2.2 DB and there must be errors in your 5.2.2 install somewhere you don't necessarily see them.

Also please note that when you upgraded to 5.2.2 (some long time ago) you must have gotten the same issues OR you have modified your DB after that (one way this can happen is start an upgrade and stop it in the middle; another is: install development versions). But you have been running a "not 5.2.2" DB on your 5.2.2 install for some time. That HAS to create errors when you try to upgrade again.

Now, once that is done, of course this is the clean DB you need to start with to upgrade to v6.

I am at a loss explaining the Incorrect key file for table 'evo_items__item'; try to repair it(Errno=1034). All I can say for sure is that the problem is in MySQL.

Also since this repeats:

1. Are you 100% positively sure that you deleted the whole old DB before trying again. Is there ANY chance you could be trying to upgrade the same broken mySQL DB over and over without having replaced it with a new one?
2. You should ask your webhost about how to repair the broken index.
3. What I would do: set up MAMP or WAMP or XAMP on your local computer, import your clean DB there and try it there. I am 99% sure it will not tell you you have a broken key file.

This evening I'll try it again by re-running the 5.2.2 to 5.2.2 upgrade a few time to make sure it's clean.

This particular blog was never upgraded to 5.2.2. It's a relatively new blog which I'm maintaining for a friend, and it began life at 5.2.2.

As for being sure the old db was deleted.. I didn't delete the entire db, but I dropped all tables until it was empty. That was for the 5.2.2 to 5.2.2 upgrade. After that, the 5.2.2 to 6.6.3 attempted upgrade was done on a brand new db that I imported the 5.2.2 into.

When you make a brand new 5.2.2 install and try to run an upgrade to 5.2.2 on it, it cannot find a difference (because it actuallt compares to the same structure than the one it used to create the brand new 5.2.2). So something must have happened to your friend's DB since the time of install.

Did you use any 3rd party tool for install ( Fantastico, Softaculous, other? )

No I never use automated installers. I downloaded the release from the b2evo site, uploaded it to the server, unzipped it, and ran the install script. If this were a mysql problem then how is the blog running without a single error ever appearing?

I've now run the 5.2.2 -> 5.2.2 "upgrade" 5 times in a row to make sure "everything is clean" as you said. It finished without any errors. I then dumped that db, imported it into a new blank db, and ran the 6.6.3 upgrade again. Again, the same exact error.

I have to say again, the 5.2.2 blog started at 5.2.2 and was never upgraded or partly upgraded or half upgraded. It was installed without any errors and it's been running just fine the entire time since then.

Ok, so if this blog was a fresh 5.2. install, what if you now make a fresh 5.2.2 install in a (separate) DB and then upgrade this to 6.6.3?

In other words: does it work when you try to upgrade a minimal 5.2.2 install?

Also, have you tried, as I suggested before, to run the upgrade on your local machine instead of your server?

I'm going back and forth with a tech support person at my host.

I was able to download DBs from 3 different sites onto my debian laptop, and was able to upgrade all 3 without issue, so that's some significant progress.

Now, what I'm wondering is whether there is some kind of incompatibility between b2evo and cloudlinux. That's the only thing I can see being the cause, since my host is running cloudlinux while my laptop is just a straight mySQL install.

Anything else you can think of to ask that I can relay to the tech support person handling my ticket?

Many hosts use cloudlinux nowadays. i have successfully upgraded a 5.2 to 6.5 while testing A2 hosting for example.

I would suspect a problem on the particular server you are on. I hope they can move your account to another server to check if it changes things.

Before migrating to another server though, I think you should also try my other suggestion of upgrading a minimal 5.2 to 6.6 on your server to see if the problem is the same.

I'm mentioning this just to see if it throws any hint over the issue.

@jibberjab did you ask your hosting support to check the server's disk space?

Incorrect key file for table errors seem to be often associated to MySQL's /tmp directory running out of space.

https://www.google.es/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=Incorrect+key+file+for+table+cloudlinux

@fplanque
I'll do another test this afternoon with a minimal 5.2.2 to 6.6.3 to see if it works. I'll also put in a request to be moved to a different server if it's possible.

@mgsolipa
In my cPanel server stats it appears to show the LVM volume for mySQL at 12% but I'll include that in my next reply to them.

Last night they requested a copy of the db and the 6.6.3 installer, so they could run a test upgrade at another location, presumably on another server. I'm going to wait until I hear from them regarding the result.

I finally had a little time to do that last test. I created a blank db, installed 5.2.2-stable with the sample blog content.

Without logging in, I deleted the files, unzipped the 6.6.3-stable installer and ran the upgrade. I got the exact same error.

So I think we can agree there is definitely an issue with the particular sever or particular setup (DB version?) your host is using.

Are they using MariaDB maybe? I would say they should upgrade to the latest version. Looks like a bug in MySQL or MariaDB.

Yeah it does seem to be the db server. It's MariaDB. They have the ticket 'on hold' now rather than 'in progress' so I'm not sure what that means. I'll see how it's resolved and then consider moving to a different host.

Rule #2 when starting with a new host: Always pay monthly until you're 100% sure of the host, and only then consider paying yearly.

jj.

Same issue for me when i try to update my 5.2.1-stable to the latest version.

I'm using mariaDB (up to date) on a debian 8 (up to date too).

I found no way to reproduce this in my local server.

@amph37 did you upgrade your site anytime before this attempt?

If there is 2 of you, both using MariaDB I continue to suspect a bug in MariaDB. It would help if you could provide the exact version number of the MariaDB install where you observe the problem.

10.0.21-MariaDB @ Hostwithlove's Orlando, FLA server

On a debian 8 (VPS OVH)

root:~# apt-show-versions mariadb-server
mariadb-server:all/unknown 10.0.20-0+deb8u1 uptodate

root@vps196058:~# apt-show-versions mariadb-client
mariadb-client:all/jessie 10.0.20-0+deb8u1 uptodate

The upgrade process is OK if i run it on my PC using WAMP

OK, we will try to work around the MariaDB issue.

In the meantime we recommend you export to MySQL for upgrading and reimport back to MariaDB.

It may also be possible to drop the index that creates the problem before upgrade and recreate it after upgrade...

@mgsolipa when you say you could not reproduce, did you try with MariaDB or with MySQL?

@fplanque when I wrote that comment I had tried with MariaDB v5.5.44 in Ubuntu. I upgraded to v10.0.21 and got exactly the same Incorrect key file for table error reported here.

I isolated the issue to this block of /install/_functions_evoupgrade.php (line 5428):

if( $old_db_version < 11360 )
    { // part 18.e trunk aka 7th part of "i7"

        task_begin( 'Upgrade table posts... ' );
        $DB->query( 'ALTER TABLE T_items__item
            CHANGE post_ptyp_ID post_ityp_ID int(10) unsigned NOT NULL DEFAULT 1,
            DROP INDEX post_ptyp_ID ,
            ADD INDEX post_ityp_ID ( post_ityp_ID )' );
        task_end();

so I separated that SQL into three different queries like these:

    if( $old_db_version < 11360 )
    { // part 18.e trunk aka 7th part of "i7"

        task_begin( 'Upgrade table posts... ' );
        $DB->query( 'ALTER TABLE T_items__item
            CHANGE post_ptyp_ID post_ityp_ID int(10) unsigned NOT NULL DEFAULT 1');
        $DB->query( 'ALTER TABLE T_items__item
            DROP INDEX post_ptyp_ID');
        $DB->query( 'ALTER TABLE T_items__item   
            ADD INDEX post_ityp_ID ( post_ityp_ID )' );
        task_end();

No idea why the original query fails (even executing it alone in phpMyAdmin), but after that change, the upgrade finished successfully, the field was renamed, the old index deleted and the new one created as supposed.

I think @jibberjab and @amph37 may apply this patch in order to finish their upgrades.

Regards!

@mgsolipa Great! Thanks!

We'll put this into v6.6.4.

i will try this fix soon. Thanks