Cloning Drupal 7 Install on VirtualBox with Vagrant and VDD

I guess folks have been using Vagrant Drupal Development for a few years now to get a good local dev version of a Drupal install going.

Had initially installed locally using MAMP, and I think it had been working, but can’t totally remember. At any rate, after pulling in some of the changes from the git repo, was getting an Apache error:

[Wed Jul 22 13:25:09 2015] [error] [client] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.

An opportunity to play with Vagrant.

Following this VDD tutorial, and with my previous (limited) Vagrant/VirtualBox experience…

Since we’re using Drupal 7 (it was installed over a year ago), obviously I updated the following lines substituting 7 for 8:

git clone --branch 8.0.x .
drush @drupal8 si standard -y

(Man, drupal is large!).

Pretty sweet drush (the Drupal command line library) is automatically installed.


Your PHP installation is too old. Drupal requires at least PHP 5.5.9. See the system requirements page for more information.

Apparently /etc/apache2/mods-enabled/php5.load tells which version of php Apache will load (as long as the version is installed), but all it contains is LoadModule php5_module /usr/lib/apache2/modules/, which doesn’t do much for the point five point nine part.

php --version
PHP 5.4.4

Hmmm. Wait a minute. That’s the same version running on the host machine. Coincidence? Yes. The whole point of running a virtual machine is that it can match a different environment. (But I still had to confirm this by loading another vagrant box, which fortunately was not running the same php version.)

The tutorial’s a couple of years old and the latest “stable” VDD release is over a year old, which may be previous to the upgraded php requirement for Drupal so now I’m running the more recent (dev) release of VDD…

Looks like it runs the same Ubuntu box disc image, which Jamaaladeen (this computer) appreciates, memory-wise.

This time I was prompted for a password as it was installing. Failed three times trying ‘root’, ‘root’ and ‘vagrant’ then got a message ‘sudo: 3 incorrect password attempts’, so maybe I should have entered the sudo passwd for Jamaaladeen.

Great! Same php version in the new one.

As it turns out, Drupal 7 doesn’t require php 5.5.9 (no surprise there!). Maybe that wasn’t the correct git clone command above. Installed a new VDD box with most recent (dev) version of VDD.

Installed Drupal differently this time:

git clone . 
git checkout 7.0

New problems. When running drush @drupal7 si standard -y:

WD php: Warning: Illegal string offset 'field' in DatabaseCondition->__clone() (line 1818 of

/var/www/drupal7/includes/database/ [warning]

Apparently a bug that was addressed in Drupal 7.14. So:

git checkout 7.14

Finally a clean Drupal install on the new box.

Will probably stick with the newer dev version of VDD and run vagrant destroy from the directory of the older one, but let’s wait a minute just in case.

Next step is to get our own Drupal install going in the VirtualBox.

First checked in the live site under Admin->reports->Status Report and we are running Drupal 7.38. Looks like running drush up from the Drupal directory on the VBox might just do the trick to get from 7.14 to 7.38.

Looks like it worked!

Browser address:

Let’s get our code in here:

git remote rename origin drupal
git add remote origin
git checkout -b cleanDrupal7
git checkout -b master
git pull remote
> Permission denied (publickey).
> fatal: The remote end hung up unexpectedly


ssh-keygen -t rsa -b 4096 -C "" #no password
eval "$(ssh-agent -s)"
> Identity added: /home/vagrant/.ssh/id_rsa (/home/vagrant/.ssh/id_rsa)
cat ~/.ssh/

Add it to the repository. Now we can git pull origin.

You asked to pull from the remote 'origin', but did not specify
a branch. Because this is not the default configured remote
for your current branch, you must specify a branch on the command line.

git pull origin dev
> error: Your local changes to the following files would be overwritten by merge:


git fetch --all
git reset --hard origin/dev #made a dev version first with git checkout -b dev

Now to import the MySQL database dump from the server. First let’s backup the clean install version.

mysqldump -u root -p root drupal7 > drupal7_clean.sql
> mysqldump: Got error: 1045: Access denied for user 'root'@'localhost' (using password: YES) when trying to connect

Really? So!

mysqld --skip-grant-tables

This generated some errors and a warning and even said it was aborting, but ended with shutdown complete.

$ mysql -u root mysql
$mysql> UPDATE user SET Password=PASSWORD('my_password') where USER='root';
/etc/init.d/mysql restart
Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service mysql restart

Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the stop(8) and then start(8) utilities,
e.g. stop mysql ; start mysql. The restart(8) utility is also available
service mysql restart
mysqldump -u root -p root drupal7 > drupal7_clean.sql
Enter password: #(root)
mysqldump: Got error: 1049: Unknown database 'root' when selecting the database


mysqldump -u root drupal7 > drupal7_clean.sql
$ ls | grep drupal7_clean


So we’ll drop the original database

$mysql> drop database drupal7;
$mysql> create database drupal7;
$mysql> exit

Now the VDD setup created two symlinced directories between the VBox and the host machine so I can just grab the live_server.sql file we exported yesterday and put it in the data/drupal7 directory on the host machine and there it is in the VBox (~/sites/drupal7) as well.

Fingers crossed…

mysql -u root -p root drupal7 < ltv_live_server.mysql 
    mysql  Ver 14.14 Distrib 5.5.44, for debian-linux-gnu (i686) using readline 6.2
Copyright (c) 2000, 2015, Oracle and/or its affiliates. All rights reserved.
    noise noise noise

$ mysql
> ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)

