(Marking this as "normal" priority on the assumption that it isn't happening on everyone else's upgrades—I can see it is happening with upgrades other than mine but presumably D7 would have never gotten to RC4 if upgrading wasn't possible)

Similar to #517742: Upgrade failing if blocked_ips doesn't exist but as you can see, someone else got slapped for assuming that the same symptom meant the same problem. So opening a new issue and if it's a duplicate I'll let someone else say so.

Also described in #1012382: Tables and columns missing during D6->D7rc4 upgrade, the difference being that since then I restored from backup and did a lot of deinstallation (not just deactivation( of modules on the assumption that some module code might have interfered.

So, details: PHP 5.2.15, and have attempted with 5.3.4 as well. OS is Debian GNU/Linux 5.0.7 (lenny). Mysql is 5.0.51a, PDO_mysql 5.0.51a. PHP memory limits: 128MB (5.2.15) and 90MB (5.3.4). My user has all db permissions. Tables are MyISAM.

I followed the instructions in UPGRADE.txt under "MAJOR VERSION UPGRADE". I've retraced my steps a few times, so I'm pretty clear that I've followed the instructions to the letter, with the possible exception of #9: it's possible that there are old modules which were deactivated and which had the files removed but were not uninstalled. I've gone through to double-check this but there could still be something I missed.

At step 13, I start at /update.php, first click the "Continue" button then the "Apply pending updates" button. This leads me to:

An unrecoverable error has occurred. You can find the error message below. It is advised to copy it to the clipboard for reference.
Please continue to the error page

An AJAX HTTP request terminated abnormally. Debugging information follows. Path: http://[MYSITE].com/update.php?id=60&op=do ReadyState: 4

I click through to the error page, which reveals:

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table '[MYDBNAME].block_custom' doesn't exist: SELECT bid, info FROM {block_custom} ORDER BY info; Array ( ) in block_block_info() (line 209 of /[MYPATH]/modules/block/block.module).

I check the database, and sure enough, there is no such table as block_custom. Looking at a fresh D7 install I see such a table, and the table is empty. So I figure that this must be a glitch, and copy the table from the fresh D7 install into the DB of the site I'm trying to upgrade.

Start over with update.php, this time the complaint is that "block" doesn't exist. Indeed, there is a table called "blocks" but no one called "block". Looking at my clean install, it looks like there is a table called "block" which is identical to "blocks" on my D6 install. So I rename the table "block" and try again.

Next it's a different error:

The update process was aborted prematurely while running update #7000 in user.module. All errors have been logged. You may need to check the watchdog database table manually

So I check watchdog. This time it's a column that's missing, not a table: node_type.disabled.

I correct this manually and continue ad nauseum. It is clear that update.php is not actually updating the table schema before trying to change the data in the tables.

If I were the only one experiencing this I'd figure the problem was the loose nut behind the keyboard.

Comments

smscotten’s picture

smscotten commented
Title: Upgrade from 6.20 to 7-rc4 » Upgrade from 6.20 to 7-rc4 fails on missing and non-updated tables.

Editing title because I'm an idiot and didn't finish typing the title before posting

jpoesen’s picture

jpoesen commented

I have the exact same problem: the upgrade process hangs on D6.20 -> D7RC4, though I'm using 'drush sup' instead of the manual process.

cafuego’s picture

cafuego commented
Version: 7.x-dev » 7.0-rc4
Priority: Critical » Normal

Yup, same problems here. Running it via aegir, but the same PDOExceptions were logged when I attempted the upgrade, as well as:

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'ccaegirmauvete_1.profile_field' doesn't exist: SELECT DISTINCT(category) FROM {profile_field}; Array ( ) in profile_user_categories() (There is a table called profile_fields though)

smscotten’s picture

smscotten commented
Version: 7.0-rc4 » 7.x-dev
Priority: Normal » Critical

Just tried again but with -dev version. Same result. Since clearly this is not just a localized phenomenon, upgrading to critical.

chx’s picture

chx commented
Version: 7.0-rc4 » 7.x-dev
Status: Active » Postponed (maintainer needs more info)

Once again we are seeing a) not reproducible b) non standard install reports. The original post, block_update_7002 renames boxes to block_custom. #3 is a separate issue, profile_update_7001 renames profile_fields to profile_field. I need a database dump and more precise instructions to reproduce.

Stevel’s picture

Stevel commented

I manually tried an upgrade from the latest D6 to D7-dev with profile.module enabled (with data in the profile tables), and that worked fine.

smscotten’s picture

smscotten commented

So far as I can tell, a half-dozen people have reproduced this already.

I'm preparing a database dump, but right now it's 26MB—quite a bit higher than the maximum upload size here. How would you like me to get it to you? Also, is it safe for me to simple delete the watchdog table? That seems to be a huge chunk of the db.

Regarding #3 being a separate issue because he reported a different table than I did, that doesn't follow because I named five different tables. From earlier attempts I can tell you that if I had kept on manually updating tables and rerunning the update when I was writing the report, I would have listed at least a half-dozen other tables.

This is not limited to one table or one db update. It appears to be queries running in the wrong order, populating tables with content prior to applying schema changes.

chx’s picture

chx commented

I emailed you, thanks for the dump ahead of the time and believe me -- they are separate issues. Just because there are queries running in the wrong order, that's like saying "these are all the same bug because some function is called with the wrong argument"...

smscotten’s picture

smscotten commented

Thanks for the email—I sent the db dump and hopefully that will shed some light.

OK, I'm willing to accept that #3 (and the others) might be a separate issue, but I find it unlikely that each of the 6+ (three listed in the OP) unupdated tables on my installation don't have a common cause. If they have a common cause, I suspect it would be foolish to rule out a relationship to another issue with queries run out of order specifically in update.php while doing an upgrade from d6.20 to d7-dev or rc4.

