I get a long list of errors when trying to upgrade to 6.4.
What I did:

  • tried to update contirb modules to there most recent version
  • Installed a backup (D-5.10) on a development box => running fine
  • deactivated ALL custom modules
  • uninstalled "update_status" module
  • deleted all files but those in "files" and "sites"
  • extracted D-6.4 tar-archive
  • adjusted ownership of extracted files
  • started update.php from administer/modules
  • GOT A LIST OF ERRORS

The part marked in red contains e.g.

  • user warning: Table 'cache_form' already exists ...
  • user warning: Table 'menu_router' already exists ...
  • user warning: Table 'menu_links' already exists ...
  • user warning: Table 'menu_custom' already exists ...
  • user warning: Duplicate entry 'navigation' for key 1 query: system_update_6021 ... system.install on line 1739
  • user warning: Duplicate entry 'primary-links' for key 1 ... system.install on line 1852
  • user warning: Duplicate entry 'secondary-links' for key 1 ... system.install on line 1870
  • user warning: Table 'upload' already exists ...
  • user warning: Duplicate column name 'nid' ...
  • user warning: Duplicate key name 'nid' ...
  • user warning: Multiple primary key defined ...
  • AND 10 MORE ERROR MESSAGES

Below this red marked block there is a list of executed queries.
Some of them report errors as well:

  • Update #6015
    Failed: CREATE TABLE {cache_form} ...
    I checked this and found: The table exists and looks as it should!
  • Update #6020
    Failed: CREATE TABLE {menu_router} ...
    Checked and: Tables exists, holds a bunch of columns and seems to be OK
  • Failed: CREATE TABLE {menu_links} ...
    Checked => seems to be OK
  • Update #6021
    Failed: CREATE TABLE {menu_custom} ...
    Checked => seems to be OK
  • Failed: UPDATE {menu_custom} SET menu_name = 'primary-links' ...
    Checked => was already done
  • Update #6022
    Failed: ALTER TABLE {file_revisions} RENAME TO {upload}
    Checked => Table 'upload' already existed, so RENAME failed
  • 4 more errors about table 'upload'
  • Update #6030
    Failed: ALTER TABLE {actions} RENAME TO {actions_old_contrib}
    Failed: CREATE TABLE {actions} ...
    The RENAME again failed because the destination table already existed.
    BUT: As a consequence table actions could not be recreated.
    So it remains with a wrong structure!
  • 4 more messages

It looks that (parts?) of the upgrade are done twice. In most cases that only results in some error message.
But in minimum one case it harms the structure of a table (e.g. 'action').

What is going wrong?
Did I made an error when upgrading to 6.4 ?

Comments

schildi’s picture

schildi commented

Additional remark:

When doing a page reload on the page showing the errors described above, drupal responds with

warning: array_pop(): The argument should be an array in /.../drupal/update.php on line 315.
The update process was aborted prematurely while running update # in .module. All errors have been logged. ...

ainigma32’s picture

ainigma32 commented
Status: Active » Postponed (maintainer needs more info)

@schildi: Are you still experiencing these problems? Or were you able to succefully update in the mean time?

- Arie

schildi’s picture

schildi commented

In the last months I tried several times to migrate to D6 without success. So I decided to wait until next year.

Sorry ...

ainigma32’s picture

ainigma32 commented
Status: Postponed (maintainer needs more info) » Postponed

Hey no need to say sorry. It's a free world right?

FWIW I don't see any obvious mistakes on your part so I don't know why you get all these errors.
You could try to list the tables before you try the update. If the tables that the update tries to create already exist we may have a bug on our hands.

I'll set this issue to postponed for now. Please post back any follow up.

- Arie

ainigma32’s picture

ainigma32 commented

@schildi: Did you ever manage to upgrade?

- Arie

pnelson’s picture

pnelson commented

Upgrading from 5.9 to 6.9 and have these database errors

Table already exists:
cache_block
cache_form
menu_router
menu_links
upload
actions_old_contrib
actions
actions_aid
search_node_links

Before running upgrade I turned off and uninstalled all contributor modules.

I also had to turn on content module and remove "locked" column from table content_node_field to get an error free update.

leo.ruffini’s picture

leo.ruffini commented
Version: 6.4 » 6.10
Priority: Normal » Critical
Status: Postponed » Active

Hi,

similar database problems here upgrading from 5.16 to 6.10. I change the priority it to critical, as I can't upgrade.

Failed: CREATE TABLE {cache_form}
Failed: CREATE TABLE {menu_router}
Failed: CREATE TABLE {menu_links}
Failed: CREATE TABLE {menu_custom}
Failed: UPDATE {menu_custom}

Failed: ALTER TABLE {file_revisions} RENAME TO {upload}
Failed: ALTER TABLE {upload} ADD `nid` INT unsigned NOT NULL DEFAULT 0
Failed: ALTER TABLE {upload} ADD INDEX nid (nid)
Failed: ALTER TABLE {upload} ADD PRIMARY KEY (vid, fid)
Failed: ALTER TABLE {upload} ADD INDEX fid (fid)

