An unrecoverable error has occurred

I know it's confusing, but "update.module" is for the new part of 6.x core that checks for available updates to your modules and themes. You're talking about update.php, which is the "update system" component...

Also, given that update.php is working fine for thousands of sites, I'm guessing this is something peculiar with your site, DB and/or browser, not a critical bug in update.php itself. If you want someone to be able to help you solve this, you'll need to provide details about exactly what versions of everything you're using, including the version of your browser. It sounds like some kind of jQuery/JS problem, so the browser, version, and configuration will be important to whomever can actually help you.

Good luck,
-Derek

Thank you and sorry for the confusion / misclassification.

I am running firefox on a mac... I have used safari as well. Firefox works fine with my other site, so I don't think it is the browser. I have disabled javascript and run update.php and it acts about the same (without a scrollbar)...

I have disabled all but the "standard" modules. I am not sure where to look next, but I am personally leaning toward something in the system table is not in an expected state. But it is just a hunch.

my batch table was full of attempts... I exported it off (saved a copy) and ran update.php with an empty batch table.

This record appeared: (batch field of the batch table)

a:8:{s:4:"sets";a:1:{i:0;a:10:{s:7:"sandbox";a:0:{}s:7:"results";a:0:{}s:7:"success";b:0;s:10:"operations";a:5:{i:0;a:2:{i:0;s:13:"update_do_one";i:1;a:2:{i:0;s:6:"system";i:1;s:4:"6047";}}i:1;a:2:{i:0;s:13:"update_do_one";i:1;a:2:{i:0;s:8:"pathauto";i:1;s:1:"4";}}i:2;a:2:{i:0;s:13:"update_do_one";i:1;a:2:{i:0;s:5:"token";i:1;s:1:"1";}}i:3;a:2:{i:0;s:13:"update_do_one";i:1;a:2:{i:0;s:7:"comment";i:1;s:4:"6003";}}i:4;a:2:{i:0;s:13:"update_do_one";i:1;a:2:{i:0;s:6:"update";i:1;s:4:"6000";}}}s:5:"title";s:8:"Updating";s:12:"init_message";s:27:"Starting updates
 ";s:13:"error_message";s:131:"An unrecoverable error has occurred. You can find the error message below. It is advised to copy it to the clipboard for reference.";s:8:"finished";s:15:"update_finished";s:16:"progress_message";s:31:"Remaining @remaining of @total.";s:5:"total";i:5;}}s:11:"current_set";i:0;s:11:"progressive";b:1;s:3:"url";s:30:"http://xxxxxxxxxx.com/update.php";s:11:"source_page";s:4:"node";s:8:"redirect";s:41:"http://boobblog.com/update.php?op=results";s:2:"id";s:1:"1";s:13:"error_message";s:99:"Please continue to the error page";}

Isn't this supposed to process?

@tuxguy: It's been a while... did you ever find out what was/is causing this issue?

- Arie

Looks like tuxguy won't be posting any feedback. Setting this to fixed.

Feel free to reopen if you think that is wrong.

- Arie

People like us are still encountering the same problem. Please see my posting http://drupal.org/node/348336 and the other poor guy's story http://drupal.org/node/320477.

We had been evaluating Drupal 5 for months and tried upgrades several times by running the same process without any issues. Recently we did a fresh Drupal 6.6 installation for rolling out our project and then the first time we tried to upgrade a module we hit the wall and we have not even tried to upgrade the core module. Maybe we would have been better off sticking with Drupal 5.

Any suggestions? Thanks a lot.

Re-opening this issue.

I'm having the same issue after updating to 6.8 (I think it started before, though).

Everything looks OK until I start the update. It get's stuck on "Starting Update" and never ends.
I tried to clear the batch table, but it's not use.

I did notice a JavaScript error on the page while running with Firefox w/Firebug: Access to restricted URI denied" code: "1012
This was in a jQuery file.
I tried on Safari and it breaks, too.

Any ideas?

Anyone?

same problem trying to update some of the modules. The "updating" message stays allways and nothing happens...

I finally got my problem solved. In my case it seemed to me at some point during update Drupal was trying to show a different progress bar image file. I have Clean Url enabled (using IIRF on IIS) and in my rewrite rules all files were passed to index.php for processing. But for this particular file the rewrite rule was not able to find it. Instead of throwing a more specific 'file not found' error, the Batch API simply returned the 'An unrecoverable error has occurred' message (see http://drupal.org/node/363911). Once I added the following rewrite rule my update ran smoothly.

# Do not pass to drupal if the file or directory exists
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]

Hope this can help some people.

@dantw: Thanks for sharing the solution!
@zvikico, @urwen: Can you confirm this fixes the problem on your end too?

- Arie

Looks like zvikico and urewen won't be posting any feedback so I'm setting this to fixed.

Feel free to reopen if you think that is wrong.

- Arie

Automatically closed -- issue fixed for 2 weeks with no activity.

edited to remove. i can't be sure this solved my problem.

Once I added the following rewrite rule my update ran smoothly.

# Do not pass to drupal if the file or directory exists
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]

It worked for me too :-) thanks

I must say that I had to flash the cache too.

I am running drupal 6.12 on a Linux server using firefox 3 and had the same problem Update.php would start but never finish.

dantw's solution worked for me:

"Once I added the following rewrite rule my update ran smoothly.

# Do not pass to drupal if the file or directory exists
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L] "

