Drush pm-update (up) rollbacks changes if fetching updates fails

Run with --debug; you are getting a rollback. Looks like the error message could be better in this instance.

The order of those messages is a bit odd. Try drush-5.x-dev; include the output from drush status, and all of the output from pm-update --debug.

Same thing here trying to get drupal (or any project) updated from 7.4 to 7.7, worked once on my blog, failed on another site (same server) using drush 4.5-rc1

It's very important here that we get ALL the debug output. I ran into a similar issue, but the actual error happens towards the beginning of the process, so it's difficult to know whether or not it's related.

My issue was that we failed to get update information for 2 projects, and from that we turned the drupal_set_message(, 'error') into a drush_set_error, which causes rollback for whatever happens afterwards. Obviously not the desired behavior. Doesn't appear to happen in 5, haven't quite nailed down why yet.

Sorry 'drush vset update_max_fetch_time 30' doesn't change anything, here's my verbose debug output :

traduction@sebcorbin:~/public_html$ drush up --debug
Bootstrap to phase 0. [0.04 sec, 2.3 MB]                             [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drush() [0.04 sec, 2.52 MB] [bootstrap]
Bootstrap to phase 6. [0.1 sec, 6.24 MB]                                            [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_root() [0.1 sec, 6.24 MB]           [bootstrap]
Initialized Drupal 7.7 root directory at /home/traduction/public_html [0.13 sec,       [notice]
7.75 MB]
Drush bootstrap phase : _drush_bootstrap_drupal_site() [0.13 sec, 7.76 MB]          [bootstrap]
Initialized Drupal site default at sites/default [0.13 sec, 7.76 MB]                   [notice]
Drush bootstrap phase : _drush_bootstrap_drupal_configuration() [0.16 sec, 7.77 MB] [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_database() [0.16 sec, 7.78 MB]      [bootstrap]
Successfully connected to the Drupal database. [0.16 sec, 7.78 MB]                  [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_full() [0.17 sec, 8.59 MB]          [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_login() [0.65 sec, 33.04 Mo]        [bootstrap]
Successfully logged into Drupal as Anonyme (uid=0) [0.66 sec, 33.42 Mo]             [bootstrap]
Found command: pm-update (commandfile=pm) [0.66 sec, 33.42 Mo]                      [bootstrap]
Initializing drush commandfile: user [0.66 sec, 33.42 Mo]                           [bootstrap]
Including /home/drush/commands/pm/updatecode.pm.inc [0.73 sec, 33.84 Mo]            [bootstrap]
Executing: wget --version
Extension l10n_stats is fetched from git. Ignoring. [1.38 sec, 35.69 Mo]                [debug]
Extension vud is fetched from git. Ignoring. [1.39 sec, 35.71 Mo]                       [debug]
Running: /usr/bin/php /home/drush/drush.php --php='/usr/bin/php'                      [command]
--root='/home/traduction/public_html' --uri='http://default' batch-process '102'
--backend  2>&1 [1.58 sec, 37.15 Mo]
Bootstrap to phase 0. [2.65 sec, 37.18 Mo]                                          [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drush() [2.65 sec, 37.19 Mo]               [bootstrap]
Bootstrap to phase 6. [2.65 sec, 37.19 Mo]                                          [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_root() [2.65 sec, 37.19 Mo]         [bootstrap]
Initialized Drupal 7.7 root directory at /home/traduction/public_html [2.65 sec,       [notice]
37.2 Mo]
Drush bootstrap phase : _drush_bootstrap_drupal_site() [2.65 sec, 37.2 Mo]          [bootstrap]
Initialized Drupal site default at sites/default [2.65 sec, 37.2 Mo]                   [notice]
Drush bootstrap phase : _drush_bootstrap_drupal_configuration() [2.65 sec, 37.2 Mo] [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_database() [2.65 sec, 37.2 Mo]      [bootstrap]
Successfully connected to the Drupal database. [2.65 sec, 37.2 Mo]                  [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_full() [2.65 sec, 37.2 Mo]          [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_login() [2.65 sec, 37.21 Mo]        [bootstrap]
Successfully logged into Drupal as Anonyme (uid=0) [2.65 sec, 37.21 Mo]             [bootstrap]
Found command: batch-process (commandfile=core) [2.65 sec, 37.21 Mo]                [bootstrap]
Initializing drush commandfile: user [2.65 sec, 37.21 Mo]                           [bootstrap]

Failed to get available update data for one project. [2.65 sec, [error]
37.21 Mo]

Command dispatch complete [2.65 sec, 37.21 Mo]                                         [notice]
Peak memory usage was 33.88 Mo [2.65 sec, 37.21 Mo]                                    [memory]
Update information last refreshed: mar, 08/02/2011 - 09:34

Update status information on all installed and enabled Drupal projects:
 Nom                  Version         Proposed        Statut                                   
                      installée       version                                                  
 Administration menu  7.x-3.0-rc1     7.x-3.0-rc1     À jour                                   
 Drupal core          7.4             7.7             SECURITY UPDATE available                
 CAPTCHA              7.x-1.0-alpha3  7.x-1.0-alpha3  À jour                                   
 Chaos tool suite     7.x-1.0-rc1     7.x-1.0-rc1     À jour                                   
 (ctools)                                                                                      
 Devel                7.x-1.2         7.x-1.2         À jour                                   
 Display suite        7.x-1.2         7.x-1.2         À jour                                   
 Entity API           7.x-1.0-beta10  7.x-1.0-beta10  À jour                                   
 EVA: Entity Views    7.x-1.0         7.x-1.0         À jour                                   
 Attachment                                                                                    
 Feeds                7.x-2.0-alpha4  7.x-2.0-alpha4  À jour                                   
 Field Permissions    7.x-1.0-alpha1  7.x-1.0-alpha1  À jour                                   
 Media                7.x-1.0-beta5   7.x-1.0-beta5   À jour                                   
 Styles               7.x-2.0-alpha8  7.x-2.0-alpha8  À jour                                   
 Google Analytics     7.x-1.2         7.x-1.2         À jour                                   
 Raphaël              7.x-1.0-rc1     7.x-1.0-rc1     À jour                                   
 Hidden CAPTCHA       7.x-1.0         7.x-1.0         À jour                                   
 Job Scheduler        7.x-2.0-alpha2  7.x-2.0-alpha2  À jour                                   
 Localization update  7.x-1.0-beta2   7.x-1.0-beta2   À jour                                   
 Libraries API        7.x-1.0         7.x-1.0         À jour                                   
 Live CSS             7.x-1.7         7.x-1.7         À jour                                   
 Masquerade           7.x-1.0-rc3     7.x-1.0-rc3     À jour                                   
 Unique field         7.x-1.0-rc1     7.x-1.0-rc1     À jour                                   
 Views                7.x-3.0-rc1     7.x-3.0-rc1     À jour                                   
 Views Bulk           7.x-3.0-beta1   7.x-3.0-beta1   À jour                                   
 Operations (VBO)                                                                              
 Views Field View     7.x-1.x-dev     7.x-1.x-dev     À jour                                   
 Views Slideshow      7.x-3.0-alpha1  7.x-3.0-alpha1  À jour                                   
 Voting API           7.x-2.4         7.x-2.4         À jour                                   
 Wysiwyg              7.x-2.1         7.x-2.1         À jour                                   
 Localization         Unknown         Unknown         Project was not packaged by drupal.org   
 statistics                                           but obtained from git. You need to       
                                                      enable git_deploy module                 
 Vote Up/Down         Unknown         Unknown         Project was not packaged by drupal.org   
                                                      but obtained from git. You need to       
                                                      enable git_deploy module                 


Drush folder at /home/drush is not writable [2.72 sec, 37.28 Mo]                       [notice]
Code updates will be made to drupal core.
WARNING:  Updating core will discard any modifications made to Drupal core files, most noteworthy among these are .htaccess and robots.txt.  If you have made any modifications to these files, please back them up before updating so that you can re-create your modifications in the updated version of the file.
Note: Updating core can potentially break your site. It is NOT recommended to update production sites without prior testing.

Do you really want to continue? (y/n): y
Executing: mkdir '/home/traduction/public_html/drupal-7.7'
Calling is_readable(/home/traduction/public_html/INSTALL.pgsql.txt) [6.27 sec, 37.34    [debug]
Mo]
Calling is_writable(/home/traduction/public_html/drupal-7.7) [6.27 sec, 37.36 Mo]       [debug]
Calling rename(/home/traduction/public_html/INSTALL.pgsql.txt,                          [debug]
/home/traduction/public_html/drupal-7.7/INSTALL.pgsql.txt) [6.27 sec, 37.36 Mo]
Calling is_readable(/home/traduction/public_html/INSTALL.mysql.txt) [6.27 sec, 37.36    [debug]
Mo]
Calling is_writable(/home/traduction/public_html/drupal-7.7) [6.27 sec, 37.36 Mo]       [debug]

[...]

Calling rename(/home/traduction/public_html/themes,                                     [debug]
/home/traduction/public_html/drupal-7.7/themes) [6.32 sec, 37.5 Mo]
Verifying signature for svn version control engine. [6.32 sec, 37.48 Mo]                [debug]
Executing: svn info '/home/traduction/public_html/drupal-7.7'
  sh: svn: command not found
Verifying signature for bzr version control engine. [6.33 sec, 37.49 Mo]                [debug]
Executing: bzr root '/home/traduction/public_html/drupal-7.7'
  sh: bzr: command not found
Executing: mkdir '/home/traduction/drush-backups/traduction/20110802073618'
Calling is_readable(/home/traduction/public_html/drupal-7.7) [6.36 sec, 37.5 Mo]        [debug]
Calling is_writable(/home/traduction/drush-backups/traduction/20110802073618) [6.37     [debug]
sec, 37.5 Mo]
Calling rename(/home/traduction/public_html/drupal-7.7,                                 [debug]
/home/traduction/drush-backups/traduction/20110802073618/drupal) [6.37 sec, 37.51
Mo]
Executing: wget -P . 'http://ftp.drupal.org/files/projects/drupal-7.7.tar.gz'
  --2011-08-02 09:36:24--  http://ftp.drupal.org/files/projects/drupal-7.7.tar.gz
  Résolution de ftp.drupal.org... 64.50.233.100, 64.50.236.52
  Connexion vers ftp.drupal.org|64.50.233.100|:80...connecté.
  requête HTTP transmise, en attente de la réponse...200 OK
  Longueur: 2754113 (2,6M) [application/x-gzip]
  Saving to: `./drupal-7.7.tar.gz'
  
       0K .......... .......... .......... .......... ..........  1%  326K 8s
      50K .......... .......... .......... .......... ..........  3%  407K 7s
     100K .......... .......... .......... .......... ..........  5%  653K 6s
     150K .......... .......... .......... .......... ..........  7%  651K 5s

[...]

    2550K .......... .......... .......... .......... .......... 96% 34,1M 0s
    2600K .......... .......... .......... .......... .......... 98% 51,2M 0s
    2650K .......... .......... .......... .........            100% 56,9M=1,2s
  
  2011-08-02 09:36:25 (2,27 MB/s) - « ./drupal-7.7.tar.gz » sauvegardé [2754113/2754113]
  
Downloading drupal-7.7.tar.gz was successful. [7.7 sec, 37.53 Mo]                      [notice]
Calling md5_file(drupal-7.7.tar.gz) [7.7 sec, 37.54 Mo]                                 [debug]
Md5 checksum of drupal-7.7.tar.gz verified. [7.72 sec, 37.54 Mo]                       [notice]
Calling chdir(.) [7.72 sec, 37.55 Mo]                                                   [debug]
Executing: tar -C '/home/traduction/public_html' -xzf 'drupal-7.7.tar.gz'
Calling chdir(/home/traduction/public_html) [8.04 sec, 37.53 Mo]                        [debug]
Calling chdir(.) [8.04 sec, 37.53 Mo]                                                   [debug]
Executing: tar -tf 'drupal-7.7.tar.gz'
  drupal-7.7/
  drupal-7.7/MAINTAINERS.txt
  drupal-7.7/xmlrpc.php
  drupal-7.7/INSTALL.pgsql.txt
  drupal-7.7/includes/
  drupal-7.7/includes/graph.inc

[...]

  drupal-7.7/misc/feed.png
  drupal-7.7/misc/jquery.cookie.js
  drupal-7.7/misc/tabledrag.js
  drupal-7.7/.htaccess
  drupal-7.7/CHANGELOG.txt
  drupal-7.7/web.config
  drupal-7.7/cron.php
Calling chdir(/home/traduction/public_html) [8.35 sec, 37.85 Mo]                        [debug]
Calling is_readable(/home/traduction/public_html/drupal-7.7/INSTALL.pgsql.txt) [8.35    [debug]
sec, 37.89 Mo]
Calling is_writable(/home/traduction/public_html) [8.35 sec, 37.89 Mo]                  [debug]
Calling rename(/home/traduction/public_html/drupal-7.7/INSTALL.pgsql.txt,               [debug]
/home/traduction/public_html/INSTALL.pgsql.txt) [8.36 sec, 37.9 Mo]
Calling is_readable(/home/traduction/public_html/drupal-7.7/INSTALL.mysql.txt) [8.36    [debug]
sec, 37.9 Mo]

[...]

Calling is_writable(/home/traduction/public_html) [8.59 sec, 35.89 Mo]                  [debug]
Calling rename(/home/traduction/public_html/drupal-7.7/themes,                          [debug]
/home/traduction/public_html/themes) [8.59 sec, 35.9 Mo]
Changes made in drush_pm_updatecode have been rolled back. [8.59 sec, 35.86 Mo]      [rollback]
Command dispatch complete [8.59 sec, 35.77 Mo]                                         [notice]
 Timer  Cum (sec)  Count  Avg (msec) 
 page   8.435      1      8434.62    

Peak memory usage was 38.07 Mo [8.59 sec, 35.76 Mo]                                    [memory]

Subscribe.

Failed to get available update data for one project. [2.65 sec, [error]

That's why it's rolling back. Granted, this is not the desired behavior, but do you know which project is unable to get update info?

I started #1236034: Don't translate drupal_set_message into drush_set_error yesterday to try to address this, but that's not a fix we can do in 4. Perhaps Greg has some ideas on how we can handle this more elegantly.

I think we should demote the above error to a warning, and insure that the unavailable project is skipped in the update operation. It would also be really spiff if there was a big warning at the end listing all of the projects that were missed. Maybe we should even prompt the user and ask if it is okay to procede with a partial update.

We should not warn or fail if the project that no info is available for is not in the list of requested updates. It is questionable whether or not upc should even report status on projects that were not requested in the update list.

How do I know which project updates cannot be fetched ?

Answering to myself : go to admin/reports/updates and check which project is greyed.
I had a views_datasource patched, I just edited it to not have project information. Anyway thanks for helping, but the project name should be mentioned ;)

to demote the error to a warning there're two options: Issue #1236034: Don't translate drupal_set_message into drush_set_error or override the 'finished' callback of update.module's batch set. To override this we also need a internal change in drush to allow the batch process include a file from DRUSH_ROOT, as the batch api is restricted to files under DRUPAL_ROOT.

To avoid fetching data for non-drupal.org projects can be done but I think it doesn't fix for all conditions that can trigger this issue: for example a network failure may produce this same error.

I thought the idea was that modules in sites/all/modules/ wouldn't be updated by Drush up, but those are the (two) projects that are greyed out in admin/reports/updates -- so, what, do I have to disable them before running update?

Problem found : renaming and closing.

@holtzermann17: (sites/all/modules gets updated by drush up too). 2 solutions, either you comment out the drupal.org project informations at the end of your greyed out modules' info files; or you just disable them before running your update and re-enable them after. The first one is the simpler, you may have junk at the end info files added by newbie developers or obsolete modules.

Anyway, this discussion continues here for future development : #1236034: Don't translate drupal_set_message into drush_set_error

This is not fixed yet.

Showing up the project's .info files may help a lot. Also it is important to know if they're git clones and if you're using git_deploy module.

Ok, so here it is :

Someone made a patch for views_datasource to port the D6 module to D7 (yes it is a huge patch). But the patch was altering project info file :

Index: views_datasource/views_json.info
===================================================================
--- views_datasource/views_json.info	(revision 21218)
+++ views_datasource/views_json.info	(working copy)
@@ -2,12 +2,12 @@
 name = Views JSON
 description = "Views style plugin to render node content as JSON."
 package = Views
-core = 6.x
+core = 7.x
 dependencies[] = views
-php = 5.1
+; php = 5.1
 ; Information added by drupal.org packaging script on 2010-07-16
-version = "6.x-1.0-beta2"
-core = "6.x"
+version = "7.x-dev"
+core = "7.x"
 project = "views_datasource"
 datestamp = "1279257012"

But, due to the absence of the co-maintainer, no info can be fetched for 7.x-dev branch

subscribing

As of version 7.x-4.5 I'm running into these rollback problems because Drush is checking and failing to find update information for my features. This didn't happen with previous versions and doesn't happen with 5.x-dev. Should I be telling Drush to exclude checks for my features somehow?

I just ran into this problem as well. I had a situation where the custom feature that I created was blocking a core update when it was enabled (it could not find release history since it is a feature I made myself). By disabling the feature, I was able to update core from 7.7 to 7.8.

Same here, sub

Subscribing.

Subscribing.

Same problem, subscribing

Subscribing

I had the same problem. Just upgraded my drush from 4.5 to 5.x dev version, and everything was fine.

Perry.

Version 5.x fixed this problem for me to.

Thanks.

Updating to All-versions-5.x-dev (Oct 4, 2011) fixed the problem for me.

+1

Updating to All-versions-5.x-dev (Nov 15, 2011) fixed the problem for me.

To recapitulate:

this bug is present in drush 4.x since 4.5 for drupal 7.

The origin is when drush switched to launch by itself a batch process to get avaliable update info at #1002658: Drush does not correctly handle D7 project status queries

The bug is also potentially present in drush 5.x but we don't hit it because of the changes in backend at #1058874: drush_backend_invoke buffers output till end of command. Show progress..

... but the code producing the error is still there. It happens if a backend command's output is integrated to the main process. A proposal to fix this was #1236034: Don't translate drupal_set_message into drush_set_error, that may not be appropiate in some scenarios.

So attached patch just clears the error context for the concrete case of this issue.

Patch applies both to 4.x and master and I suggest to commit to both branches although in master it is not an issue at present for a canonical invocation of drush upc (perhaps with some argument (--interactive, --integrate or like) it is possible to hit the bug).

I think this is a good solution.

Committed to master and 4.x (via awesome git cherry-pick)

"Backups were restored successfully." Noooooooooo!

Glad this is fixed in the latest development versions, because a rollback when everything that matters succeeds is a major expectation fail-- and when, say, i'm in the mountains of West Virginia doing work through a cell phone data plan and barely getting a signal with a repeater and a booster that my brother set up, i can't afford it.

Workaround in the meantime, the no-backup flag:

drush upc --no-backup

--no-backup

Nice one

Ah ha! Both of those work -

Note that --no-backup should probably only be used when you are using a VCS like git, or when you have project versions and any applied patches memorized! I might use this switch more often, since I am already using git for everything.

Also, we are using Pantheon for some projects, and I MUST use drush 4.5 for that. So, what I've done, is symlinked the seperate versions - so drush defaults to 5, and drush4 defaults to 4.5. Works out pretty well.

fwiw: after updating to 5.x-dev some months ago (Nov 2) gracefully cleared up the difficulty. I updated 5.x-dev to the latest version on drupal.org with files dated Jan 16, 2012 and now we're "restoring from backup" again.

Thanks to mlncn for the --no-backup idea. Probably OK on my dev site.

--no-backup is a workaround that works, but pay attention.
It seems that drush doesn't call updatedb after the code update!
I've some views updates (7301 - Enlarge the name column) yet pending after the upgrade to Views 3.1 today...

drush --no-backup --debug

Project views was updated successfully. Installed version is now 7.x-3.1.
Rolling back update of Views code ... [8.41 sec, 18.08 MB]                                                                                                                                 [notice]
Verifying signature for svn version control engine. [8.41 sec, 18.09 MB]                                                                                                                    [debug]
Executing: svn info 'sites/all/modules/contrib/views'
  svn: 'sites/all/modules/contrib/views' is not a working copy
Verifying signature for bzr version control engine. [8.43 sec, 18.03 MB]                                                                                                                    [debug]
Executing: bzr root 'sites/all/modules/contrib/views'
  sh: bzr: command not found
Changes made in drush_pm_updatecode have been rolled back. [8.43 sec, 18.02 MB]                                                                                                          [rollback]
Command dispatch complete [8.43 sec, 17.97 MB]                                                                                                                                             [notice]
 Timer  Cum (sec)  Count  Avg (msec) 
 page   8.367      1      8367.41 

drush updatedb
The following updates are pending:

views module : 
  7301 -   Enlarge the name column 

Do you wish to run all pending updates? (y/n): y
Finished performing updates.

--no-backup worked for me... will stick with this until a stable 5.0 release. Thanks for the tip.

Upgrading to 5.0.0 with sudo pear install drush/drush-5.0.0 fixed it, and I can now update both modules and Core without rollback.

I did get this error at first:

unlink(/usr/share/php/drush/includes/../includes/table.inc): [warning]
Permission denied drush.inc:755
Drush needs to download a library from [error]
http://download.pear.php.net/package/Console_Table-1.1.3.tgz in order
to function, and the attempt to download this file automatically
failed because you do not have permission to write to the library
directory /usr/share/php/drush/includes/../lib. To continue you will
need to manually download the package from
http://download.pear.php.net/package/Console_Table-1.1.3.tgz, extract
it, and copy the directory into your
/usr/share/php/drush/includes/../lib directory.

So I switched to root with sudo -i and ran drush up to get the file in the right place and fix the error, after which my everyday user had full Drush functionality.

After updating drush to the development version, it was finally showing that a custom feature was causing the problem. Maybe you can just disable your features, update and enable them again!

Reopen, problem persist.

Wrong version, problem still persist for 7.x-4.5, All-versions-4.x-dev and 7.x-5.0-rc2.

The only way I've found to get past this is to use --no-backup, basically denying drush the ability to rollback the update.

Not sure if this is related, but `drush up drupal` isn't updating the database so I have to run `drush updatedb` afterwards.

I am seeing this with a dash of #1266614: Custom modules, Strongarm and Features on "Failed to get available update data" list. I think my custom modules are blocking the update.

Just a couple of notes for folks suffering from this issue:

1) as SebCorbin mentioned in #13, going to the report at /admin/reports/updates is really helpful, you can see there what module (may not be the one you think) is causing the issue. It's the greyed out one.
2) if you are porting D6 modules, you will frequently run into this issue as the project names of the module is found on d.o. but no release history from D7 will be found. Are you in this situation?

I am using the bandaide from poster #39. But the update is never registered so that drupal report out of date on whatever was updated this way.

I need to at first run ..drush up mymodule.. and then run ..drush up mymodule --no-backup
Only then is the update both installed and acknowledged.

1. Make sure you are using the latest version of drush. If you can't because of your configuration for whatever reason, careful use of --no-backup should be ok.
2. Make sure drush has the ability to write to your /tmp directory or another directory that you set for temporary files
3. Greyed out modules can be caused by multiple factors. I've had issues with modules that come from git repositories especially, because they aren't tracked the same way as the ftp sourced ones (default drush/tarballs). Later versions of drush seem to ignore modules that do not have update status information rather than causing this issue. If you are doing a lot of module development and find yourself using a lot of modules from the git repos, setup gitdeploy module and the update module should be much happier. Note: I've also had these lack of update status issues when accidentally installing duplicate modules when using an install profile!

@romanse make sure your site is running cron regularly. This is what provides regular update information. If that information is not available when you go to run drush up, it may be either that or the greyed out module issue noted above.

@rerooting: thank's for the tips. :)

This has become a big deal by now. Updates are fast and furious. So I worked on updating drush as you suggest in your last "1." tip.
I was using putty on windows to do remote drush on a live server. Could not use drush self-update for what ever reasons that way. But I got onto the server machine and ran the self-update. Serveral drush versions were in the auto menu returned and I selected the recommended 5.7. That installed in a flash. No new updates yet but I am optimistic drush 5.7 has this issue fixed on linux as it does on windows. *cheers.

Crossposting from #1428608: Can't get Drupal core or modules to update, backups are auto-restored for no apparent reason Did not find this thread before after posting to it. We should prob. just close that one and keep this? Moving the version to the latest 8.x. My testing showed me that 7.x also seems to share the same vulnerability.

I found that it was some custom features causing this for me.
Based on what I'd learnt 20 minutes earlier about Omega subthemes causing update failures because of their project= line I checked the features.

It looks like features generation has taken to adding a "project=featurename" line to the info files.
And drush upc is assuming that the feature (most of which are highly localized) are actually full-blown projects on d.o.

My fix - to avoid the --no-backup route - is to remove the project=xxx line from each info file of hacked or local custom modules.
That makes upc ignore it and not bail out over such a trivial warning.

Just drifted into this issue today. Thanks everyone for the comments.

@dman, yes features adds a line "project =" and to me it makes sense. I also like that it shows on the report of available updates greyed out as custom features or modules. Not to see it there would be counter intuitive for administration of sites.

Hopefully, newer versions of drush will solve the problem and "not bail out over such a trivial warning".

@rerooting thanks for the summary in #53.

I just tried the recommendation in #57, and still got the rollback.

I found a workaround to this, maybe it will help someone, who has the same problem.

The problem is, that in all of your features, there is a *.info file which contains the "project" property, but in most cases you don't need it. You can comment out this line, and drush will not stack at this point.

So, if you have all of your features in a separate dir, you can switch to to the features dir and execute this command:

find . -name "*.info" -exec sed -ie "/^project/ s/^/; /" {} \;

But be vary carefull with this command: It will comment out all project lines in all Info files of the current dir & subdirs.

@msypes I just used drush 7.x-5.x-dev and didn't have to change any of the .info files.

This issue was marked closed (won't fix) because Drush has moved to Github.

If desired, you may copy this bug to our Github project and then post a link here to the new issue. Please also change the status of this issue to closed (duplicate).

Please ask support questions on Drupal Answers.

https://github.com/drush-ops/drush/issues/160

Hi All,

I am getting an error in updating Drupal from 6.32 to 6.33 using Drush command.

When I execute the command it getting stuck at the terminal for a long time. I have to execute Ctrl + C to release the terminal.

Please find the below Drush status details and command output.

################## drush status ############
Drupal version : 6.32
Site URI : http://default
Database driver : mysqli
Database username : --------------
Database name : --------------
Database : Connected
Drupal bootstrap : Successful
Drupal user : Anonymous
Default theme : --------------
Administration theme : garland
PHP executable : /usr/bin/php
PHP configuration : /etc/php.ini
PHP OS : Linux
Drush version : 6.3.0
Drush configuration :
Drush alias files :
Drupal root : /home/account_name/public_html
Site path : sites/default
File directory path : sites/default/files
Temporary file directory path : /tmp

###################### drush up -vv ##########################

Initialized Drupal 6.32 root directory at /home/dacarlidrupal7/public_html_inside_pubhtml [notice]
Initialized Drupal site default at sites/default [notice]
Loading release_info engine. [notice]
Loading version_control engine. [notice]
Loading package_handler engine. [notice]
Executing: wget --version
/usr/bin/php -d magic_quotes_gpc=Off -d magic_quotes_runtime=Off -d magic_quotes_sybase=Off /home/dacarlidrupal7/drush-6.3.0/drush.php --php=/usr/bin/php [notice]
--php-options=' -d magic_quotes_gpc=Off -d magic_quotes_runtime=Off -d magic_quotes_sybase=Off' --backend=2 --verbose
--root=/home/dacarlidrupal7/public_html_inside_pubhtml --uri=http://default pm-updatestatus 2>&1

Please help in resolving the issue.

Regards,

the issues for drush are now in github.