Failed: CREATE TABLE {actions_aid}
Failed: CREATE TABLE {search_node_links}
Failed: ALTER TABLE {upload}

In addition, the site menus look completely broken (Navigation menu has vanished and Primary links items are repeated four times) and I get this error message:
# recoverable fatal error: Object of class stdClass could not be converted to string in /var/www/internal/sites/all/themes/garland/page.tpl.php on line 3.

Any help much appreciated. Really.

Leo

vm’s picture

vm commented
Component: install system » update system
leo.ruffini’s picture

leo.ruffini commented

Hi,

can somebody please lend me a hand on this? I'm really stuck on it, as there is no way I can move to D6 with all these errors...

Leo

avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented

Did anybody try to make the update in multiple steps? I mean to update to the latest Drupal 5 version, then to the first Drupal 6 version, and finally to the last Drupal 6 version.

avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented
Title: Database errors when upgrading 5.10 => 6.4 » Database errors when upgrading from Drupal 5 to Drupal 6
Anonymous’s picture

Anonymous (not verified) commented

I've recently updated from 4.7.3 to 6.10 doing the following process. I'm in the process of moving hosting services and decided to do this upgrade all at once. In the process I received no errors on update. I did receive one error on importing the data because the sequences table contained multiple entries for the menu table. I removed the one with the lower value and continued.

1) export data from existing service
2) install the current 4.7.10 on the new server (no contrib).
3) import the data into the new DB (mysql 5.0.51a - utf8-generic-ci).
4) execute the upgrade.php script.
5) install Drupal 5.0 (no contrib).
6) switch site to use Drupal 5.0
7) execute the update.php
8) install Drupal 5.16
9) switch site to use Drupal 5.10
10) execute the update.php
11) install Drupal 6.10 (no contrib).
12) switch site to use Drupal 6.10.
13) execute the update.php
14) install the contrib modules
15) execute the update.php script

The main point here is that no contrib module or theme code existed during the upgrade from 4.7.3 to 6.10. The absence of the module code by default causes them to be deactivated so there is nothing to remove from admin/build/modules. This helps keep the data intact for the modules that remove data during the deactivate process. The whole process took about 45 minutes and the site was up and working. I installed Drupal based on its versions into /var/www/drupal as webadmin user. So I have the following directories:

/var/www/drupal/drupal47/drupal-4.7.3
/var/www/drupal/drupal47/drupal-4.7.10
/var/www/drupal/druapl47/sites
/var/www/drupal/drupal5/drupal-5.0
/var/www/drupal/drupal5/drupal-5.16
/var/www/drupal/drupal5/sites
/var/www/drupal/drupal6/drupal-6.10
/var/www/drupal/drupal6/sites

Notice the sites directory in the parent directory for the Drupal root directory. Using drupal-4.7 as an example I 

mv drupal-4.7.3/sites .
cd drupal-4.7.3
ln -s ../sites sites
cd drupal-4.7.10
rm -rf sites
ln -s ../sites sites

This allows for one instance of the sites directory for each update making updating the site easier.

To switch the site to use a different Drupal version I simply cd <DocumentRoot>/..; rm htdocs; ln -s /var/drupal/drupal47/drupal-4.7.10 htdocs;. Replace the <DocumentRoot> with your sites diretory and replace htdocs with whatever you call it. I use symlinks for the htdocs to make it easier to upgrade multiple sites singularly.

I hope this helps you upgrade.

leo.ruffini’s picture

leo.ruffini commented

Thank you Earnie,

I tried, but without success. I'm getting the same errors described in the first post of this issue.
I deleted all contributed modules and themes and then tried to upgrade, but it didn't work.
I tried to upgrade from 5.16 to 6.1, from 5.10 to 6.10, and nothing...

What is going wrong?

Anonymous’s picture

Anonymous (not verified) commented

A table existing already that shouldn't exist would make me question how the table was there to begin with.

A failure to create a table would make me question the permission of the DB user. If the DB user has permission then I would question Apache's mod_security module settings.

leo.ruffini’s picture

leo.ruffini commented

Thanks a lot Earnie, I will follow those hints.
Anyway, isn't a big coincidence that two users happen to have the same update problems with the same tables..?

Another question that comes to my mind is why I don't have any problem when doing a D5 minor upgrade. Is it because the D5 to D6 major upgrades require less strict Apache or mysql settings?

Leo

jpl-2’s picture

jpl-2 commented

I have a plausible explanation for these errors. I got them as well during a two-phase D5->D6 migration. The first phase consisted in porting all functionality to D6 using a new (clean) database. After ascertaining that it works ok with test data, the real site's D5 dump was imported into the D6 database and then treated with update.php to migrate content. However, during that second phase, I forgot to drop all the existing D6 tables before importing the old D5 dump, wrongly assuming that simply importing the dump would somehow "replace" the entire contents of the database. So it was no wonder that update.php was messed up having to work on a database containing an unholy mix of D5 and D6 tables.