Again!?!? Wait! Look above – accidentally changed the password the password. Ha.

mysql -u root -p
password: #(password)

Run above command with new password.

$mysql> use drupal7
$mysql> show tables;
>Empty set (0.00 sec)

Not there yet. Maybe what I downloaded wasn’t a sql dump? Open it up. Sure looks like it was.
Maybe having the -p root isn’t necessary here.

$ mysql -u root drupal7 < ltv_live_server.mysql

Took a second or two. Good.

$ mysql
$mysql> use drupal7
$mysql> show tables;
| Tables_in_drupal7                                      |
| actions                          # plus dozens more...

Success. Finally!

Refresh browser window and…

Fatal error: Call to undefined function ctools_include() in /var/www/drupal7/sites/all/modules/context/context.module on line 487

Ah. Wait. We don’t have our profiles directory in the repository.

$ rsync -azP ltv:dev3/profiles/ profiles/ # lowercase p doesn't give progress

Yes. Copying the Profiles directory solved that error. Now we need the files directory.

$ cd sites/default
$ rsync -azP ltv:dev3/sites/default/files files/

Something still amis:

( ! ) Fatal error: Unsupported operand types in /var/www/drupal7/profiles/commerce_kickstart/modules/contrib/entity/includes/ on line 113

 Call Stack
#   Time    Memory  Function    Location
1   0.0001  128316  {main}( )   .../index.php:0
2   1.3996  7361560 menu_execute_active_handler( )  .../index.php:21
3   2.1486  9634848 drupal_deliver_page( )  .../
4   2.1575  9644668 drupal_deliver_html_page( ) .../
5   2.1575  9645216 drupal_page_footer( )   .../
6   2.1707  9855448 system_run_automated_cron( )    .../
7   2.1707  9855508 drupal_cron_run( )  .../system.module:3518
8   2.5012  10503484    module_invoke( )    .../
9   2.5012  10503688    call_user_func_array:{/var/www/drupal7/includes/} ( ) .../
10  2.5012  10503780    commerce_recurring_cron( )  .../
11  2.5012  10503824    rules_invoke_all( ) .../commerce_recurring.module:587
12  2.5069  10504200    rules_invoke_event_by_args( )   .../rules.module:1000
13  2.5135  10750804    RulesEventSet->executeByArgs( ) .../rules.module:1056
14  2.5385  11985940    RulesActionContainer->evaluate( )   .../
15  2.5385  11985964    RulesReactionRule->evaluate( )  .../
16  2.5385  11986296    Rule->evaluate( )   .../
17  2.5447  12063780    RulesActionContainer->evaluate( )   .../
18  2.5447  12063804    RulesAbstractPlugin->evaluate( )    .../
19  2.5533  12088884    RulesAction->executeCallback( ) .../
20  2.5533  12090228    RulesExtendable->__call( )  .../
21  2.5533  12090228    FacesExtendable->__call( )  .../
22  2.5533  12090584    call_user_func_array:{/var/www/drupal7/profiles/commerce_kickstart/modules/contrib/rules/includes/} ( )    .../
23  2.5533  12091128    rules_action_entity_query( )    .../
24  2.5533  12091144    entity_property_query( )    .../

