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

@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

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.

Subscribing

the same problem with Google Chrome, on Firefox works fine;/
Drupal 6.11

I've got the same problem (update.php freezes when the progress bar appearing) yesterday after massive update and cleanup of site's modules. Don't know after which one the problem occured. Drupal 6.15.
Subscribing.

It's probably caused by time out.

Is time out something we can adjust? I'm not sure I know what you mean.

#31: Update is called through AJAX, when PHP scripts has time out (maximum execution time), the main page returns the error.

Is this something I can adjust in Cpanel, or will I have to talk to my webhost? (Hostgator).

ShannonK: In your case you can try to install http://drupal.org/project/drupal_tweaks and increase maximum execution time in PHP Tab

A truly remarkable error. I had the same issue as everyone else with too little information about the actual error.

Read that Firefox would be the problem so I tried Safari which also didn't work. Of course IE wouldn't work then either so I kept on looking for an answer for another hour before trying with IE8 and everything worked smoothly.

Someone with enough brains really should try to figure this one out. Perhaps some JS error that returns something faulty which throws the page not found error?

Same problem, and I can see and JS error on console:
(Im using jquery update)

Uncaught Syntax error, unrecognized expression: }
k.errorjquery.js:75
k.filterjquery.js:75
kjquery.js:72
kjquery.js:91
kjquery.js:73
kjquery.js:91
kjquery.js:73
kjquery.js:91
findjquery.js:95
c.fn.c.initjquery.js:23
cjquery.js:20
Drupal.ahahErrordrupal.js:256
errorprogress.js:88
handleErrorjquery.js:130
g.x.onreadystatechangejquery.js:129

if you added a rewrite to change from domain.com to www.domain.com then you also need to change the base url in the settings file to the www.domain.com (to upload the revised settings file you may have to change the permissions on the file first to Owner: Read Write; then return the permissions to read only)

#37 Thank you! This is where I went wrong. I had a rewrite rule in .htaccess, but I didn't know I needed to change the URL in settings.php. Now update.php is running fine. Oh, and if anyone else is trying this, don't forget to change your permissions so you can edit your settings.php, and then change them back. Thank you, thank you, thank you...

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!

The problem I experienced (#20 above) was NOT caused by a wrong configuration of $base_url. Since the problem hasn't been experienced with newer releases of Drupal 6.x, I see no reason to reopen the ticket. I'm just including this note for completeness in case the problem is experienced again.

Hi,

We are facing this issue again for Drupal version 6.37.
We do not have jquery update module installed.

In our case the progress bar just hangs but the functionality is accomplished.The Drupal core and modules do get updated.
When we run the update.php since ours is a https site, we get the Mixed content error

Mixed Content: The page at 'https://mysite.org/update.php?op=start&id=14' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://mysite.org/update.php?id=14&op=do'. This request has been blocked; the content must be served over HTTPS.

Any help will be appreciated.

@preetam.chari Try asking at: Drupal Answers, as this is a bug report which has been closed already, so nobody would help you here.

@kenorb: Thanks