use drush make with a stub .make file to download a custom profile via git.

that profile has all of the modules I want all of my sites to start out with.

If I then go into that site, and run "drush up drupal", it will update core, and remove my custom profile.

This is not good, since all of the modules I downloaded with my install profile's make file get stuck into the profiles/myprofile/modules folder. This basically removes all of my installed contrib modules, and drush doesn't give me a way to put them any where else, so basically, I can't update core with drush.

Comments

owen barton’s picture

owen barton commented

Looking at updatecode.pm.inc, it looks lie it does try and move any of the original /profiles/* directories that do not exist in the upgraded install back into place, if you are using the backup version control engine. Could you try looking at this (code is _pm_update_move_files($project['backup_target'] . '/profiles', $drupal_root . '/profiles', array('default'), FALSE);) - perhaps that functionality is not working?

I think it's also worth mentioning that the way updating profile updates are generally intended to work is that you update the entire distro (including both core and profile, modules and all). If you use drupal.org as a build system it can produce this for you and drush up should upgrade it as normal.

If not you can still produce your own package just be rerunning drush make in a new directory (changing the version numbers if necessary), but I think you would need to apply the upgrade manually. In theory you should be able to have Drush handle this by running your own update server (as was popular for features for a while), but I expect wiring together distro packaging would likely take a bit of work to set up.

captcodemonkey’s picture

captcodemonkey commented

I ran an update on my test install, and this is the -v output of "drush up drupal"

The backup directory was empty when this finished, and my custom profile was gone. (It did create the folder for the directory, and all this is running as root as there shouldn't be a permission issue).

[root@dev httpdocs]# drush up drupal -v
Initialized Drupal 7.15 root directory at /var/www/vhosts/d7_test/httpdocs [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 /usr/share/pear/drush/drush.php --php=/usr/bin/php --backend=2 --verbose --root=/var/www/vhosts/d7_test/httpdocs --uri=http://default batch-process 2 2 [notice]
2>&1
Initialized Drupal 7.15 root directory at /var/www/vhosts/d7_test/httpdocs [notice]
Initialized Drupal site default at sites/default [notice]
Checking available update data ... [ok]
Checked available update data for Strongarm. [ok]
Checked available update data for Views. [ok]
Checked available update data for Views Slideshow. [ok]
Checked available update data for Weight. [ok]
Checked available update data for Wysiwyg. [ok]
Failed to check available update data for Responsive Slideshow. [ok]
Failed to check available update data for WYSIWYG-ck. [ok]
Checked available update data for Email. [ok]
Checked available update data for GMap. [ok]
Checked available update data for Location. [ok]
Failed to check available update data for Office Directory. [ok]
Checked available update data for Administration Development tools. [ok]
Checked available update data for Block. [ok]
Checked available update data for Bulk Export. [ok]
Checked available update data for Context. [ok]
Checked available update data for Entity API. [ok]
Checked available update data for Entity Reference. [ok]
Checked available update data for Features. [ok]
Checked available update data for Flex Slider. [ok]
Checked available update data for IMCE. [ok]
Checked available update data for IMCE Wysiwyg API bridge. [ok]
Checked available update data for LESS CSS Preprocessor. [ok]
Checked available update data for Libraries. [ok]
Checked available update data for Role delegation. [ok]
Checked available update data for Administration Development tools. [ok]
Checked available update data for Block. [ok]
Checked available update data for Bulk Export. [ok]
Checked available update data for Context. [ok]
Checked available update data for Email. [ok]
Checked available update data for Entity API. [ok]
Checked available update data for Entity Reference. [ok]
Checked available update data for Features. [ok]
Checked available update data for Flex Slider. [ok]
Checked available update data for GMap. [ok]
Checked available update data for IMCE. [ok]
Checked available update data for IMCE Wysiwyg API bridge. [ok]
Checked available update data for LESS CSS Preprocessor. [ok]
Checked available update data for Libraries. [ok]
Checked available update data for Location. [ok]
Failed to check available update data for Office Directory. [ok]
Failed to check available update data for Responsive Slideshow. [ok]
Checked available update data for Role delegation. [ok]
Checked available update data for Strongarm. [ok]
Checked available update data for Views. [ok]
Checked available update data for Views Slideshow. [ok]
Checked available update data for Weight. [ok]
Checked available update data for Wysiwyg. [ok]
Failed to check available update data for WYSIWYG-ck. [ok]
Failed to get available update data for 6 projects. [error]
Checked available update data for 42 projects. [status]
Command dispatch complete [notice]
Undefined index: path drupal.inc:120 [notice]
Update information last refreshed: Sun, 10/07/2012 - 11:23

Update status information on all installed and enabled Drupal projects:
Name Installed version Proposed version Status
Administration menu (admin_menu) 7.x-3.0-rc3 7.x-3.0-rc3 Up to date
Drupal 7.15 7.17 SECURITY UPDATE available
Chaos tools (ctools) 7.x-1.2 7.x-1.2 Up to date
Context (context) 7.x-3.0-beta4 7.x-3.0-beta4 Up to date
Email (email) 7.x-1.2 7.x-1.2 Up to date
Entity API (entity) 7.x-1.0-rc3 7.x-1.0-rc3 Up to date
Entity Reference (entityreference) 7.x-1.0-rc5 7.x-1.0-rc5 Up to date
Features (features) 7.x-1.0 7.x-1.0 Up to date
Flex Slider (flexslider) 7.x-1.0-rc3 7.x-1.0-rc3 Up to date
GMap (gmap) 7.x-1.x-dev 7.x-1.0-beta1 Update available
IMCE (imce) 7.x-1.5 7.x-1.6 Update available
IMCE Wysiwyg API bridge (imce_wysiwyg) 7.x-1.0 7.x-1.0 Up to date
LESS CSS Preprocessor (less) 7.x-2.6 7.x-2.6 Up to date
Libraries (libraries) 7.x-2.0 7.x-2.0 Up to date
Location (location) 7.x-3.0-alpha1 7.x-3.0-alpha1 Up to date
Role delegation (role_delegation) 7.x-1.1 7.x-1.1 Up to date
Strongarm (strongarm) 7.x-2.0 7.x-2.0 Up to date
Views (views) 7.x-3.5 7.x-3.5 Up to date
Views Slideshow (views_slideshow) 7.x-3.0 7.x-3.0 Up to date
Weight (weight) 7.x-2.1 7.x-2.1 Up to date
Wysiwyg (wysiwyg) 7.x-2.2+2-dev 7.x-2.2 Update available

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: svn info /var/www/vhosts/d7_test/httpdocs/drupal-7.17
Executing: bzr root /var/www/vhosts/d7_test/httpdocs/drupal-7.17
Executing: which wget
Executing: wget -q --timeout=30 -O /tmp/download_fileYyu59Z http://ftp.drupal.org/files/projects/drupal-7.17.tar.gz
Downloading drupal-7.17.tar.gz was successful. [notice]
Md5 checksum of drupal-7.17.tar.gz verified. [notice]
Mime type for /var/www/vhosts/d7_test/httpdocs/drupal-7.17.tar.gz is application/x-gzip [notice]
Executing: tar -C /var/www/vhosts/d7_test/httpdocs -xzf drupal-7.17.tar.gz
Executing: tar -tzf drupal-7.17.tar.gz
Project drupal was updated successfully. Installed version is now 7.17.
Backups were saved into the directory /root/drush-backups/dev_d7_test/20121115204719/drupal. [ok]
/usr/bin/php /usr/share/pear/drush/drush.php --php=/usr/bin/php --backend=2 --verbose --root=/var/www/vhosts/d7_test/httpdocs --uri=http://default [notice]
pm-updatecode-postupdate 2>&1
Initialized Drupal 7.17 root directory at /var/www/vhosts/d7_test/httpdocs [notice]
Initialized Drupal site default at sites/default [notice]
'all' cache was cleared in /var/www/vhosts/d7_test/httpdocs#default [success]
GMap is unable to save the marker bundle. Markers will not work! [error]
Command dispatch complete [notice]
You have pending database updates. Run `drush updatedb` or visit update.php in your browser. [warning]
Command dispatch complete [notice]
Rolling back update of Drupal core code ... [notice]
Executing: svn info drupal-7.17
Executing: bzr root drupal-7.17
Backups were restored successfully. [ok]
Command dispatch complete

greg.1.anderson’s picture

greg.1.anderson commented

Output from a --debug run would probably be helpful.

owen barton’s picture

owen barton commented

The clue is here:
Rolling back update of Drupal core code ... [notice]

I think what is happening is that Drush is backing a backup, installing the new core, moving profiles to the new core, then detecting an error (not sure if that is the gmap or updates pending lines?) and rolling back by deleting the new core (including the original profiles directory) and moving the backup directory (with missing profiles) back into place.

captcodemonkey’s picture

captcodemonkey commented

Yes, you are exactly correct as I discovered yesterday.

When drush is updating and that error happens with the gmap module and it rolls back from the backup, it wipes out the custom profile.

If I disable gmap, then drush up core, it preserves the custom profile.

So the issue is really that when a core update is happening, if there is an error, it will wipe out any custom profiles when doing the restore.

(the issue with gmap is happening because it tries to regen the markers during drush up before I can fix the permissions on the directories (drush doesn't run as the right user).

So again, I guess a slight pivot to my original issue, but when updating core with drush, if there is an error and you have a custom profile, when it tries to roll back from the backup it kills any custom profiles.

greg.1.anderson’s picture

greg.1.anderson commented
Title: Way to prevent drush from eating custom profiles when updating core? ("drush up drupal") » Drush does not restore backups correctly under some failure conditions in pm-updatecode

Seems like it would be safer to copy rather than move the profiles et.al. from the backup to the original location. This, however, might have implications vis-a-vis file permissions. Moving profiles et.al. back to the backup before restoring the backup would be convoluted.

What we really need is #759906: Update core without moving core files out of the way..

greg.1.anderson’s picture

greg.1.anderson commented
Version: 7.x-5.7 » 8.x-6.x-dev
Status: Active » Closed (won't fix)
Issue tags: +Needs migration

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.