I upgraded my 4.6.0 installation to 4.6.2 and the db was upgraded with no issues. Then I upgraded to 4.6.3, 4.6.4, 4.6.5 and 4.6.6 -- even though their upgrade script never updated the database (the scripts claimed it wasn't necessary).

Now, when I try to upgrade to 4.7 RC4 the progress bar gets stuck at 58%, while "updating system module". There are no onscreen errors so I have no idea where to look for solutions.

If I ignore this error and go to my website anyway, I get all sorts of errors.

How do I debug this?

Comments

killes@www.drop.org’s picture

1) Are you sure it really is stuck? There are a number of upgrades which can take a long time. For example the update for drupal.org lasted up to 8 minutes on a dual processor machine.
2) If there were any errors, they should be found in your watchdog table.
--
Drupal services
My Drupal services

tvst’s picture

yes, i'm sure. I left it running for about 20 minutes.

And there were plenty of errors on the watchdog table -- all of them complaining about how there was no column x in table y.

Thanks for the help, though. Please read my next comment as it explains a bit more

killes@www.drop.org’s picture

tvst’s picture

this is what my main page (mysite.com/tracker/) printed when i first viewed it (after the failed upgrade)

     * user warning: Table 'contact' already exists query: CREATE TABLE contact ( subject varchar(255) NOT NULL default '', recipients longtext NOT NULL default '', reply longtext NOT NULL default '' ) in [-- address removed --]/includes/database.mysql.inc on line 120.
    * user warning: Unknown column 'subject' in 'contact' query: ALTER TABLE contact CHANGE subject category VARCHAR(255) NOT NULL in [-- address removed --]/includes/database.mysql.inc on line 120.
    * user warning: Multiple primary key defined query: ALTER TABLE contact ADD PRIMARY KEY (category) in [-- address removed --]/includes/database.mysql.inc on line 120.
    * user warning: Table 'node_revisions' already exists query: CREATE TABLE node_revisions SELECT nid, nid AS vid, uid, type, title, body, teaser, changed AS timestamp, format FROM node in [-- address removed --]/includes/database.mysql.inc on line 120.
    * user warning: Duplicate column name 'log' query: ALTER TABLE node_revisions ADD log longtext in [-- address removed --]/includes/database.mysql.inc on line 120.
    * user warning: Multiple primary key defined query: ALTER TABLE node_revisions ADD PRIMARY KEY vid (vid) in [-- address removed --]/includes/database.mysql.inc on line 120.
    * user warning: Duplicate key name 'nid' query: ALTER TABLE node_revisions ADD KEY nid (nid) in [-- address removed --]/includes/database.mysql.inc on line 120.
    * user warning: Duplicate key name 'uid' query: ALTER TABLE node_revisions ADD KEY uid (uid) in [-- address removed --]/includes/database.mysql.inc on line 120.
    * user warning: Table 'old_revisions' already exists query: CREATE TABLE old_revisions SELECT nid, type, revisions FROM node WHERE revisions != '' in [-- address removed --]/includes/database.mysql.inc on line 120.
    * user warning: Can't DROP 'type'; check that column/key exists query: ALTER TABLE node_revisions DROP type in [-- address removed --]/includes/database.mysql.inc on line 120.
    * user warning: Table 'search_dataset' already exists query: CREATE TABLE search_dataset ( sid int(10) unsigned NOT NULL default '0', type varchar(16) default NULL, data longtext NOT NULL, KEY sid_type (sid, type) ) in [-- address removed --]/includes/database.mysql.inc on line 120.
    * user warning: Incorrect table definition; there can be only one auto column and it must be defined as a key query: ALTER TABLE contact DROP PRIMARY KEY in [-- address removed --]/includes/database.mysql.inc on line 120.
    * user warning: Duplicate column name 'cid' query: ALTER TABLE contact ADD COLUMN cid int(11) NOT NULL PRIMARY KEY auto_increment in [-- address removed --]/includes/database.mysql.inc on line 120.
    * user warning: Duplicate key name 'category' query: ALTER TABLE contact ADD UNIQUE KEY category (category) in [-- address removed --]/includes/database.mysql.inc on line 120.
    * user warning: Duplicate column name 'weight' query: ALTER TABLE contact ADD COLUMN weight tinyint(3) NOT NULL DEFAULT 0 in [-- address removed --]/includes/database.mysql.inc on line 120.
    * user warning: Duplicate column name 'selected' query: ALTER TABLE contact ADD COLUMN selected tinyint(1) NOT NULL DEFAULT 0 in [-- address removed --]/includes/database.mysql.inc on line 120.
    * user warning: Duplicate column name 'done' query: ALTER TABLE old_revisions ADD done tinyint(1) NOT NULL DEFAULT 0 in [-- address removed --]/includes/database.mysql.inc on line 120.

and here's what the watchdog says (the bottom lines are the ones which happen first in time):