The commerce pages also all seem to have errors and won’t load.

You can view reports in the admin panel under Reports->Recent Log Messages.

What’s my password? And the password reset’s not working yet. Create a new admin with Drush? Lemme just reset the password drush upwd mikek --password="newpassword".

Notice: Undefined index: status in entity_property_query() (line 113 of /var/www/drupal7/profiles/commerce_kickstart/modules/contrib/entity/includes/

Ah! The file permissions on the main config file for the site (sites/default/settings.php) were set to 444 instead of 644.

Now on to Unknown data property commerce_product. in EntityStructureWrapper->getPropertyInfo(). Drupal forums? What are line items, and how do I find them? Ah. “product line item”s. Apparently this is what the Drupal folks are referring to as entity errors. Seems it is likely a database issue and comment #24 on the aformentioned tread proposes a possible solution. “The product reference field, that is installed on the product line item was deactivated (active = 0). The field itself was also locked, so I’m not sure how this happened. By changing the value of active to 1 and clearing cache the error disappeared.”

SELECT * FROM field_config;

mysql> describe field_config;        
| Field          | Type         | Null | Key | Default | Extra          |


mysql> SELECT field_name, active, locked FROM field_config WHERE locked=1;

commerce_line_items is one of the returned items. Hey! “Line items”.

mysql> SELECT * FROM field_config where field_name="commerce_line_items";
mysql> UPDATE field_config SET locked = 0 WHERE field_name="commerce_line_items";

No no no no no. Hmmm. “Failures are easy to recreate if you try to enable a lot of modules at one time, especially if you have the default 30 second PHP max_execution_time.”

Let’s try disabling all the modules with Drush.

drush pml --no-core --type=module --status=enabled --pipe | xargs drush -y dis
#output output output...
>Drush command terminated abnormally due to an unrecoverable error.                              [error]
>Error: Unsupported operand types in /var/www/drupal7/profiles/commerce_kickstart/modules/contrib/entity/includes/, line 113

Hmmm. Back to this error on front end:

( ! ) Fatal error: Call to undefined function page_manager_get_task() in /var/www/drupal7/profiles/commerce_kickstart/modules/contrib/ctools/page_manager/plugins/tasks/ on line 266

Let’s try this one. The ack version didn’t work.

drush pm-list --status=enabled --pipe | grep 'uc_' | xargs -i drush pm-disable '{}' -y

Same error. And on back end:

( ! ) Fatal error: Call to undefined function message_type_access() in /var/www/drupal7/profiles/commerce_kickstart/modules/contrib/entity/entity.module on line 657

Arrgh! Let’s clear the slate.

  • repeat steps from above, delete the drupal7 database and reinstall it from the .sql file.
  • reset the password again.

Yo! It’s working!

I think the problems were likely cause by importing the database before adding the filesystem with which it was intertwined. Better go to bed before I discover any new problems.

At one point when “re-up”ing this install I got error:

Fatal error: Call to undefined function ctools_include() in /sites/all/modules/context/context.module

The solution of which was to move the sites/all/modules directory.
In the terminal, run

drush pm-enable `drush php-eval "echo 'ctools'"`

Which seemed to create a new modules directory containing ctools. But I think the error was actually caused by us having been missing the profiles directory.