I am getting this as well.

This should be committed to .htaccess it seems, as several people are getting it.

Hum, first of all, how is the update looking for a different progress bar image? Why? Second, if the given .htaccess snippet solves it, then why is the browser not finding that image (it is an existing file, so it should not jump on the index.php snippet already in .htaccess which checks for existing files)?

Last, bugs are fixed first in Drupal 7, so let's get this there first. This is to ensure that we introduce no regressions.

I'm experiencing similar behavior on one site while attempting a 6.13 => 6.14 update.

In IE8 I get the endless progress bar problem described above, but, in FireFox 3.53 I get:
"An HTTP error 0 occurred." and on the error page:
"The update process was aborted prematurely while running update #____ in _____.module." (The update # and module can vary).

The .htaccess patch (described above) makes no difference on this site.

If Javascript is disabled in the browser, the "Updating" screen is displayed and no message is ever returned to the user.

Further info: I manually installed database updates such that no further updates need to be executed. Now, when I run update.php, I get:

"warning: array_pop() [function.array-pop]: The argument should be an array in /home/talldave/public_html/<sitename>/update.php on line 314." and
"The update process was aborted prematurely while running update # in .module."

I find it curious that I get the "running update # in .module" message. Hopefully this additional information will provide a clue for those that better understand the update process.

[Note to self: T-H.com]

I'm experiencing similar behavior on one site while attempting a 6.13 => 6.14 update.
I'm using Firefox 3.0.14

I have this message in Error Consol:

"Problema di sicurezza: i contenuti in http://www.mysite.com/update.php?op=start&id=17 non possono caricare dati da http://mysite.com/update.php?id=17&op=do."

"Security problem: the contents in http://www.mysite.com/update.php?op=start&id=17 cannot load data from http://mysite.com/update.php?id=17&op=do."

I use the following rewrite rule in the .htaccess

# RewriteRule ^(.*)$ http://www.example.com/$1 [L,R=301]
RewriteCond %{HTTP_HOST} ^mysite\.com$ [NC]
RewriteRule ^(.*)$ http://www.mysite.com/$1 [L,R=301]

# Do not pass to drupal if the file or directory exists
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]

Strange !

In .htaccess if I use this rewrite rules :

RewriteCond %{HTTP_HOST} ^mysite\.com$ [NC]
RewriteRule ^(.*)$ http://www.mysite.com/$1 [L,R=301]

the update process don't finish. Instead if I use this rules:

RewriteCond %{HTTP_HOST} ^www\.mysite\.com$ [NC]
RewriteRule ^(.*)$ http://mysite.com/$1 [L,R=301]

it worked for me.

scorpio in my settings.php I commented out the baseurl line by adding "//" before it. That fixed my problem and now even with htaccess forcing link to use www, my update.php still works.

(adding www to your baseurl also works, assuming you are forcing www with your htaccess)

I have now experienced this issue on two sites:
1) Update Drupal 6.13 to 6.14 [see comment #20 above] and
2) on an existing Drupal 6.14 site while attempting to update 2 modules (boost & quotes).

Both sites use the .htaccess rewrite rules to redirect to a URL without "www".

In both cases, I have been able to work-around the issue by commenting-out the baseurl line in the settings.php file (as described by DraeZ in comment #24 above), running update.php, and then changing my settings.php file back to its original configuration.

Lets hope that this additional info helps the Code Gods isolate/fix the problem while allowing fellow mortals to work around the issue. ;-)

_{[Note to self: 1) T-H.com, 2) FBD.com]}

I also have this problem on two sites:
- Update 6.13 to 6.14
- Update 5.20 to 6.14 (performed update from 5.13 to 5.20 without problem)

No error is logged within Drupal or PHP. All that is returned is the Updating page with the following:

"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"

This is followed by the source code of an HTML page contained within a red background table cell.

Running on IIS. Have disabled Clean URLs, disabled all cached and cleared cache. Problem still exists.

Perhaps the Core team can look at what is fundamentally different between updates preformed by 5.x and 6.x. Obviously, code that is working well in 5.x Update.php is not working in 6.x Update.php.