I'm getting this unrecoverable error when upgrading from 6.20 to 7.0:
An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: http://[site]/update.php?id=533&op=do StatusText: Service unavailable (with message) ResponseText: PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table '[db].block_node_type' doesn't exist: SELECT module, delta, type FROM {block_node_type}; Array ( ) in node_block_list_alter() (line 2374 of /home/rokur/[site]/modules/node/node.module).
My site is quite standard Drupal 6.20, except for these modules: AddToAny 6.x-3.3, BUEditor 6.x-2.2, Facebook Like Button, Mollom 6.x-1.15, Pathauto 6.x-1.5, Token 6.x-1.15, Archive 6.x-1.4, Google Analytics 6.x-3.2, and an additional theme Pixture Reloaded 6.x-3.2.
I also try to keep optional core modules to a minimum: Color, Comment, Contact, Database Logging, Forum, Help, Locale, Menu, OpenID, Path, PHP Filter, Ping, Profile, Search, Statistics, Syslog, Taxonomy, Throttle, Tracker, Trigger, Update Status and Upload.
The site status report says that everything is OK. The site is more than three years old, and has therefore been updated quite a few times. But I always try to do it step-by-step, not skipping any minor or major upgrade.
I disabled the additional modules and the additional theme, before upgrading. I also changed the default language from additional Faroese to English, just to be as close to standard as possible.
When upgrading, I chose to keep the files and sites folders entirely (including the original 6.20 sites/default/settings.php file), but replaced everything else by deleting and then uploading everything Drupal 7.0 except the sites folder.
The error pops up during the upgrade process, after "Completed 72 of 129. Updating taxonomy module".
I've tried ignoring it and then somehow getting past it via WSOD and other error messages. But it seems to be impossible to complete the upgrade.
MySQL is 5.1.39 and PHP 5.2.15 (FastCGI). Existing tables are MyISAM, but the upgrade creates InnoDB tables.
I try to follow UPGRADE.txt as close as possible, see attached UPGRADE-NOTES.txt
Any ideas ?
| Comment | File | Size | Author |
|---|---|---|---|
| UPGRADE-NOTES.txt | 4.14 KB | morshus |
Comments
Comment #1
morshus commentedRight, I've now tried upgrading a standard 6.20 installation, with the same core modules enabled as on my real site, in same test-environment as when doing the test-upgrade before.
I noticed that all tables are MyISAM in the 6.20 installation, and that table 'block_node_type' doesn't exist before upgrading to 7.0.
Created a few test posts, and uploaded an attachment in order to create the 'files' directory.
The update ran smooth, with these returned messages
So I guess that there is nothing critically wrong with my LAMP environment.
The table types are now a mixture of MyISAM and InnoDB. Don't know if that is a problem.
'block_node_type' now exists.
I will now try to do this once more, now with the additional modules and themes that my real site uses, to see if they are the problem.
Comment #2
morshus commentedRight, I've been able to recreate 78 tables in the test-db, compared to 81 tables in my real site.
I had to activate and deactivate core modules 'Blog API', 'Book' and 'Poll', in order to recreate those additional tables.
But I don't know where the tables 'client', 'client_system' and 'sequence come from, so I just ignored them for now.
Using the same procedure described in my original UPGRADE-NOTES.txt here above, I ended up with a new but quite similar unrecoverable error:
To cut things short, this is a very basic installation:
Drupal 6.20 with additional modules AddToAny 6.x-3.3, BUEditor 6.x-2.2, Facebook Like Button, Mollom 6.x-1.15, Pathauto 6.x-1.5, Token 6.x-1.15, Archive 6.x-1.4, Google Analytics 6.x-3.2, and an additional theme Pixture Reloaded 6.x-3.2.
Additional modules deactivated before upgrade, and additional theme deactivated and deleted.
Only one test blog post and one test story created.
The upgrade ran fine without the additional modules, but not now with them added, enabled and disabled again.
Comment #3
kars-t commentedDear fellow Drupal enthusiasts,
this issue is now lasting for a very long time in the issue queue and was unfortunately never solved. As Drupal is a open source project everyone is helping on voluntary basis. So that this is was not solved is nothing personal and means no harm. But perhaps no one had time to deal with this issue, maybe it is too complex or did not pose the problem comprehensible.
But this issue is not the only one. There are thousands of issues on Drupal.org that have never been worked on or could not be processed. This means that we are building a wave that is unmanageable and just a problem for the Drupal project as a whole. Please help us keep the issue queue smaller and more manageable.
Please read again, "Making an issue report" and see if you can improve the issue. Test the problem with the current Core and modules. Maybe the problem doesn't exist anymore, is a duplicate or has even been solved within this issue but never closed.
Help can also be found for it on IRC and in the user groups.
In order this issue no longer remains, I put this issue to "fixed".
If there is new information, please re-open the issue.
Comment #5
mattwmc commentedI have the same issues, but more. No fix?
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'xxxxxxl.block_node_type' doesn't exist: SELECT module, delta, type FROM {block_node_type}; Array ( ) in node_block_list_alter() (line 2521 of /home/xxx/public_html/modules/node/node.module).The following updates returned messagesComment #6
chunty commentedDid you try just creating the table:
CREATE TABLE `block_node_type` (
`module` varchar(64) NOT NULL COMMENT 'The block’s origin module, from block.module.',
`delta` varchar(32) NOT NULL COMMENT 'The block’s unique delta within module, from block.delta.',
`type` varchar(32) NOT NULL COMMENT 'The machine-readable name of this type from node_type.type.',
PRIMARY KEY (`module`,`delta`,`type`),
KEY `type` (`type`)
)
Comment #7
kropotkinthinks commentedI had this issue while upgrading from Drupal 6.38. The issue was one of data corruption. My data has come from Drupal 5 through Drupal 6, and so some of the data has become corrupt.
In my case, the problem was in the users table and the blocks table (in D6). I had users with NULL passwords, and blocks with NULL titles. I removed the users with NULL passwords and turned the block titles from NULL to the empty string, and that worked.
I found the affected rows in the error messages produced by update.php (in my case, invoked through drush), examined the data which generated the errors, and that helped me isolate what the problem is. I can't say for sure that this is your problem, but it was what was blocking me from making the updates. When the NULL values were removed, the update proceeded normally, and all of the tables were created.
What appears to happen is that the update process comes across an error, and then only partially completes. This is not apparent from the report at the end of the update process.
If you have users with NULL passwords, you can select them with:
Select * from users where pass is NULL;Then take those uids and insert them into the user delete URL to delete the user.
As for the blocks table, I issued the following SQL statement:
update blocks set title = '' where title is null;in MySQL.