An AJAX HTTP error occurred during upgrade

Same here. Upgrade 6.19 to 7.0-beta1. Failed 7006 4 times.
Had to add field_data_comment_body.comment_body_value and field_data_comment_body.comment_body_format manually to get the update (7006) to take. Used comment.comment and comment.format respectively as guides for field defs. Altogether had to run update.php 4 or 5 times. Crossing fingers.

Tagging, so we get some people to look into this.

Also changing component since this has to do with the upgrade path, not the ajax system.

Any other details you folks can provide would be wonderful!

Hm. Does #895140: _system_rebuild_module_data() and _system_rebuild_theme_data() will choose 6.x versions of modules and themes over 7.x versions help with that at all, by any chance..?

During upgrade from 6.19 to 7 beta 1 I have same problem as #2.
This is the error on the website.

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'mcrickma_drupal.block_node_type' doesn't exist: SELECT module, delta, type FROM {block_node_type}; Array ( )  in node_block_list_alter() (line 2339 of /home/mcrickma/public_html/modules/node/node.module).

FYI: When I ran the update.php I was given the access denied page and had to set the $update_free_access = TRUE; in the settings.php

Charlie

I got the upgrade to work I had to completely remove the version 6 cck directory for it to work. I did receive this info on the completion screen.

Update #7006

    * Failed: PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'comment_body_value' in 'field list': INSERT INTO {field_data_comment_body} (entity_id, comment_body_value, comment_body_format, bundle, etid, deleted, language, delta) SELECT c.cid AS entity_id, c.comment AS comment_body_value, c.format AS comment_body_format, 'comment_node_page' AS bundle, 1 AS etid, 0 AS deleted, 'und' AS language, 0 AS delta FROM {comment} c INNER JOIN {node} n ON c.nid = n.nid AND n.type = :type; Array ( [:type] => page ) in comment_update_7006() (line 311 of /home/mcrickma/public_html/modules/comment/comment.install).

But I no longer get the error on the website.

Also I didn't do a restore of the site I simply removed the cck directory and re ran the update.php.

Charlie

I had to manually added the two fields (comment_body_value & comment_body_format) to the (field_data_comment_body) table to get the upgrade to complete without errors.

ALTER TABLE `field_data_comment_body` ADD `comment_body_value` LONGTEXT CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL AFTER `delta` ,
ADD `comment_body_format` INT( 10 ) NULL DEFAULT NULL AFTER `comment_body_value` 

K, well. Enough people are reporting this issue that I think we need to escalate it to critical.

Thanks for testing! Let's get to the bottom of this. :)

I ran into the issue as well. Update fails on #7002 and #7007. I tried on linux, latest apache, mysql, php 5.3 and wamp with apache 2.2.11, mysql 5.1.36 and php 5.3 and 5.2.11, php and apache logs are completely empty. I tried both 7.0-beta1 and latest dev version, no luck. Below are errors from update result

Update #7002
Failed: PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'module' in 'where clause': SELECT 1 AS expression FROM {role_permission} role_permission WHERE ( (rid = :db_condition_placeholder_0) AND (permission = :db_condition_placeholder_1) AND (module = :db_condition_placeholder_2) ) FOR UPDATE; Array ( [:db_condition_placeholder_0] => 2 [:db_condition_placeholder_1] => access user contact forms [:db_condition_placeholder_2] => contact ) in contact_update_7002() (line 128 of C:\wamp\www\modules\contact\contact.install).

Update #7007
Failed: PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '4-administer recommender' for key 'PRIMARY': INSERT INTO {role_permission} (rid, permission) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1), (:db_insert_placeholder_2, :db_insert_placeholder_3), (:db_insert_placeholder_4, :db_insert_placeholder_5), (:db_insert_placeholder_6, :db_insert_placeholder_7), (:db_insert_placeholder_8, :db_insert_placeholder_9), (:db_insert_placeholder_10, :db_insert_placeholder_11), (:db_insert_placeholder_12, :db_insert_placeholder_13), (:db_insert_placeholder_14, :db_insert_placeholder_15), (:db_insert_placeholder_16, :db_insert_placeholder_17), (:db_insert_placeholder_18, :db_insert_placeholder_19), (:db_insert_placeholder_20, :db_insert_placeholder_21), (:db_insert_placeholder_22, :db_insert_placeholder_23), (:db_insert_placeholder_24, :db_insert_placeholder_25), (:db_insert_placeholder_26, :db_insert_placeholder_27), (:db_insert_placeholder_28, :db_insert_placeholder_29), (:db_insert_placeholder_30, :db_insert_placeholder_31), (:db_insert_placeholder_32, :db_insert_placeholder_33), (:db_insert_placeholder_34, :db_insert_placeholder_35), (:db_insert_placeholder_36, :db_insert_placeholder_37), (:db_insert_placeholder_38, :db_insert_placeholder_39), (:db_insert_placeholder_40, :db_insert_placeholder_41), (:db_insert_placeholder_42, :db_insert_placeholder_43), (:db_insert_placeholder_44, :db_insert_placeholder_45), (:db_insert_placeholder_46, :db_insert_placeholder_47), (:db_insert_placeholder_48, :db_insert_placeholder_49), (:db_insert_placeholder_50, :db_insert_placeholder_51), (:db_insert_placeholder_52, :db_insert_placeholder_53), (:db_insert_placeholder_54, :db_insert_placeholder_55), (:db_insert_placeholder_56, :db_insert_placeholder_57), (:db_insert_placeholder_58, :db_insert_placeholder_59), (:db_insert_placeholder_60, :db_insert_placeholder_61), (:db_insert_placeholder_62, :db_insert_placeholder_63), (:db_insert_placeholder_64, :db_insert_placeholder_65), (:db_insert_placeholder_66, :db_insert_placeholder_67), (:db_insert_placeholder_68, :db_insert_placeholder_69), (:db_insert_placeholder_70, :db_insert_placeholder_71), (:db_insert_placeholder_72, :db_insert_placeholder_73), (:db_insert_placeholder_74, :db_insert_placeholder_75), (:db_insert_placeholder_76, :db_insert_placeholder_77), (:db_insert_placeholder_78, :db_insert_placeholder_79), (:db_insert_placeholder_80, :db_insert_placeholder_81), (:db_insert_placeholder_82, :db_insert_placeholder_83), (:db_insert_placeholder_84, :db_insert_placeholder_85), (:db_insert_placeholder_86, :db_insert_placeholder_87), (:db_insert_placeholder_88, :db_insert_placeholder_89), (:db_insert_placeholder_90, :db_insert_placeholder_91), (:db_insert_placeholder_92, :db_insert_placeholder_93), (:db_insert_placeholder_94, :db_insert_placeholder_95), (:db_insert_placeholder_96, :db_insert_placeholder_97), (:db_insert_placeholder_98, :db_insert_placeholder_99), (:db_insert_placeholder_100, :db_insert_placeholder_101), 
.
.
.
in system_update_7007() (line 1883 of C:\wamp\www\modules\system\system.install).