Duplicate column name 'done' query: ALTER TABLE old_revisions ADD done tinyint(1) NOT NULL DEFAULT 0 in [-- address removed --]/includes/database.mysql.inc on line 120.
Duplicate column name 'selected' query: ALTER TABLE contact ADD COLUMN selected tinyint(1) NOT NULL DEFAULT 0 in [-- address removed --]/includes/database.mysql.inc on line 120.
Duplicate column name 'weight' query: ALTER TABLE contact ADD COLUMN weight tinyint(3) NOT NULL DEFAULT 0 in [-- address removed --]/includes/database.mysql.inc on line 120.
Duplicate key name 'category' query: ALTER TABLE contact ADD UNIQUE KEY category (category) in [-- address removed --]/includes/database.mysql.inc on line 120.
Duplicate column name 'cid' query: ALTER TABLE contact ADD COLUMN cid int(11) NOT NULL PRIMARY KEY auto_increment in [-- address removed --]/includes/database.mysql.inc on line 120.
Incorrect table definition; there can be only one auto column and it must be defined as a key query: ALTER TABLE contact DROP PRIMARY KEY in [-- address removed --]/includes/database.mysql.inc on line 120.
Table 'search_dataset' already exists query: CREATE TABLE search_dataset ( sid int(10) unsigned NOT NULL default '0', type varchar(16) default NULL, data longtext NOT NULL, KEY sid_type (sid, type) ) in [-- address removed --]/includes/database.mysql.inc on line 120.
Can't DROP 'type'; check that column/key exists query: ALTER TABLE node_revisions DROP type in [-- address removed --]/includes/database.mysql.inc on line 120.
Table 'old_revisions' already exists query: CREATE TABLE old_revisions SELECT nid, type, revisions FROM node WHERE revisions != '' in [-- address removed --]/includes/database.mysql.inc on line 120.
Duplicate key name 'uid' query: ALTER TABLE node_revisions ADD KEY uid (uid) in [-- address removed --]/includes/database.mysql.inc on line 120.
Duplicate key name 'nid' query: ALTER TABLE node_revisions ADD KEY nid (nid) in [-- address removed --]/includes/database.mysql.inc on line 120.
Multiple primary key defined query: ALTER TABLE node_revisions ADD PRIMARY KEY vid (vid) in [-- address removed --]/includes/database.mysql.inc on line 120.
Duplicate column name 'log' query: ALTER TABLE node_revisions ADD log longtext in [-- address removed --]/includes/database.mysql.inc on line 120.
Table 'node_revisions' already exists query: CREATE TABLE node_revisions SELECT nid, nid AS vid, uid, type, title, body, teaser, changed AS timestamp, format FROM node in [-- address removed --]/includes/database.mysql.inc on line 120.
Multiple primary key defined query: ALTER TABLE contact ADD PRIMARY KEY (category) in [-- address removed --]/includes/database.mysql.inc on line 120.
Unknown column 'subject' in 'contact' query: ALTER TABLE contact CHANGE subject category VARCHAR(255) NOT NULL in [-- address removed --]/includes/database.mysql.inc on line 120.	
Table 'contact' already exists query: CREATE TABLE contact ( subject varchar(255) NOT NULL default '', recipients longtext NOT NULL default '', reply longtext NOT NULL default '' ) in [-- address removed --]/includes/database.mysql.inc on line 120.
Unknown column 'access' in 'field list' query: UPDATE users SET access = 1146427938 WHERE uid = 1 in [-- address removed --]/includes/database.mysql.inc on line 120.
Unknown column 'access' in 'field list' query: UPDATE users SET access = 1146427938 WHERE uid = 1 in [-- address removed --]/includes/database.mysql.inc on line 120.
Unknown column 'access' in 'field list' query: UPDATE users SET access = 1146427938 WHERE uid = 1 in [-- address removed --]/includes/database.mysql.inc on line 120.
Unknown column 'access' in 'field list' query: UPDATE users SET access = 1146427938 WHERE uid = 1 in [-- address removed --]/includes/database.mysql.inc on line 120.
Unknown column 'access' in 'field list' query: UPDATE users SET access = 1146427930 WHERE uid = 1 in [-- address removed --]/includes/database.mysql.inc on line 120.
Unknown column 'access' in 'field list' query: UPDATE users SET access = 1146427927 WHERE uid = 1 in [-- address removed --]/includes/database.mysql.inc on line 120.

by the way, the update script autoselected the number "129" on the db update selectbox

killes@www.drop.org’s picture

129 is the right number, but the errors seem to indicate that you did the update on the same copy of the database.
--
Drupal services
My Drupal services

sepeck’s picture

I had to do my site's update from 131 for it to succeed from 4.6.6

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide

killes@www.drop.org’s picture

That is probably because you had backported Morbus' free tagging patch.
--
Drupal services
My Drupal services

sepeck’s picture

Nope. Not a chance. free tagging isn;t all that appealing to me. I had errors when I updated, so I looked at the database.inc and that was the last update listed for 4.6.6. When I selected that no errors during update.

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide

tvst’s picture

I just tried all sorts of combinations -- again -- and nothing. The funny thing is that when I tried "131", the upgrade didn't fail at 58% but at 57% instead :-/