The only thing to my eyes that indicates that it's not the same thing is that cafuego's first error was not on the same table as mine. But since I uninstalled advanced_profile and don't have profile enabled, I'd never see any errors about profile no matter how many tables I manually updated to restart the upgrade process.

If cafuego were to manually make the change to the profile_field table then restart the update process, I think that would settle the question definitively. If the second run failed with another unupdated table it would be very likely to be the same thing. If the install continued as normal, or encountered some different error, that would indicate that we don't have the same issue.

I suppose I could enable the profile module and try it...

I'll reiterate: my issue is not limited to block_custom, and therefore I doubt that it is related to block_update_7002.

David_Rothstein’s picture

David_Rothstein commented
Component: install system » database update system

Moving this to the correct issue queue.

jpoesen’s picture

jpoesen commented

For what it's worth: my problem was trying to use an outdated drush to perform the site upgrade.
As soon as I updated drush to the latest 4.0 rc it all went smooth.

(Thanks to @migueljacq for putting me on the right track.)

crifi’s picture

crifi commented
Priority: Normal » Critical
Status: Postponed (maintainer needs more info) » Active

Hi, I can confirm and reproduce the issue in #1. In my upgrade of D6-20 to D7-0 I see this error message on my Debian server:

An AJAX HTTP request terminated abnormally. Debugging information follows. Path: http://mysite.com/update.php?id=26&op=do StatusText: ResponseText: ReadyState: 4

and

The update process was aborted prematurely while running update #7000 in user.module.

The system is also debian lenny (Apache 2.2.9, PHP 5.2.6 (as fcgid), MySQL 5.0.51a). For analyzation I make a dump of the database and upgrade the same database (which produces the error under debian lenny) locally on my Mac OS X (Apache 2.2.14, PHP 5.3.1 (mod-php), MySQL 5.1.44). And wow, here it could be installed without any error! So in my opinion the failure correlates with the server system...

crifi’s picture

crifi commented

In my case the failure was caused by a false setting of $base_url (with www.) while mod_rewrite in .htaccess redirects to a version without www.
Hence there was an HTTP 301 Error Code and the AJAX code could not be requested.

carlos8f’s picture

carlos8f commented

Yep, conflicting www/non-www rules will screw up a site, doesn't matter if you're upgrading or not :)

If that is the only thing going on, it's a configuration mistake and therefore we can't/won't fix.

stevenpatz’s picture

stevenpatz
he/him
commented
Priority: Critical » Normal
smscotten’s picture

smscotten commented

Interesting. Well, I've got $base_url set to http://paroxysm.com in both settings.php files (in default and in the paroxysm.com dir) but the error is reporting "www.":

An HTTP error 0 occurred. http://www.paroxysm.com/update.php?id=66&op=do

So there might be something to this on my install as well. I have .htaccess rules that force non-www. Maybe if I allow either and run it again? I'm not sure how that relates to the database errors though.

Postscript: I'm an idiot. My webserver wasn't even pointed at the right directory. I'd set it back to the d6 directory while this issue is investigated.

CompSol’s picture

CompSol commented

I've experienced the same problem and got the same error message when upgrading from 7.0 alpha6 to the 7.0 official release. However, I'm no expert and since I couldn't loose anything important, after several hours of trying to find the problem and move on, and trying to recover the site back from backups unsuccessfully (getting another different database related errors), I just did empty the database and did a new clean install, which went smooth.
But after the clean install I noticed several times while working with the site that the same error appeared - not for long though, just for a fraction of a second and disappeared itself right after - without causing any trouble. Strange a bit, it just shows up on the screen occasionally for a little while with no effect - desired page loads up after that/steps required get performed.
As I mentioned, I'm no expert so can't describe much better.

Regarding the "www/non-www" issue - the error mentioned the site with "www", while htaccess forced "non-www" url. But $base_url in settings.php I'd got set to "www" url and commented - I had not touched that before and there was the www.example.com pre-filled, not the actual site's url. I've just uncommented it and set to "non-www" site's url. Will see if that makes a difference...?

berdir’s picture

berdir
Primary language German
Location Switzerland
commented

Without reading everything, note that all those PDOExceptions and errors just happen because the update did not finish, it's quite obvious that it doesn't work then :)

The real issue here seems to be related to that ajax error mentioned in the first post.

I quick search shows that there is a number of similiar bug reports, for example #1010444: An AJAX HTTP request terminated abnormally. In the linked one, the used browser (Chrome) seems to have caused this, which browser are the people using which are able to reproduce this?

CompSol’s picture

CompSol commented

My post referred to the ajax error, showing up right after the update. I've done some google research as well, found a lot of similar reports elsewhere, however, most of them unanswered, for quite a long time, even on drupal forums.
In my case I've tried Chrome and Mozilla, no difference... the same error.

crifi’s picture

crifi commented

Maybe it would be a good idea (feature request) to give a warning message, if the base_url is configured and somebody is not upgrading over the base_url domain, so that upgrading would be more error tolerant...

crifi’s picture

crifi commented
Status: Active » Closed (duplicate)

This problem is caused by a wrong configuration of $base_url and should be prevented by inserting a warning message to the requirements system. Therefore I created a new issue and this is now a duplicate of #1046682: Install/Update process fails if $base_url is set to a wrong URL. Please reopen if I'm wrong. Thanks!

JCB’s picture

JCB commented

Thank you crifi.

Your solution at #21 solved my update issue.
I opened settings.php
fixed baseurl

SOLVED: "The update process was aborted prematurely while running update"