Huh. It looks like the sidebar block only picks up issues assigned to "7.x-dev", so re-assigning. I'll make a separate bug report about that.

Argus - you can't recover an installation where the upgrade failed, or not easily. If you have you have a backup, please try again with no Drupal 6 modules around.

varontron, mrickman, spongecat - please post here whether you have any D6 modules in your Drupal install, especially CCK.

I think this is a duplicate of #895140: _system_rebuild_module_data() and _system_rebuild_theme_data() will choose 6.x versions of modules and themes over 7.x versions but would be good to confirm that either way before closing.

If anyone is getting this without having D6 modules around, we might need a dump of the D6 database to test with.

Ok, #895140: _system_rebuild_module_data() and _system_rebuild_theme_data() will choose 6.x versions of modules and themes over 7.x versions has now been committed.

Could folks in this issue please try your upgrades again from scratch, using the latest, bleeding-edge code in CVS? (and/or wait ~12 hours for the new 7.x-dev.tar.gz file to be generated.) I suspect it should now be fixed.

catch - I have a lots of modules, including cck. All were disabled though and sites/all and sites/default/files dirs were emptied completely. I tested it on local copy of production site.

I ran into this ajax http error with Beta1. Tried again just now with a fresh checkout and did not see the error anymore so seems to be fixed indeed. Is 1 succesful test enough to mark this fixed then?

Update #7007
Failed: PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '4-administer recommender' for key 'PRIMARY': INSERT INTO {role_permission} (rid, permission) VALUES (...)

That's probably the culprit.

But contact_update_7002() should also depend on the user_update_7007().

Welll, I still get reports that update 7006 still needs doing but that one keeps failing

I'm concerned that "critical" and "postponed" is a bad combination now, because "postponed" issues don't show up in the "X Critical issues" contributor link, so they don't get nearly enough attention, which isn't good if it's truly "critical".

@DamZ, @yoroy: can you please make new issues for #20 and #21, if that's still needed.

What else is needed to close this?

For everyone who reported the bugs, thank you, and please, please, keep doing so, but I think it makes sense to close this issue, because:

1) It's not 1 issue. It's at least 3 issues.

a) The originally reported issue is node_update_7006() calling text_summary(), but text_summary() not existing. I'm unable to reproduce this with either a 6.19 to 7.0-beta1 upgrade or a 6.19 to HEAD upgrade. And code-wise, there doesn't appear to be anything identifiably wrong. node_update_dependencies() lists system_update_7049() as a dependency, and that runs after system_update_7027(), which enables text.module, so it shouldn't be possible to have text_summary() not existing when node_update_7006() is running. Unless D6 CCK's text.module is being loaded instead of the D7 text.module. But now with #295255: Clean-up the upgrade path: UPGRADE.txt just landing, our instructions clearly say to remove D6 modules for which there are new D7 modules.

b) #10 is comment_update_7006() querying 'comment_body_value' and 'comment_body_format' columns of {field_data_comment_body}, but those columns don't exist. But comment_update_7005() creates the comment_body field, including its columns, unless again, there's D6 CCK modules lying around and causing conflict.

c) #14 is contact_update_7002() and system_update_7007() failures that don't appear to have anything to do with CCK. I haven't put much time into trying to reproduce these. @spongecat: if you're still seeing those, please open a new issue with steps on how to reproduce this, like "install Drupal 6.19, enable modules x, y, z, add roles a, b, c, and users foo and bar, then upgrade to Drupal 7, ...".

2) There's some evidence (#19) that HEAD has fewer of these problems than beta1.

3) Having this issue be open but postponed hasn't been useful in getting further information.

So, again, closing this issue, and encouraging new issues to be opened, specific to the actual update function failing, if anyone is finding problems with HEAD, using its new and improved UPGRADE.txt instructions.

Oh, and as per #17, in addition to better UPGRADE.txt instructions, HEAD is now better about prioritizing D7 modules over D6 modules that may be lying around.