My website runs 4.6.0 and, as I explained before, for my test website I copied that database and incrementally upgraded it Drupal to 4.6.6.

If a table or column already exists on my DB it is not because I added it myself (I don't do that) and it's not because I was already running a newer DB format (I wasn't, I was running 4.6.0).

I imagine the errors may come because from modules that were incorporated into the Druapal distribution post 4.6.0, and which changed the DB from what the upgrade script expects.

In any case, I would just like to know how I can manually update the node and user tables right now. I don't care about saving the revisions (although that would be nice) or anything else, since I'm probably doing a complete rehaul of the website anyway. Can someone point me in the right direction here?

Thanks everyone for the help, by the way :)

sepeck’s picture

Oh wait, you have 4.6.0? Not 4.6.6? Then 131 is definitaly not the one for you. You might try going back a version down. Try 128 or update your site to 4.6.6 first, then try 4.7.0. 4.6.0 has a serious security issue.

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide

tvst’s picture

I have 4.6 running on my main site, which I then copy to another folder and another DB and another subdomain for testing. On this new test site I then upgrade drupal to 4.6.2, then 4.6.3, then (...) all the way to 4.6.6. Although it doesn't really matter since there were no DB changes since 4.6.2. Only then do I attempt to install 4.7.0.

But now I've given up on that. I just want to do a clean install and somehow import my users and nodes. Any ideas?

killes@www.drop.org’s picture

Can you make your sql dump available to me? If yes, contact me through my contact tab. I'd like to try and it update myself and if successfull you wouldn't need to do it anymore.
--
Drupal services
My Drupal services

tvst’s picture

Well, I can't give you my sql dump because it contains private user data. What I could do instead is give you just the "CREATE TABLE" parts of the dump, without any of the data.

Of course, that wouldn't exactly solve my problem but it would definitely help you debug.

killes@www.drop.org’s picture

I think the problem might be somehow related to the data in the tables, but I'd give the bare bones version a try too.
--
Drupal services
My Drupal services

tvst’s picture

...probably by friday.

tvst’s picture

despite all those errorrs, it seems to be working now, with no additional watchdog messages showing up.

The only thing left is that I'm getting some weird characters instead of accents and such. Like "Pé ante pé" instead of "Pé and pé"

--------- edit: ---------
No, wait, it's not working after all. I can see my nodes on the tracker, but i can't view their actual content. I get an "access denied" even though I am user 1.

gordon’s picture

Try running the update with javascript turned off in your browser. This will allow you to see if there are any problems.
--
Gordon Heydon
Heydon Consulting

--
Gordon Heydon

Steven’s picture

Both the JS and non-JS versions print errors to the screen in an identical fashion. It may simply take a while due to timeouts.

--
If you have a problem, please search before posting a question.

tvst’s picture

I tried the upgrade 3 times -- after restoring the db to the 6.4.6 version everytime, of course. Every time i waited more than 20 minutes with the progress bar at 58%. Twice I used firefox 1.5, once internet explorer 6 (to check if it was some browser issue).

20 minutes should be enough for any reasonable script to fire its timeouts.

It would be nice to have all successful and failed operations printed onto the screen as the progress bar moved. This way I'd know where to look. I tried looking at update.php to figure out what's going on, with no luck.

At this point I really don't care about doing the full upgrade. I just want my "user" and "nodes" tables. If I could do a clean install and import those tables, it would be amazing, but I guess the tables need to be updated first.

Does anyone know what changed on the "nodes" and "user" tables since 4.6.6, and how to convert them to the new format? I'm an SQL noob.

smithcorona’s picture

I started this site back in 4.5 and i've upgraded it to 4.6.3 successfully in the past and then just now i upgraded to 4.6.6 to make sure that I had the latest tables.
Now, I've just installed 4.7, and the little progress bar sticks at 58%.

What is 58% anyway?? I'd much rather have a verbose output that tells me what's going on and where, so i could know where this has hung.
It's totally hung, and it's been about 20 minutes.

smithcorona’s picture

and I set back the update clock to version 110, thinking that maybe there were some old issues that needed to be addressed.
Nope, now it's stuck at 70%.

smithcorona’s picture

I mean, it's nice that you offer, but i'm not comfortable with handing over my users data.

heine’s picture

Strip the database until you have a minimal version without sensitive data that still replicates the problem.
--
Tips for posting to the forums.
When your problem is solved, please post a follow-up to the thread you started.

fallacious’s picture

Stuck at 70% when applying patches starting at 110. PHP runs out of memory after a few hours - I gave it 48MB to play with. This is a site that was started at 4.5 or earlier and upgraded to 4.6.6 without problems. I have other sites that took the same upgrade path, they upgraded to rc3 just fine.

Nope, I can't hand over the database, either. Not unless I write a script to sanitize the actual data and replace it with filler data of the same size.

killes@www.drop.org’s picture

110 is the wrong number to start from, 129 should be right.
--
Drupal services
My Drupal services

fallacious’s picture

First round, no percentage or other progress shown:

warning: reset() [function.reset]: Passed variable is not an array or object in /...xxx.../update.php on line 404.

Second round, stuck at 58%

smithcorona’s picture

I have found that there is a conflict between database patch 146 and database patch 159 that causes the database update to hang.

All databases patches prior to 146 will hang at 159
all database patches subsequent to 146 do not hang at 159.

----------------

I decided to investigate this and to do so, opted to apply all the patches to the database in sequential order, in order to discover which patches failed and when. i did this without resetting the database, and starting from 140 and jumping up untill i found a number that worked:
the database was not reset in between

140 - fails at 47%
145 - fails at 40%
149 - fails at 32%
151 - fails at 27%
156 - fails at 12%
157 - fails at 8%
158 - fails at 4 %
159 - fails.

--

in order to discover if there was a conflict or if 159 worked, i reset the databse, and attempted again, this time backwards from 159.

159 passed
158 passed
150 passed
149 passed
148 passed
147 passed
146 -- failed
145 -- failed
140 -- failed

-- From this, I would deduce that there is a conflict introduced at 146 which causes failure at 159.
I could be wrong.
--------------------------------------------

I have submitted this as a bug
--------
this url:
http://drupal.org/node/61544

kika’s picture

here, upgrading from 4.6 to cvs.
same behaviour, stuck at 58%

can pass the dump, gerhard, if you like to (it's 333MB unpacked ;)

where is the exact URL to bugreport?

smithcorona’s picture

killes@www.drop.org’s picture

kika, I am pretty sure that this is the error reported by Ricardo, namely that 'max_allowed_packet' is set to a too low value. The update script stores the update data in the session and this can apparently get quite a lot of data f you have a lot of nodes and/or a rather low setting for this variable. I have set max_allowed_packet in my my.cnf and did not encounter any such problems.

Edit: I am now pretty sure that the 'max_allowed_packet' error was only a followup of the "broken revisions" error. OTOH, the broken revisions were probably caused my the 'max_allowed_packet' error somewhere in the past.

--
Drupal services
My Drupal services

hound’s picture

Killes, since you wrote that original comment about how this error should never occur if you upgrade from 4.6, and that it is not worth fixing, could you comment: Do we care if update 159 is never done? Will it affect anything? Thanks in advance!

/Hound

killes@www.drop.org’s picture

Update 159 is for recovering your old revision.
If you do not care about them it is safe to comment out the update 159.

I think some of you guys have an awful lot of revisions. I wish I had had your databases when writing this update...

Basically there are two problems:

1) if you have a lot of revisions then update 159 will simply take an awfull long time to complete. And that means a long time, like half an hour or even longer.

2) Due to the fact that you have a lot of updates some data that we log in the session can lead to the max_packet error.
--
Drupal services
My Drupal services

