By tvst on
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
1) Are you sure it really is
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
--
Drupal services
My Drupal services
yes, i'm sure. I left it running for about 20 minutes.
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
Which errors
Which errors exactly?
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
here they are:
this is what my main page (mysite.com/tracker/) printed when i first viewed it (after the failed upgrade)
and here's what the watchdog says (the bottom lines are the ones which happen first in time):
by the way, the update script autoselected the number "129" on the db update selectbox
129 is the right number, but
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
--
Drupal services
My Drupal services
I had to do my site's update
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
That is probably because you
That is probably because you had backported Morbus' free tagging patch.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
Nope. Not a chance. free
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
I just tried 131 and still no go.
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 :)
Oh wait, you have 4.6.0?
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
I have 4.6.0 but I upgraded it to 4.6.6 before installing 4.7
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?
Can you make your sql dump
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
--
Drupal services
My Drupal services
Well,
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.
I think the problem might be
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
--
Drupal services
My Drupal services
I'll send you as soon as I can
...probably by friday.
hmmm
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.
Try running the update with
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
All errors are printed
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.
i tried the upgrade 3 times...
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.
I've got the same issue.
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.
So thought i'd get clever,
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%.
http://drupal.org/node/61039#
http://drupal.org/node/61039#comment-116336
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
Yah, It's not something I can really just hand over either.
I mean, it's nice that you offer, but i'm not comfortable with handing over my users data.
Strip the database
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.
Me too
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.
110 is the wrong number to
110 is the wrong number to start from, 129 should be right.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
doesn't improve things
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%
Research: Conflict between database revision 146 and 159
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
confirmed
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?
Bug report url
http://drupal.org/node/61544
kika, I am pretty sure that
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
--
Drupal services
My Drupal services
Killes, a question for you about update 159.
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
Update 159 is for recovering
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
--
Drupal services
My Drupal services
Well, that's some good
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?
Does that mean you managed
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.
Yes, I managed to. The
Yes, I managed to. The problem did not turn out to be too many revisions, but broken revisions.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
Thanks for the reply. 2
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..
I think my patch resolves
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
--
Drupal services
My Drupal services
Please have a look at this
Please have a look at this patch:
http://drupal.org/node/61867
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
Killes! You are rad.
This patch solves this issue for me.
Same problem - hangs forever at 58% 4.6.6 to 4.7.0 (or any 4.7.x
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!!!
chop chop
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.
The 58% solution?
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.
that's awesome. i'll try it out.
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.
better...
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.
Well, I got this error too.
Well, I got this error too. I've contacted Killes to send him my SQL dump... let's keep our fingers crossed.
Also, I got dozens of these
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?
update log
Update system from 129, og from 1.
After a few seconds ("updating system module" is never displayed):
After the second attempt:
Query log (failed only):
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).
"national characters are now mangled"
"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
Works nice with postgres
I had to change the collation of my drupal database under postgres, but after that it did work as expected, even with Tamil characters.
what did you do, exactly?
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?
Solved -- For me
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
thanks
That worked great for me, I was also stuck at 58%
Worked for me
Props to killes
Kinda worked
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...
Please try the following:1)
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
--
Drupal services
My Drupal services
Before I go ahead and do it
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
node_revisions
I'm guessing that the nid's are OK but the vid's aren't?
The failed previous upgrade
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
--
Drupal services
My Drupal services