Perhaps Drupal could be a little more helpful validating preconditions for an update (first check whether the initial state makes sense before even trying to run an update and raise alarm early).

The problem described in comment #1 is an independent one, and I can confirm that it occurs when reloading the update.php results page. I guess you shouldn't do it or it should be handled better.

The problem with table actions_aid is an independent genuine one when upgrading from 5.x-2.6 actions module. See http://drupal.org/node/1003448

schildi’s picture

schildi commented

My assumption is still that each table is dropped before populated with values when restoring a mysql dump.
Having a look at a dump shows the following sequence of sql commands for each table:

--
-- Table structure for table `accesslog`
--

DROP TABLE IF EXISTS `accesslog`;
CREATE TABLE `accesslog` (
  `aid` int(11) NOT NULL auto_increment,
  `sid` varchar(64) NOT NULL default '',
  `title` varchar(255) default NULL,
  `path` varchar(255) default NULL,
  `url` text,
  `hostname` varchar(128) default NULL,
  `uid` int(10) unsigned default '0',
  `timer` int(10) unsigned NOT NULL default '0',
  `timestamp` int(10) unsigned NOT NULL default '0',
  PRIMARY KEY  (`aid`),
  KEY `accesslog_timestamp` (`timestamp`),
  KEY `uid` (`uid`)
) ENGINE=MyISAM AUTO_INCREMENT=3413015 DEFAULT CHARSET=utf8;

--
-- Dumping data for table `accesslog`
--

LOCK TABLES `accesslog` WRITE;
/*!40000 ALTER TABLE `accesslog` DISABLE KEYS */;
INSERT INTO `accesslog` VALUES (3392891,'6upnc1jlkppnkrlrepuh9jdud3','Biblio','biblio/author/5361'
jpl-2’s picture

jpl-2 commented

You're right that each table which is re-created is dropped. But there are some tables in D6 that did not exist at all in D5. Precisely these tables are not dropped by the mysql import, and the update script for D5->D6 doesn't expect them to exist - hence the errors.

schildi’s picture

schildi commented

now I start to see what you mean.
Of course D6 tables which not existed before in D5 are not dropped by the import. And these new tables might by essential for D6 to work - we can't know about. So I assume these tables must not be dropped at all. From my point of view it's the responsibility of the update process to take care about those things.

jpl-2’s picture

jpl-2 commented

In the scenario which I described, which concerns importing a D5 database dump into a pre-existing but "empty" D6 database, it is clear to me that the D6 tables *must* be dropped manually. Of course, the easiest way to do it is to just drop all tables, and then import the dump.

Essentially, you're supposed to run update.php on your D5 database, having replaced the code of all core and contrib modules. You're not supposed to run update.php on a database which contains some strange mix of D5 tables from the original dump and some D6 tables from an "empty shell" database. In fact, the mere existence of such a non-empty target D6 database is not covered by the official update scenario.

vm’s picture

vm commented
Version: 6.10 » 6.20
Component: update system » database update system
Priority: Critical » Normal
Status: Active » Closed (cannot reproduce)

Queue clean up.

I'm not seeing this when upgrading a Drupal 5.23 site to Drupal 6.20 site. When updating drupal update to the latest version of Drupal 5.x before moving to Drupal 6.x

If this issue is still relevent with Drupal 5.23 being upgraded to 6.20, feel free to reopen.

Il_Bruco’s picture

Il_Bruco commented

Reopen: I'm having those database issues when upgrading from 5.23 to 6.20.

minhtao’s picture

minhtao commented

Hi

I had the same error.
I tried to migrate from drupal 5 (D5) to a drupal 6 (D6) and while testing the procedure I had issues with tables already there.

In my case, what happened is that I tried to migrate a first time, then I rolled back with a D5 dump backup done at the beginning of the process. What happened is that those two databases ended up being "merged" with tables from D6 (like menu_router and menu_links) in what I though was a plain D5 database. It cost me a whole day to figure that out... (it was late, I was tired, it was Friday...).

To solve that problem: I had to drop all the tables from the database (drop database, then create create database with the same name), re-install the D5 database and start from the beginning.

I don't know if your upgrade involved a rollback that you forgot to mentioned. I just though that posting that message could help someone anyway.

Regards

vm’s picture

vm commented
Status: Closed (cannot reproduce) » Active
Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Closed (works as designed)

Tables that already exist isn't an issue when the table schema is valid. Note that "Warning" is the programmed message of the install process and "Failed" is the error from the database engine. Just because the database failed to create a table that already exists during the update.php process doesn't mean that there is something to panic about. You just need to ensure that the table is usable by the system. If you see failures later that a column is missing then you know for sure that the upgrade did not happen appropriately.

jpl-2’s picture

jpl-2 commented

Actually, as a side remark, tables that unexpectedly exist should be considered a problem even if the table schema seems valid. They should prevent upgrading or at least demand the user's consent before upgrading. That's because the meanings of attributes in a table may have changed subtly, thus making data migration required (which may or may not have occurred if the table is surprisingly there).