ricmadeira’s picture

Well, that's some good news... I don't think I have that much revisions, but I'll look into it.

By the way, this might be significant. Somewhere along the line, in the recent past, I started getting these errors pretty much everytime I deleted revisions:

warning: mysql_real_escape_string() expects parameter 1 to be string, array given in /home/ricmad/public_html/abreojogo/includes/database.mysql.inc on line 239.
warning: Cannot modify header information - headers already sent by (output started at /home/ricmad/public_html/abreojogo/includes/common.inc:384) in /home/ricmad/public_html/abreojogo/includes/common.inc on line 192.

I never worried about them because the revisions appear to be deleted, error or no error, and I don't go around deleting them that much. Could this be related to the update problem?

ricmadeira’s picture

Does that mean you managed to update my SQL dump, Killes? Well, that would at least be good news... I could update my DB outside my webhost's server and then upload it :)

Anyway, I set up a duplicate of my site and have been running tests with it. If it matters, it turns out I can't reproduce that "max_allowed_packet" SQL error... the error might still be there, but it doesn't show up on watchdog. I've tried, and tried, and tried, and I can't reproduce those error messages again. The website/DB is an exact duplicate of the one I where I got the error, plus the DB is an exact duplicate, plus I'm using the same webhosting account.

killes@www.drop.org’s picture

Yes, I managed to. The problem did not turn out to be too many revisions, but broken revisions.
--
Drupal services
My Drupal services

hound’s picture

Thanks for the reply. 2 suggestions:

a) ask the user at update time if he/she wants to run update 159. Let them skip it if they want to.

b) Display some counter on-screen so that there is an indication that something is happening. I would probably wait even an hour for it to complete, if I had confidence that it wasn't really dead, but was still doing something. The 58% progress bar is ok, when there is something that happens fairly frequently, but for this update_159 problem, it would be better to show an updating recno() or something..

killes@www.drop.org’s picture

I think my patch resolves the problem in such a way that no choice button is needed. The progress bar is essentially a counter, any counter would more or less have failed.
--
Drupal services
My Drupal services

smithcorona’s picture

This patch solves this issue for me.

hound’s picture

This is very annoying! I interim-upgraded from 4.5.0 to 4.6.6 - and my site, which has several hundred thousand records, runs fine.

