I have a site on a D6 platform that I am unable to migrate to a new D6 platform on the same server.
I was originally trying to perform a migrate task in order to achieve an update of some contrib modules, but in trying to resolve the continual failure of the migrate task, I have now manually updated all the modules.
The new platform was built in Aegir using a drush make-file. It verified fine. The migrate has failed every time with a message of "The external command could not be executed due to an application error." when running "/usr/bin/php /var/aegir/drush/drush.php --php='/usr/bin/php' @orgright.co.nz updatedb --backend 2>&1" (see log below).
I have upgrade all modules on the source platform so that it is now identical to the destination platform. The compare platforms list follows:
Package Current Target
admin_menu 6.x-1.8 (6001) 6.x-1.8 (6001)
backup_migrate 6.x-2.4 (2005) 6.x-2.4 (2005)
block 6.22 6.22
ca 6.x-2.7 (6001) 6.x-2.7 (6001)
color 6.22 (6001) 6.22 (6001)
comment 6.22 (6003) 6.22 (6003)
common_fonts 6.x-2.8 6.x-2.8
contact 6.22 6.22
dblog 6.22 (6000) 6.22 (6000)
default 6.22 6.22
fb 6.x-3.1 (6003) 6.x-3.1 (6003)
fbnewton3 Unknown Unknown
fb_app 6.x-3.1 (6302) 6.x-3.1 (6302)
fb_canvas 6.x-3.1 6.x-3.1
fb_connect 6.x-3.1 (6202) 6.x-3.1 (6202)
fb_tab 6.x-3.1 (6300) 6.x-3.1 (6300)
fb_user 6.x-3.1 (6008) 6.x-3.1 (6008)
filter 6.22 6.22
fontyourface 6.x-2.8 (6200) 6.x-2.8 (6200)
garland 6.22 6.22
googleanalytics 6.x-3.3 (6302) 6.x-3.3 (6302)
help 6.22 6.22
jquery_ui 6.x-1.5 6.x-1.5
jquery_update 6.x-2.0-alpha1 (6200) 6.x-2.0-alpha1 (6200)
memcache 6.x-1.9 6.x-1.9
memcache_admin 6.x-1.9 (6001) 6.x-1.9 (6001)
menu 6.22 6.22
node 6.22 6.22
path 6.22 6.22
search 6.22 6.22
system 6.22 (6055) 6.22 (6055)
taxonomy 6.22 6.22
token 6.x-1.16 (1) 6.x-1.16 (1)
typekit_api 6.x-2.8 6.x-2.8
uc_attribute 6.x-2.7 (6005) 6.x-2.7 (6005)
uc_cart 6.x-2.7 (6202) 6.x-2.7 (6202)
uc_cart_links 6.x-2.7 (6001) 6.x-2.7 (6001)
uc_credit 6.x-2.7 (6000) 6.x-2.7 (6000)
uc_order 6.x-2.7 (6019) 6.x-2.7 (6019)
uc_overrides Unknown Unknown
uc_payment 6.x-2.7 (6002) 6.x-2.7 (6002)
uc_payment_pack 6.x-2.7 (6000) 6.x-2.7 (6000)
uc_paypal 6.x-2.7 (6000) 6.x-2.7 (6000)
uc_product 6.x-2.7 (6009) 6.x-2.7 (6009)
uc_recurring 6.x-2.0-alpha6 (6012) 6.x-2.0-alpha6 (6012)
uc_recurring_hosted 6.x-2.0-alpha6 6.x-2.0-alpha6
uc_recurring_product 6.x-2.0-alpha6 (6000) 6.x-2.0-alpha6 (6000)
uc_recurring_subscription 6.x-2.0-alpha6 (6000) 6.x-2.0-alpha6 (6000)
uc_reports 6.x-2.7 (6000) 6.x-2.7 (6000)
uc_spt_hpp 6.x-1.0-alpha1 6.x-1.0-alpha1
uc_store 6.x-2.7 (6006) 6.x-2.7 (6006)
uc_taxes 6.x-2.7 (6003) 6.x-2.7 (6003)
uc_tax_report 6.x-2.7 6.x-2.7
uc_termsofservice 6.x-1.2 (6101) 6.x-1.2 (6101)
uc_vat 6.x-1.2 (6001) 6.x-1.2 (6001)
uc_webform_pane 6.x-3.5 (6204) 6.x-3.5 (6204)
update 6.22 (6000) 6.22 (6000)
user 6.22 6.22
views 6.x-2.12 (6009) 6.x-2.12 (6009)
views_ui 6.x-2.12 6.x-2.12
webform 6.x-3.14 (6329) 6.x-3.14 (6329)
zenright Unknown Unknown
aggregator 6.22 6.22
blog 6.22 6.22
blogapi 6.22 6.22 (6001)
bluemarine 6.22 6.22
book 6.22 6.22 (6000)
chameleon 6.22 6.22
date 6.x-2.7 6.x-2.7 (6005)
date_api 6.x-2.7 6.x-2.7 (6006)
date_locale 6.x-2.7 6.x-2.7
date_php4 6.x-2.7 6.x-2.7
date_popup 6.x-2.7 6.x-2.7 (6001)
date_repeat 6.x-2.7 6.x-2.7
date_timezone 6.x-2.7 6.x-2.7 (5200)
date_tools 6.x-2.7 6.x-2.7
devel 6.x-1.26 (6003) 6.x-1.26 (6003)
devel_generate 6.x-1.26 6.x-1.26
devel_node_access 6.x-1.26 6.x-1.26
drupal 6.22 6.22
fb_devel 6.x-3.1 6.x-3.1
fb_example 6.x-3.1 6.x-3.1 (1)
fb_form 6.x-3.1 6.x-3.1
fb_friend 6.x-3.1 6.x-3.1 (6300)
fb_permission 6.x-3.1 6.x-3.1
fb_registration 6.x-3.1 6.x-3.1
fb_rules 6.x-3.1 6.x-3.1
fb_stream 6.x-3.1 6.x-3.1
fb_test 6.x-3.1 6.x-3.1
fb_user_app 6.x-3.1 6.x-3.1 (6008)
fb_views 6.x-3.1 6.x-3.1
feedback 6.x-2.1 6.x-2.1 (6101)
fontsquirrel 6.x-2.8 6.x-2.8
fonts_com 6.x-2.8 6.x-2.8
forum 6.22 6.22 (6000)
google_fonts_api 6.x-2.8 6.x-2.8 (6200)
kernest 6.x-2.8 6.x-2.8
locale 6.22 6.22 (6006)
local_fonts 6.x-2.8 6.x-2.8
marvin 6.22 6.22
memcache_test 6.x-1.9 6.x-1.9
minnelli 6.22 6.22
newton3 Unknown Unknown
openid 6.22 6.22 (6000)
php 6.22 6.22
ping 6.22 6.22
poll 6.22 6.22
print 6.x-1.12 6.x-1.12 (6007)
print_mail 6.x-1.12 6.x-1.12 (6007)
print_pdf 6.x-1.12 6.x-1.12 (6007)
profile 6.22 6.22
pushbutton 6.22 6.22
rules 6.x-1.4 6.x-1.4 (6005)
rules_admin 6.x-1.4 6.x-1.4 (6002)
rules_forms 6.x-1.4 6.x-1.4 (6001)
rules_scheduler 6.x-1.4 6.x-1.4 (6100)
rules_test 6.x-1.4 6.x-1.4
schema 6.x-1.7 6.x-1.7
statistics 6.22 6.22 (6000)
support 6.x-1.4 6.x-1.4 (6007)
support_charts 6.x-1.4 6.x-1.4
support_mailcmd 6.x-1.4 6.x-1.4
syslog 6.22 6.22
test_gateway 6.x-2.7 6.x-2.7
throttle 6.22 6.22
tokenSTARTER 6.x-1.16 6.x-1.16
token_actions 6.x-1.16 6.x-1.16
token_test 6.x-1.16 6.x-1.16
tracker 6.22 6.22
translation 6.22 6.22
trigger 6.22 6.22
uc_2checkout 6.x-2.7 6.x-2.7
uc_authorizenet 6.x-2.7 6.x-2.7
uc_catalog 6.x-2.7 6.x-2.7
uc_cybersource 6.x-2.7 6.x-2.7
uc_file 6.x-2.7 6.x-2.7 (6007)
uc_flatrate 6.x-2.7 6.x-2.7 (6003)
uc_googleanalytics 6.x-2.7 6.x-2.7
uc_google_checkout 6.x-2.7 6.x-2.7 (6004)
uc_product_kit 6.x-2.7 6.x-2.7 (6003)
uc_quote 6.x-2.7 6.x-2.7 (6004)
uc_recurring_mock_gateway 6.x-2.0-alpha6 6.x-2.0-alpha6
uc_recurring_order 6.x-2.0-alpha6 6.x-2.0-alpha6 (6000)
uc_roles 6.x-2.7 6.x-2.7 (6004)
uc_shipping 6.x-2.7 6.x-2.7 (6006)
uc_stock 6.x-2.7 6.x-2.7 (6000)
uc_ups 6.x-2.7 6.x-2.7 (6000)
uc_usps 6.x-2.7 6.x-2.7 (6001)
uc_weightquote 6.x-2.7 6.x-2.7 (6002)
upload 6.22 6.22
views_export 6.x-2.12 6.x-2.12
zen 6.x-2.1 6.x-2.1
Go back
The migrate task output log follows:
Log message
Task starts processing
Undefined variable: additions hosting_client.module:882
Running: /usr/bin/php /var/aegir/drush/drush.php --php='/usr/bin/php' @orgright.co.nz provision-migrate '@platform_orgRightWebsite11Drupal622' --backend 2>&1
Bootstrap to phase 0.
Drush bootstrap phase : _drush_bootstrap_drush()
Load alias @orgright.co.nz
Loading drushrc "/var/www/orgright/website-1.0-6.22/sites/orgright.co.nz/drushrc.php" into "site" scope.
Bootstrap to phase 1.
Drush bootstrap phase : _drush_bootstrap_drupal_root()
Loading drushrc "/var/www/orgright/website-1.0-6.22/drushrc.php" into "drupal" scope.
Initialized Drupal 6.22 root directory at /var/www/orgright/website-1.0-6.22
Found command: provision-migrate (commandfile=provision)
Initializing drush commandfile: drush_make
Initializing drush commandfile: drush_make_d_o
Initializing drush commandfile: provision
Load alias @server_localhost
Load alias @server_master
Loading apache driver for the http service
Loading mysql driver for the db service
Load alias @platform_orgRightWebsite10Drupal622
Initializing drush commandfile: user
Including /var/aegir/.drush/provision/db/migrate.provision.inc
Including /var/aegir/.drush/provision/http/migrate.provision.inc
Including /var/aegir/.drush/provision/platform/migrate.provision.inc
Drush bootstrap phase : _drush_bootstrap_drupal_site()
Initialized Drupal site orgright.co.nz at sites/orgright.co.nz
Loading drushrc "/var/www/orgright/website-1.0-6.22/sites/orgright.co.nz/drushrc.php" into "site" scope.
Putting site under maintenance
Template loaded: /var/aegir/.drush/provision/platform/provision_drupal_settings.tpl.php
Changed permissions of /var/www/orgright/website-1.0-6.22/sites/orgright.co.nz/settings.php to 640
Generated config Drupal settings.php file
Changed permissions of /var/www/orgright/website-1.0-6.22/sites/orgright.co.nz/settings.php to 440
Change group ownership of /var/www/orgright/website-1.0-6.22/sites/orgright.co.nz/settings.php to apache
Including /var/aegir/.drush/provision/db/backup.provision.inc
Including /var/aegir/.drush/provision/platform/backup.provision.inc
Drush bootstrap phase : _drush_bootstrap_drupal_configuration()
Adding sites directory to /var/aegir/backups/orgright.co.nz-20111028.164002.tar.gz
Temporarily uncloaking database credentials for backup
Template loaded: /var/aegir/.drush/provision/platform/provision_drupal_settings.tpl.php
Changed permissions of /var/www/orgright/website-1.0-6.22/sites/orgright.co.nz/settings.php to 640
Generated config Drupal settings.php file
Changed permissions of /var/www/orgright/website-1.0-6.22/sites/orgright.co.nz/settings.php to 440
Change group ownership of /var/www/orgright/website-1.0-6.22/sites/orgright.co.nz/settings.php to apache
Re-cloaking database credentials after backup
Template loaded: /var/aegir/.drush/provision/platform/provision_drupal_settings.tpl.php
Changed permissions of /var/www/orgright/website-1.0-6.22/sites/orgright.co.nz/settings.php to 640
Generated config Drupal settings.php file
Changed permissions of /var/www/orgright/website-1.0-6.22/sites/orgright.co.nz/settings.php to 440
Change group ownership of /var/www/orgright/website-1.0-6.22/sites/orgright.co.nz/settings.php to apache
Deleted mysql dump from sites directory
Backed up site up to /var/aegir/backups/orgright.co.nz-20111028.164002.tar.gz.
Client backup directory for admin path /var/aegir/clients/admin/backups exists.
Client backup directory for admin ownership of /var/aegir/clients/admin/backups has been changed to aegir.
Client backup directory for admin permissions of /var/aegir/clients/admin/backups have been changed to 750.
Client backup directory for admin path /var/aegir/clients/admin/backups is writable.
Created symlink /var/aegir/backups/orgright.co.nz-20111028.164002.tar.gz to /var/aegir/clients/admin/backups/orgright.co.nz-20111028.164002.tar.gz
Load alias @platform_orgRightWebsite11Drupal622
Running: /usr/bin/php /var/aegir/drush/drush.php --php='/usr/bin/php' --uri='orgright.co.nz' --platform='@platform_orgRightWebsite11Drupal622' --root='/var/www/orgright/website-1.1-6.22' --profile='default' provision-save '@orgright.co.nz' --backend 2>&1
Bootstrap to phase 0.
Drush bootstrap phase : _drush_bootstrap_drush()
Bootstrap to phase 0.
Found command: provision-save (commandfile=provision)
Initializing drush commandfile: drush_make
Initializing drush commandfile: drush_make_d_o
Initializing drush commandfile: provision
Load alias @self
Load alias @server_master
Loading apache driver for the http service
Initializing drush commandfile: user
Load alias @orgright.co.nz
Loading drushrc "/var/www/orgright/website-1.0-6.22/sites/orgright.co.nz/drushrc.php" into "site" scope.
Load alias @server_localhost
Loading mysql driver for the db service
Load alias @platform_orgRightWebsite11Drupal622
Template loaded: /var/aegir/.drush/provision/provision_drushrc_alias.tpl.php
Changed permissions of /var/aegir/.drush/orgright.co.nz.alias.drushrc.php to 600
Generated config Drush configuration file
Changed permissions of /var/aegir/.drush/orgright.co.nz.alias.drushrc.php to 400
Command dispatch complete
Peak memory usage was 9.98 MB
Running: /usr/bin/php /var/aegir/drush/drush.php --php='/usr/bin/php' --old_uri='orgright.co.nz' @orgright.co.nz provision-deploy '/var/aegir/backups/orgright.co.nz-20111028.164002.tar.gz' --backend 2>&1
Bootstrap to phase 0.
Drush bootstrap phase : _drush_bootstrap_drush()
Load alias @orgright.co.nz
Bootstrap to phase 1.
Drush bootstrap phase : _drush_bootstrap_drupal_root()
Loading drushrc "/var/www/orgright/website-1.1-6.22/drushrc.php" into "drupal" scope.
Initialized Drupal 6.22 root directory at /var/www/orgright/website-1.1-6.22
Found command: provision-deploy (commandfile=provision)
Initializing drush commandfile: drush_make
Initializing drush commandfile: drush_make_d_o
Initializing drush commandfile: provision
Load alias @server_localhost
Load alias @server_master
Loading apache driver for the http service
Loading mysql driver for the db service
Load alias @platform_orgRightWebsite11Drupal622
Initializing drush commandfile: user
Including /var/aegir/.drush/provision/db/deploy.provision.inc
Including /var/aegir/.drush/provision/http/deploy.provision.inc
Including /var/aegir/.drush/provision/platform/deploy.provision.inc
Deploying site from /var/aegir/backups/orgright.co.nz-20111028.164002.tar.gz
Granting privileges to orgrightconz_0@localhost on orgrightconz_0
Created orgrightconz_0 database
Running: gunzip -c /var/aegir/backups/orgright.co.nz-20111028.164002.tar.gz | tar pxf - in /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz
Successfully extracted the contents of /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz
Changed group ownership of files in /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/files to apache
Template loaded: /var/aegir/.drush/provision/provision_drushrc_site.tpl.php
Changed permissions of /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/drushrc.php to 600
Generated config Site Drush configuration file
Changed permissions of /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/drushrc.php to 400
Drush bootstrap phase : _drush_bootstrap_drupal_site()
Initialized Drupal site orgright.co.nz at sites/orgright.co.nz
Loading drushrc "/var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/drushrc.php" into "site" scope.
Template loaded: /var/aegir/.drush/provision/platform/provision_drupal_settings.tpl.php
Changed permissions of /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/settings.php to 640
Generated config Drupal settings.php file
Changed permissions of /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/settings.php to 440
Change group ownership of /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/settings.php to apache
Found database dump at /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/database.sql.
Database dump at /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/database.sql is readable
Importing database using command: mysql --defaults-file=/dev/fd/3 orgrightconz_0
Changed permissions of sites/orgright.co.nz to 755
Changed permissions of sites/orgright.co.nz/themes to 2775
Changed permissions of sites/orgright.co.nz/modules to 2775
Changed permissions of sites/orgright.co.nz/libraries to 2775
Changed permissions of sites/orgright.co.nz/files to 2770
Changed permissions of sites/orgright.co.nz/files/tmp to 2770
Changed permissions of sites/orgright.co.nz/files/images to 2770
Changed permissions of sites/orgright.co.nz/files/pictures to 2770
Changed permissions of sites/orgright.co.nz/files/css to 2770
Changed permissions of sites/orgright.co.nz/files/js to 2770
Changed permissions of sites/orgright.co.nz/files/ctools to 2770
Changed permissions of sites/orgright.co.nz/files/imagecache to 2770
Changed permissions of sites/orgright.co.nz/files/locations to 2770
Changed permissions of sites/orgright.co.nz/private to 2770
Changed permissions of sites/orgright.co.nz/private/files to 2770
Changed permissions of sites/orgright.co.nz/private/temp to 2770
Changed group ownership of sites/orgright.co.nz/files to apache
Changed group ownership of sites/orgright.co.nz/files/tmp to apache
Changed group ownership of sites/orgright.co.nz/files/images to apache
Changed group ownership of sites/orgright.co.nz/files/pictures to apache
Changed group ownership of sites/orgright.co.nz/files/css to apache
Changed group ownership of sites/orgright.co.nz/files/js to apache
Changed group ownership of sites/orgright.co.nz/files/ctools to apache
Changed group ownership of sites/orgright.co.nz/files/imagecache to apache
Changed group ownership of sites/orgright.co.nz/files/locations to apache
Changed group ownership of sites/orgright.co.nz/private to apache
Changed group ownership of sites/orgright.co.nz/private/files to apache
Changed group ownership of sites/orgright.co.nz/private/temp to apache
Removed dump file /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/database.sql after restoring from it
Template loaded: /var/aegir/.drush/provision/http/apache/vhost.tpl.php
Generated config virtual host configuration file
apache on arcturus.mainspring.co.nz has been restarted
Running: /usr/bin/php /var/aegir/drush/drush.php --php='/usr/bin/php' @orgright.co.nz updatedb --backend 2>&1
The external command could not be executed due to an application error. <<<<============
Bootstrap to phase 0.
Drush bootstrap phase : _drush_bootstrap_drush()
Load alias @orgright.co.nz
Loading drushrc "/var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/drushrc.php" into "site" scope.
Bootstrap to phase 2.
Drush bootstrap phase : _drush_bootstrap_drupal_root()
Loading drushrc "/var/www/orgright/website-1.1-6.22/drushrc.php" into "drupal" scope.
Initialized Drupal 6.22 root directory at /var/www/orgright/website-1.1-6.22
Drush bootstrap phase : _drush_bootstrap_drupal_site()
Initialized Drupal site orgright.co.nz at sites/orgright.co.nz
Loading drushrc "/var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/drushrc.php" into "site" scope.
Found command: updatedb (commandfile=core)
Initializing drush commandfile: drush_make
Initializing drush commandfile: drush_make_d_o
Initializing drush commandfile: provision
Load alias @server_localhost
Load alias @server_master
Loading apache driver for the http service
Loading mysql driver for the db service
Load alias @platform_orgRightWebsite11Drupal622
Initializing drush commandfile: user
Drush bootstrap phase : _drush_bootstrap_drupal_configuration()
Drush bootstrap phase : _drush_bootstrap_drupal_database()
Successfully connected to the Drupal database.
Drush bootstrap phase : _drush_bootstrap_drupal_full()
Drush bootstrap phase : _drush_bootstrap_drupal_login()
Drush command terminated abnormally due to an unrecoverable error. Error: Call to undefined function user_load() in /var/aegir/drush/drush.php, line 235
Drush was not able to start (bootstrap) Drupal. Hint: This error can only o... (Expand)
Drush was not able to start (bootstrap) the Drupal database. Hint: This err... (Expand)
could not bootstrap drupal after updatedb
Template loaded: /var/aegir/.drush/provision/http/apache/vhost.tpl.php
Generated config virtual host configuration file
apache on arcturus.mainspring.co.nz has been restarted
Changes made in drush_http_post_provision_deploy have been rolled back.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/themes directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/libraries directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/modules directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/files/locations directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/files/css directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/files/images directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/files/backup_migrate/manual directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/files/backup_migrate/scheduled directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/files/backup_migrate directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/files/ctools directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/files/imagecache directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/files/pictures directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/files/orgRight/css directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/files/orgRight/images/arch-old directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/files/orgRight/images/service-old directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/files/orgRight/images/arch directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/files/orgRight/images/service directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/files/orgRight/images directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/files/orgRight/backup/scheduled directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/files/orgRight/backup directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/files/orgRight/debug directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/files/orgRight/projects directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/files/orgRight/js directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/files/orgRight directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/files/fontyourface directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/files/js directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/files/tmp directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/files directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/private/files directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/private/temp directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz/private directory successful.
Deleting /var/www/orgright/website-1.1-6.22/sites/orgright.co.nz directory successful.
Changes made in drush_provision_drupal_pre_provision_deploy have been rolled back.
Dropping database orgrightconz_0
Revoking privileges of orgrightconz_0@localhost from orgrightconz_0
Changes made in drush_db_pre_provision_deploy have been rolled back.
Command dispatch complete
Peak memory usage was 11.44 MB
Running: /usr/bin/php /var/aegir/drush/drush.php --php='/usr/bin/php' --platform='@platform_orgRightWebsite10Drupal622' provision-save '@orgright.co.nz' --backend 2>&1
Bootstrap to phase 0.
Drush bootstrap phase : _drush_bootstrap_drush()
Bootstrap to phase 0.
Found command: provision-save (commandfile=provision)
Initializing drush commandfile: drush_make
Initializing drush commandfile: drush_make_d_o
Initializing drush commandfile: provision
Load alias @self
Load alias @server_master
Loading apache driver for the http service
Initializing drush commandfile: user
Load alias @orgright.co.nz
Load alias @server_localhost
Loading mysql driver for the db service
Load alias @platform_orgRightWebsite10Drupal622
Template loaded: /var/aegir/.drush/provision/provision_drushrc_alias.tpl.php
Changed permissions of /var/aegir/.drush/orgright.co.nz.alias.drushrc.php to 600
Generated config Drush configuration file
Changed permissions of /var/aegir/.drush/orgright.co.nz.alias.drushrc.php to 400
Command dispatch complete
Peak memory usage was 8.76 MB
Changes made in drush_provision_drupal_provision_migrate have been rolled back.
Bringing site out of maintenance
Template loaded: /var/aegir/.drush/provision/platform/provision_drupal_settings.tpl.php
Changed permissions of /var/www/orgright/website-1.0-6.22/sites/orgright.co.nz/settings.php to 640
Generated config Drupal settings.php file
Changed permissions of /var/www/orgright/website-1.0-6.22/sites/orgright.co.nz/settings.php to 440
Change group ownership of /var/www/orgright/website-1.0-6.22/sites/orgright.co.nz/settings.php to apache
Removed unused migration site package
Template loaded: /var/aegir/.drush/provision/http/apache/vhost.tpl.php
Generated config virtual host configuration file
apache on arcturus.mainspring.co.nz has been restarted
Changes made in drush_provision_drupal_pre_provision_migrate have been rolled back.
Template loaded: /var/aegir/.drush/provision/http/apache/vhost.tpl.php
Generated config virtual host configuration file
Changes made in drush_http_pre_provision_migrate have been rolled back.
Command dispatch complete
Peak memory usage was 12.67 MB
Command dispatch complete
Peak memory usage was 23.31 MB
Using the command line to run the offending command against the source site (without of course the "--backend" parameter) showed that it ran perfectly. There are no database updates to be done. What does that indicate?
I have used mysql command line tools to dump that database, create a new database and import the dump into the new database, then edited the file "/var/aegir/config/server_master/apache/vhost.d/orgright.co.nz" to use the new database and credentials. Browsing to the site confirms that the new database is being used. Still a migrate task fails with the same error.
I don't believe that it is a problem with my Aegir configuration, as I have other platforms, one of which is hosting a couple of dozen sites, which I have been able upgrade through migrating to a new platform without problems.
I have tried disabling all contrib modules and themes on my site prior to migrating, but this did not make any difference.
I am now at a bit of a loss on what to do next.
Comment | File | Size | Author |
---|---|---|---|
#25 | provision-show_mysqldump_errors_during_backups-1324466-25.patch | 8.37 KB | ergonlogic |
#18 | aegir_import.sh_.info | 2.29 KB | wamilton |
Comments
Comment #0.0
jlscott CreditAttribution: jlscott commentedEmphasised the failure message
Comment #1
Dane Powell CreditAttribution: Dane Powell commentedMarked #1328334: Can't migrate using Aegir- Drush command failed. Call to undefined function user_load as duplicate.
Comment #2
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedI thought that this was just for one type of installation profiles.
it is for all of them.
I can't clone anymore :( I am on 1.5
Comment #3
Steven Jones CreditAttribution: Steven Jones commentedSorry I'd missed this one, looks like this has been a bug for a while. Drush 4.5 changed the way it bootstrapped it seems, I wonder if this changed things.
Comment #4
Steven Jones CreditAttribution: Steven Jones commentedOkay, so to the people getting this error, can you reproduce it with a very simple platform, i.e. can you do it with just Drupal core (+ a few contrib modules maybe) if so, could you post the makefile possibly. I can't reproduce this.
Comment #5
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedon a brand new platform and site it seems to work fine.
if I upgraded from a previous version, in my case version 1.4 to 1.5, those sites are not being copied or migrated.
is there an easy way to recreate a platform and all of its sites if I need to re-install?
Comment #6
Steven Jones CreditAttribution: Steven Jones commented@SocialNicheGuru okay, well I can do an upgrade to test this really easily, what's the simplest platform you have where this is broken, and can you share the make file at all?
Comment #7
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedOk. I just tried it.
for me there seems to be an issue with upgrading sites from Aegir from 1.4 to 1.5.
I had sites on Aegir 1.4
I upgraded
Then I could not migrate, clone, etc
I just created a new Aegir install
I created a site of the same name
imported the database and I can clone just fine.
Comment #8
Steven Jones CreditAttribution: Steven Jones commentedOkay, trying to reproduce this...
Comment #9
Steven Jones CreditAttribution: Steven Jones commentedI can't reproduce this.
@SocialNicheGuru what error messages are you seeing? Would it be possible to paste some of the logging output here?
Comment #10
Anonymous (not verified) CreditAttribution: Anonymous commentedComment #11
jlscott CreditAttribution: jlscott commentedOK. I can now migrate the website without problems.
I made a backup of the database and the site files directory structure. I then deleted the site, dropped the database and removed all of the associated directories.
Next, I created a new empty site using the same URL, and (external to Aegir) imported the database and copied the files directory structure onto the new site.
Since then, I have been able to migrate the site onto a new platform that was built by Aegir using a makefile.
So it seems that there was something in the settings or database structure that was causing the original problem.
Thanks for the comments.
Comment #12
Anonymous (not verified) CreditAttribution: Anonymous commentedThanks. I'm guessing something iffy in the drushrc.php like incorrect database credentials were preventing the site to connect to the database after deployment of the tarball - maybe it wasn't able to update the drushrc.php with the new credentials and was trying to use the old ones (which probably didn't work because that old database had been removed). But just can't think of a way that that could occur.
Not sure though, and still can't reproduce. Please reopen or open a new ticket if the issue comes up again. Thanks for getting back to us!
Comment #13
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedmig, that is exactly what it was. the password for the database in the crush file in settings did not match what was in the config directory.
Comment #14
omega8cc CreditAttribution: omega8cc commentedI was able to reproduce this issue a few times and to find the source of the problem.
The failed task log was exactly the same, with the line:
Drush command terminated abnormally due to an unrecoverable error. Error: Call to undefined function user_load()
It was a site imported from some standalone Ubercart install, so it included also sql views, but owned by db user with required privileges existing on the old system, while no such user exists on the Aegir server.
The steps to reproduce and debug the problem with Ubercart based site:
1. Create an empty site in Aegir with expected domain.
2. Upload files and import the database dump exported from previous server.
3. Try to rename the site with Migrate task to get paths rewritten. (it will fail)
4. Try to use Backup task in Aegir. (surprise! it will work)
So where is the problem and why Backup task works?
The problem is that Aegir Backup task will create backup archive with *empty* database.sql file!
It will look like this:
No wonder it must fail when such a pseudo-backup is used as a part of the Clone or Migrate task, hence the errors looking exactly as the one reported at the top of this issue - because the real problem remains hidden.
Next step:
5. Try to export the database from the site where we just imported it in the step #2 above.
The result:
Ouch!
Let's try to find this in the database dump we have imported:
Hah.
Now, as you probably know, we have a nice solution for this kind of issues in the function
generate_dump()
:But it doesn't work and the old
DEFINER
is not removed when we use Backup or Clone or Migrate task on a site with manually imported database including oldDEFINER
. This looks like a serious bug, no? Especially with Aegir happily proceeding when it should fail, because database export failed and is empty!To get it to work we need to remove this
DEFINER
manually:Now we need to import old_data.sql again and now
DEFINER
will be reset to the default working in the Aegir server, in my case it isroot@localhost
instead ofold_data_acct@%
.Now the problem is gone.
How to fix this in the Aegir code?
Comment #15
jlscott CreditAttribution: jlscott commented@omega8cc - great work! Thanks for finding this.
What I think this means is that my reporting the problem fixed in #11 is only true for as long as the site remains on the same server (where the non-standard sql user exists). However, If I migrate to another server, the problem will probably re-appear.
It would seem that until a fix is in Aegir, then a note in the handbook would be really useful.
Comment #16
remco75 CreditAttribution: remco75 commentedI have run into the same bug, But i don;t think the conditions are the same as omega8cc described. This is a site that I've been managing with aegir for a long time (since aegir 1.0 at least)
Migrating and cloning never was a problem.
Since (I think 1.6) only this site I cannot clone or migrate anymore; not to the same server and not to the master server (the site is running on a remote server.
het the output of the failed migrate task:
Comment #17
wamilton CreditAttribution: wamilton commentedI am using a mac. I realize the UNIX implementation is different from most other *nix'es.
I can confirm that this case is not limited to the DEFINER issue that omega8cc reports:
`grep -i mydump.sql definer`
in my case returns nothing at all, and I actually get a completely empty database.sql file when I invoke provision-backup for this site.This site is also a D6 site with Ubercart. The way I created the db is by invoking
`drush si`
followed by`drush sqlc < dump.sql`
in the sites/default directory of the platform I'm importing and then invokingprovision-save
for platform and site and then invokingprovision-import
for the site. The site_path in the site alias points to the new site directory that was created byprovision-import
, which has a settings.php file with the Ægir lines and the db info array and d6 db urls.In my case, I can even invoke by hand:
and I actually get an actionable dump. Same for
drush @sitealias sql-dump
.I tested to make sure the
proc_open
wasn't having trouble with/dev/fd/3
and it seems fine, although trying ls that fd gives me the 'bad fd' error.Furthermore, if I just change out the line that generates the dump for the insecure
`drush sql-dump`
, everything goes swimmingly and my updates get applied and I'm super happy.I have attached the bash script I am using that completes the migration without error with the change to
provisionService_db_mysql::generate_dump
to force it to use regular drush sql-dump, but fails without that change. You will need to give it some platform names, a makefile for the platform to which to migrate, tarball names and a URI, and put the tarballs in/var/aegir/tarballs
.Comment #18
wamilton CreditAttribution: wamilton commentedahem
using .info suffix so I can upload.
Comment #19
wamilton CreditAttribution: wamilton commentedMy problem was actually a '#' in my db password. Here's that issue and a patch: http://drupal.org/node/1741814.
Comment #20
Steven Jones CreditAttribution: Steven Jones commentedSo we're back to the issue in #14, and I'm really not sure how to fix that, suggestions welcome.
Comment #20.0
Steven Jones CreditAttribution: Steven Jones commentedHighlight error message
Comment #21
ergonlogicI believe the problem is more general. A failed mysqldump is not detected, I believe because the output is piped directly to tar. I've seen this when mysql crashes, and leaves some inconsistent tables (only a .frm). Mysql thinks there ought to be a table, but with a missing .idb, the mysqldump crashes at that point. The backup, however, is marked as successful. We now have the very dangerous situation of having given the user a false sense of security. I've seen this most frequently with cache tables (admin_menu, I'm looking at you...) The database dump is entirely useless, as it ends very early in the process; long before such essential tables as 'system' or 'node_revisions'.
Comment #22
ergonlogicThe issue that I'm seeing cause this is #2135373: Admin_menu cache breaks 'drush sql-dump'?.
Comment #23
ergonlogicWe (mostly @anarcat) has posted a fix in the 'dev/mysqldump-error-check' branch. I'll test/re-factor a bit before merging into 3.x. It looks like this bug was introduced in 1.1, so we should really look at backporting this to 2.x, at least.
Setting to 'needs review' to get some additional testing.
Comment #24
ergonlogicRelated IRC discussion: http://hefring.mig5.net/bot/log/aegir/2015-04-16#T563385
Comment #25
ergonlogicI've fixed this up, and added an alter hook to allow regexes to be added or changed. From my very limited testing, this appears to be somewhat faster than piping through sed twice. I'm going to merge this into 3.x, since my own testing shows it to be working, and to get broader testing.
Since this issue affects 2.x as well, I suggest we backport it. I've attached a patch to make this a bit easier.
Comment #27
ar-jan CreditAttribution: ar-jan commentedDo you know if there's a difference between how backslashes are handled with plain sed vs php/drush? Because with plain sed the command
s|/\\*!50017 DEFINER=`[^`]*`@`[^`]*`\s*\\*/||g'
does not work (1), and should bes|/\*!50017 DEFINER=`[^`]*`@`[^`]*`\s*\*/||g'
instead (no double backslahses).(1) At least in my testing with GNU sed version 4.2.1.
(Coming form https://github.com/omega8cc/boa/pull/672)
Comment #28
ergonlogic@ar-jan: Not really sure; I just stuck with what was already there. It should be easier to test now though, and the regexes are now isolated in
Provision_Service_db_mysql::get_regexes()
, and can be overwritten or added to usinghook_provision_mysql_regex_alter(&$regexes)
BTW, I merged these changes (along with those from #1926520: Support Server Name Indication (SNI) for SSL) into the 6.x-2.x-backports branch, and I'm running them in production. This branch should otherwise be identical to 6.x-2.3, and so safe to test for anyone looking to get this fix.
Comment #30
helmo CreditAttribution: helmo at Initfour websolutions commentedI see a regression in our test suite...
See full log for more details.
PS: could be related to #2479345: Race condition in provision-save gives errors via test suite
Comment #31
anarcat CreditAttribution: anarcat commentedi think ar-jan is correct here: we escape too much. we'll followup on this in #2479885: Access denied; you need (at least one of) the SUPER privilege(s) for this operation .
Comment #32
ergonlogicRecent debugging and re-factoring has stabilized this. Feel free to set to 'Patch (to be ported)', if anyone is sufficiently motivated to back-port this to 6.x-2.x
Comment #33
PolHello all,
I think this change is causing a failure at this line: https://github.com/nodeone/provision-quickmigrate/blob/master/provision_...
I will have a bit more time in the following days to investigate, I'll let you know.
Comment #34
anarcat CreditAttribution: anarcat commentedplease do not reopen older issues without a good reason. this bugfix was to work around issues with mysqldump crashing that would be ignored by the old pipeline. that has been fixed. if this fix causes a regression some place else (in your case, in contrib), please open a separate bug report. thanks.
Comment #35
PolOk, sorry.