If I create a copy of the 4.6.6 database, set access_check to false and browse directly to the 4.7.0 updata.php (necessary since I can't log in or see anything at all except error messages), it zooms to 58% and then stays there until the php script times out. I then eventually get the error page which says:

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

(there are no other errors shown)

Below is the snippet which shows what is happening....

--------------------
Update #157

* DELETE FROM {url_alias} WHERE src = 'node/feed' AND dst = 'rss.xml'
* INSERT INTO {url_alias} (src, dst) VALUES ('rss.xml', 'node/feed')

Update #158

* ALTER TABLE {old_revisions} ADD done tinyint(1) NOT NULL DEFAULT 0
* ALTER TABLE {old_revisions} ADD INDEX (done)

Update #159

* UPDATE {sequences} SET id = 1288 WHERE name = '{node_revisions}_vid'
* UPDATE {sequences} SET id = 1302 WHERE name = '{node_revisions}_vid'
* UPDATE {sequences} SET id = 1304 WHERE name = '{node_revisions}_vid'
* UPDATE {sequences} SET id = 1306 WHERE name = '{node_revisions}_vid'
...
...
... (this continues with 'SET id = xxxx' incrementing by one, forever.....)
-------------------
I tried to go into update.php and completely skip doing update 159, since at one point I searched these archives (for 'update 159') and found this thread: http://drupal.org/node/40662

(begin quote from thread)
---------------------------------
#3 submitted by killes@www.drop.org on December 11, 2005 - 11:07

If you did create the site in September then you would not run update.php at all and the update that created the old_revisions table.
#4 submitted by beginner on December 11, 2005 - 15:50

So, what about the error message? Do we need those tables or not? Do I need to create them "manually"?
#5 submitted by killes@www.drop.org on December 11, 2005 - 16:23

The table is created in update 146 and holds old revisions that were created using the old revision table. For core node types, these old revisions are put into the node_revisions table in update 158/159. Non-core modules will need to create separate update scripts to retrieve their revisions.

A possible fix could be to create this table in update 158 if it does not exist. Don't know if this would work with pgsql.
#6 submitted by Cvbge on December 13, 2005 - 20:31
Priority: normal » minor
Status: active » won't fix

It's not trivial for postgres.

This error can't happen if you upgrade from 4.6. If you're using cvs - you should be ready to have some problems (and this one is completly safe afaik).

IMO this is not worthy fixing.
---------------------------------------
(end quote from thread)

Anyway, if this is true, I can totally skip this update, right? I edited update.php - the function fix_update_schema_version() - and below the switch case statement, I found this statement;

variable_set('update_170_done', TRUE);

I added a line below that which reads

variable_set('update_159_done', TRUE);

and tried again. No luck! Apparently the line

variable_set('update_170_done', TRUE);

only gets executed if

if (update_start=variable_get('update_start, FALSE)) {

so then I tried moving

variable_set('update_159_done', TRUE);

*above* the if statement...but that also did nothing!

WHERE ARE THE ACTUAL UPDATE INSTRUCTIONS STORED? I can't seem to find the file that contains them. I would be perfectly happy to go into that file and get rid of the line that causes the endless loop...

HELP HELP HELP!!!

fallacious’s picture

As far as I can tell, the actual updates are in database/updates.inc

You could try to comment out the code of function system_update_159(), leaving it as an empty stub. I don't have the bandwidth to sit down and figure out the impact of skipping this update. Losing old revisions would be acceptable to me, though.

hound’s picture

I modified update.php to set update_159_done = TRUE and also updates.inc so that if update_159_done is true then that update gets skipped. The big update then ran fine! (apparently, I was able to post new content, view, and do all the stuff I usually do - but there may be an inconsistency that I haven't discovered. In my case there is no utility whatsoever to being able to look at old revisions.

tvst’s picture

that's awesome. i'll try it out and let you know.

i've been running this site since 4.4.x and never had any update problems before. this really bothers me. oh well, we'll see what happens.

fallacious’s picture

Forcing the update process to skip #159 allows it to run to completion. I still have to kick off the update from #129 twice and end up getting a ton of failed updates, most but not all relating to revisions. The site seems to work, but I'll hold off on updating the live site until the upgrade path is less fragile.

I'm getting to the point where I'd prefer to migrate the content and user data into a clean, new site and drop all kinds of accumulated crud in the process.

ricmadeira’s picture

Well, I got this error too. I've contacted Killes to send him my SQL dump... let's keep our fingers crossed.

ricmadeira’s picture

Also, I got dozens of these errors in Watchdog (I'm only including two):

Got a packet bigger than 'max_allowed_packet' bytes query: UPDATE sessions
SET uid = 1, cache = 0, hostname = '82.154.65.11', session =
'messages|a:0:{}watchdog_overview_filter|s:3:\"all\";update_remaining|a:21:{i:30;a:2:{s:6:\"module\";s:6:\"system\";s:7:\"version\";i:159;}i:31;a:2:{s:6:\"module\";s:6:\"system\";s:7:\"version\";i:160;}i:32;a:2:{s:6:\"module\";s:6:\"system\";s:7:\"version\";i:161;}i:33;a:2:{s:6:\"module\";s:6:\"system\";s:7:\"version\";i:162;}i:34;a:2:{s:6:\"module\";s:6:\"system\";s:7:\"version\";i:163;}i:35;a:2:{s:6:\"module\";s:6:\"system\";s:7:\"version\";i:164;}i:36;a:2:{s:6:\"module\";s:6:\"system\";s:7:\"version\";i:165;}i:37;a:2:{s:6:\"module\";s:6:\"system\";s:7:\"version\";i:166;}i:38;a:2:{s:6:\"module\&quo in /home/ricmad/public_html/abreojogo/includes/database.mysql.inc on line 120.

Got a packet bigger than 'max_allowed_packet' bytes query: UPDATE sessions
SET uid = 1, cache = 0, hostname = '82.154.65.11', session =
'messages|a:0:{}watchdog_overview_filter|s:3:\"all\";update_remaining|a:21:{i:0;a:2:{s:6:\"module\";s:6:\"system\";s:7:\"version\";i:159;}i:1;a:2:{s:6:\"module\";s:6:\"system\";s:7:\"version\";i:160;}i:2;a:2:{s:6:\"module\";s:6:\"system\";s:7:\"version\";i:161;}i:3;a:2:{s:6:\"module\";s:6:\"system\";s:7:\"version\";i:162;}i:4;a:2:{s:6:\"module\";s:6:\"system\";s:7:\"version\";i:163;}i:5;a:2:{s:6:\"module\";s:6:\"system\";s:7:\"version\";i:164;}i:6;a:2:{s:6:\"module\";s:6:\"system\";s:7:\"version\";i:165;}i:7;a:2:{s:6:\"module\";s:6:\"system\";s:7:\"version\";i:166;}i:8;a:2:{s:6:\"module\";s:6:\& in /home/ricmad/public_html/abreojogo/includes/database.mysql.inc on line 120.

Could they be related to the cause of the error, or are they just a consequence of update.php getting stuck?

fallacious’s picture

Update system from 129, og from 1.

After a few seconds ("updating system module" is never displayed):

warning: reset() [function.reset]: Passed variable is not an array or object in /...xxx.../update.php on line 405.

After the second attempt:

    * user warning: Can't DROP 'title'; check that column/key exists query: update_sql ALTER TABLE boxes DROP INDEX title in /...xxx.../includes/database.mysql.inc on line 120.
    * user warning: Table 'contact' already exists query: update_sql CREATE TABLE contact ( subject varchar(255) NOT NULL default '', recipients longtext NOT NULL default '', reply longtext NOT NULL default '' ) in /...xxx.../includes/database.mysql.inc on line 120.
    * user warning: Duplicate entry 'rss.xml' for key 2 query: update_sql INSERT INTO url_alias (src, dst) VALUES ('node/feed', 'rss.xml') in /...xxx.../includes/database.mysql.inc on line 120.
    * user warning: Unknown column 'subject' in 'contact' query: update_sql ALTER TABLE contact CHANGE subject category VARCHAR(255) NOT NULL in /...xxx.../includes/database.mysql.inc on line 120.
    * user warning: Multiple primary key defined query: update_sql ALTER TABLE contact ADD PRIMARY KEY (category) in /...xxx.../includes/database.mysql.inc on line 120.
    * user warning: Table 'node_revisions' already exists query: update_sql CREATE TABLE node_revisions SELECT nid, nid AS vid, uid, type, title, body, teaser, changed AS timestamp, format FROM node in /...xxx.../includes/database.mysql.inc on line 120.
    * user warning: Duplicate column name 'log' query: update_sql ALTER TABLE node_revisions ADD log longtext in /...xxx.../includes/database.mysql.inc on line 120.
    * user warning: Multiple primary key defined query: update_sql ALTER TABLE node_revisions ADD PRIMARY KEY vid (vid) in /...xxx.../includes/database.mysql.inc on line 120.
    * user warning: Duplicate key name 'nid' query: update_sql ALTER TABLE node_revisions ADD KEY nid (nid) in /...xxx.../includes/database.mysql.inc on line 120.
    * user warning: Duplicate key name 'uid' query: update_sql ALTER TABLE node_revisions ADD KEY uid (uid) in /...xxx.../includes/database.mysql.inc on line 120.
    * user warning: Table 'old_revisions' already exists query: update_sql CREATE TABLE old_revisions SELECT nid, type, revisions FROM node WHERE revisions != '' in /...xxx.../includes/database.mysql.inc on line 120.
    * user warning: Can't DROP 'type'; check that column/key exists query: update_sql ALTER TABLE node_revisions DROP type in /...xxx.../includes/database.mysql.inc on line 120.
    * user warning: Table 'search_dataset' already exists query: update_sql CREATE TABLE search_dataset ( sid int(10) unsigned NOT NULL default '0', type varchar(16) default NULL, data longtext NOT NULL, KEY sid_type (sid, type) ) in /...xxx.../includes/database.mysql.inc on line 120.
    * user warning: Incorrect table definition; there can be only one auto column and it must be defined as a key query: update_sql ALTER TABLE contact DROP PRIMARY KEY in /...xxx.../includes/database.mysql.inc on line 120.
    * user warning: Duplicate column name 'cid' query: update_sql ALTER TABLE contact ADD COLUMN cid int(11) NOT NULL PRIMARY KEY auto_increment in /...xxx.../includes/database.mysql.inc on line 120.
    * user warning: Duplicate key name 'category' query: update_sql ALTER TABLE contact ADD UNIQUE KEY category (category) in /...xxx.../includes/database.mysql.inc on line 120.
    * user warning: Duplicate column name 'weight' query: update_sql ALTER TABLE contact ADD COLUMN weight tinyint(3) NOT NULL DEFAULT 0 in /...xxx.../includes/database.mysql.inc on line 120.
    * user warning: Duplicate column name 'selected' query: update_sql ALTER TABLE contact ADD COLUMN selected tinyint(1) NOT NULL DEFAULT 0 in /...xxx.../includes/database.mysql.inc on line 120.
    * user warning: Duplicate column name 'done' query: update_sql ALTER TABLE old_revisions ADD done tinyint(1) NOT NULL DEFAULT 0 in /var/...xxx.../includes/database.mysql.inc on line 120.
    * user warning: Table 'poll_votes' already exists query: update_sql CREATE TABLE poll_votes ( nid int(10) unsigned NOT NULL, uid int(10) unsigned NOT NULL default 0, hostname varchar(128) NOT NULL default '', INDEX (nid), INDEX (uid), INDEX (hostname) ) in /...xxx.../includes/database.mysql.inc on line 120.
    * user warning: Table 'client' already exists query: update_sql CREATE TABLE client ( cid int(10) unsigned NOT NULL auto_increment, link varchar(255) NOT NULL default '', name varchar(128) NOT NULL default '', mail varchar(128) NOT NULL default '', slogan longtext NOT NULL, mission longtext NOT NULL, users int(10) NOT NULL default '0', nodes int(10) NOT NULL default '0', version varchar(35) NOT NULL default'', created int(11) NOT NULL default '0', changed int(11) NOT NULL default '0', PRIMARY KEY (cid) ) in /...xxx.../includes/database.mysql.inc on line 120.
    * user warning: Table 'client_system' already exists query: update_sql CREATE TABLE client_system ( cid int(10) NOT NULL default '0', name varchar(255) NOT NULL default '', type varchar(255) NOT NULL default '', PRIMARY KEY (cid,name) ) in /...xxx.../includes/database.mysql.inc on line 120.
    * user warning: Table 'file_revisions' already exists query: update_sql CREATE TABLE file_revisions ( fid int(10) unsigned NOT NULL default 0, vid int(10) unsigned NOT NULL default 0, description varchar(255) NOT NULL default '', list tinyint(1) unsigned NOT NULL default 0, PRIMARY KEY (fid, vid) ) /*!40100 DEFAULT CHARACTER SET utf8 */ in /...xxx.../includes/database.mysql.inc on line 120.
    * user warning: Duplicate entry '1-331' for key 1 query: update_sql INSERT INTO file_revisions SELECT DISTINCT fid , vid, description, list FROM files_tmp in /...xxx.../includes/database.mysql.inc on line 120.

Normalizing files table failed. A backup of the original table called {files_backup} remains in your database.

Query log (failed only):

The following queries were executed
system module

Update #131

    * Failed: ALTER TABLE {boxes} DROP INDEX title

Update #133

    * Failed: CREATE TABLE {contact} ( subject varchar(255) NOT NULL default '', recipients longtext NOT NULL default '', reply longtext NOT NULL default '' )

Update #138

    * Failed: INSERT INTO {url_alias} (src, dst) VALUES ('node/feed', 'rss.xml')

Update #143

    * Failed: ALTER TABLE {contact} CHANGE subject category VARCHAR(255) NOT NULL
    * Failed: ALTER TABLE {contact} ADD PRIMARY KEY (category)

Update #146

    * Failed: CREATE TABLE {node_revisions} SELECT nid, nid AS vid, uid, type, title, body, teaser, changed AS timestamp, format FROM {node}
    * Failed: ALTER TABLE {node_revisions} ADD log longtext
    * Failed: ALTER TABLE {node_revisions} ADD PRIMARY KEY vid (vid)
    * Failed: ALTER TABLE {node_revisions} ADD KEY nid (nid)
    * Failed: ALTER TABLE {node_revisions} ADD KEY uid (uid)
    * Failed: CREATE TABLE {old_revisions} SELECT nid, type, revisions FROM {node} WHERE revisions != ''

Update #147

    * Failed: ALTER TABLE {node_revisions} DROP type

Update #150

    * Failed: CREATE TABLE {search_dataset} ( sid int(10) unsigned NOT NULL default '0', type varchar(16) default NULL, data longtext NOT NULL, KEY sid_type (sid, type) )

Update #153

    * Failed: ALTER TABLE {contact} DROP PRIMARY KEY
    * Failed: ALTER TABLE {contact} ADD COLUMN cid int(11) NOT NULL PRIMARY KEY auto_increment
    * Failed: ALTER TABLE {contact} ADD UNIQUE KEY category (category)

Update #154

    * Failed: ALTER TABLE {contact} ADD COLUMN weight tinyint(3) NOT NULL DEFAULT 0
    * Failed: ALTER TABLE {contact} ADD COLUMN selected tinyint(1) NOT NULL DEFAULT 0

Update #158

    * Failed: ALTER TABLE {old_revisions} ADD done tinyint(1) NOT NULL DEFAULT 0

Update #164

    * Failed: CREATE TABLE {poll_votes} ( nid int(10) unsigned NOT NULL, uid int(10) unsigned NOT NULL default 0, hostname varchar(128) NOT NULL default '', INDEX (nid), INDEX (uid), INDEX (hostname) )

Update #166

    * Failed: CREATE TABLE {client} ( cid int(10) unsigned NOT NULL auto_increment, link varchar(255) NOT NULL default '', name varchar(128) NOT NULL default '', mail varchar(128) NOT NULL default '', slogan longtext NOT NULL, mission longtext NOT NULL, users int(10) NOT NULL default '0', nodes int(10) NOT NULL default '0', version varchar(35) NOT NULL default'', created int(11) NOT NULL default '0', changed int(11) NOT NULL default '0', PRIMARY KEY (cid) )
    * Failed: CREATE TABLE {client_system} ( cid int(10) NOT NULL default '0', name varchar(255) NOT NULL default '', type varchar(255) NOT NULL default '', PRIMARY KEY (cid,name) )

Update #173

    * Failed: CREATE TABLE {file_revisions} ( fid int(10) unsigned NOT NULL default 0, vid int(10) unsigned NOT NULL default 0, description varchar(255) NOT NULL default '', list tinyint(1) unsigned NOT NULL default 0, PRIMARY KEY (fid, vid) ) /*!40100 DEFAULT CHARACTER SET utf8 */
    * Failed: INSERT INTO {file_revisions} SELECT DISTINCT fid , vid, description, list FROM {files_tmp}

Superficially, things look okay. Exceptions are: national characters are now mangled, probably because of the conversion to UTF-8, and the database schema for organic groups seem broken (missing column og.directory).

tvst’s picture

"national characters are now mangled, probably because of the conversion to UTF-8"
i have the same problem. please let me know if you solve it

mousse-man’s picture

I had to change the collation of my drupal database under postgres, but after that it did work as expected, even with Tamil characters.

tvst’s picture

you're saying you changed the collation of the db. what was it before? and what did you change it to? did you have to change the collation of each table individually? did you convert the strings in the tables to a different format as well?

smithcorona’s picture

The issue of the update hanging at '58%' is solved for me by applying this patch.

http://drupal.org/node/61867

-------

*nix instructions.
in your drupal 4.7 directory:

wget http://drupal.org/files/issues/infinite_loop.patch.txt
patch -b -p0 < infinite_loop.patch.txt

then proceed with the update as per normal

svladcjelli’s picture

That worked great for me, I was also stuck at 58%

tvst’s picture

Props to killes

GraemeFoster’s picture

That got me through the 58% barrier and everything seemed to be OK, but now when new nodes are added the body is replaced with an old revision of an existing node! Arg! :(
Any ideas on how to fix this? I'd be happy to lose all old revisions of all nodes and start with a clean sheet...

killes@www.drop.org’s picture

Please try the following:

1) use a new database
2) import backup
3) run update with patch applied
4) Post content of the sequences table here.
5) also post the highest number of vid in the node_revisions table as well as the highes number of nid.
--
Drupal services
My Drupal services

GraemeFoster’s picture

Before I go ahead and do it with a new database, here is the information with the one I have already upgraded (with the patch). It's possible that a failed upgrade is responsible for the problem, but apart from hanging at 58% it went OK. Anyway, here it is:

sequences

users_uid 	34
node_nid 	1349
aggregator_feed_fid 	10
comments_cid 	279
vocabulary_vid 	7
term_data_tid 	89
access_aid 	5
project_cid 	140
quotes_qid 	6
menu_mid 	60
aggregator_item_iid 	49512
filter_formats_format 	3
aggregator_category_cid 	1
files_fid 	16
node_revisions_vid 	1428

node_revisions

  • Highest vid: 1579
  • Highest nid: 1348

I'm guessing that the nid's are OK but the vid's aren't?

killes@www.drop.org’s picture

The failed previous upgrade is indees responsible. Please restart with a fresh db and the backup. The patch is now in cvs so you can get the 4.7 cvs tarball:
ftp://ftp.osuosl.org/pub/drupal/files/projects/drupal-4.7.0-cvs.tar.gz

--
Drupal services
My Drupal services