Command site-install needs a higher bootstrap level to run - you will need to invoke drush from a more functional Drupal environment to run this command. about blt

[grasmash]

Running the same command manually may give you a different result because running a target via blt.sh may actually execute the command in a different directory than your current working directory. What command did you run? What was the initial error? If it's a drush command, you likely need to execute it from the docroot. Otherwise drush can't find Drupal.

[haynescw]

Its it the drush install site command. Im running it again to get the error output from that for you.

[haynescw]

project > setup:drupal:install:

[drush] Executing '/Users/XXXXX/Documents/Clients/XXXXXX/dev/blted8/vendor/bin/drush @blted8.local --site-name="BLTed 8" --site-mail="[email protected]" --account-name="admin" --account-pass="admin" --account-mail="[email protected]" --l="default" --nocolor --yes --verbose site-install "lightning" "install_configure_form.update_status_module='array(FALSE,FALSE)'"'...

Loaded alias @blted8.local from file /Users/XXXXX/Documents/Clients/XXXXXX/dev/blted8/drush/site-aliases/drupal-vm.aliases.drushrc.php [notice]
Begin redispatch via drush_invoke_process(). [notice]
Calling proc_open(ssh -o PasswordAuthentication=no -i /Users/XXXXX/.vagrant.d/insecure_private_key [email protected] 'env COLUMNS=272 drush --local --alias-path=/Users/XXXXX/Documents/Clients/XXXXXX/dev/blted8/drush/site-aliases --nocolor --yes --verbose --uri=default --root=/var/www/blted8/docroot site-install lightning '''install_configure_form.update_status_module='''''''''array(FALSE,FALSE)'''''''''''' --site-name='''BLTed 8''' --site-mail='''[email protected]''' --account-name=admin --account-pass=admin --account-mail='''[email protected]''' 2>&1' 2>&1);
End redispatch via drush_invoke_process(). [notice]
[drush] [error] Command site-install needs a higher bootstrap level to run - you will need to invoke drush from a more functional Drupal environment to run this command.
[drush] [error] The drush command 'site-install lightning install_configure_form.update_status_module='array(FALSE,FALSE)'' could not be executed.
[phingcall] /Users/XXXXX/Documents/Clients/XXXXXX/dev/blted8/build/core/phing/tasks/setup.xml:73:85: Drush exited with code 1

BUILD FAILED
/Users/XXXXX/Documents/Clients/XXXXXX/dev/blted8/build/core/phing/tasks/local-sync.xml:12:30: Execution of the target buildfile failed. Aborting.

Total time: 42.5293 seconds

[CashWilliams]

Are you running this from the host or from inside the VM?

I have a feeling this is an issue with the drush alias files, as they are not fully ironed out for the VM workflow.

[haynescw]

I am running this from my mac not drupal vm.

[grasmash]

Dumb question, but is the VM running? If you run drush @blted8.local ssh can you login to it?

[haynescw]

An error 1 occurred while running the command `ssh -o PasswordAuthentication=no -i /Users/XXXXX/.vagrant.d/insecure_private_key -t [email protected] 'cd /var/www/blted8/docroot && bash [error]
-l'

[haynescw]

I found the generate config file is wrong, in the section

Provide the path to the project root to Vagrant.

vagrant_synced_folders:

Set the local_path for the first synced folder to ../.

• local_path: .

  Set the destination to the Acquia Cloud subscription machine name.

  destination: /var/www/blted8
  type: nfs

local path needs to be set to ../

[haynescw]

after updating that line, i can ssh with the drush command like you wanted

[haynescw]

Nice, that . to a ../ fixed my issue and it completed the setup task. Thanks @grasmash for thinking of logging in with drush. Really made the difference.

[haynescw]

Dont forget to update that line

[grasmash]

Hm. I've just run the vagrant up command with it set to . and it worked. Changing to ../ causes the same error for me that you described. Strange. I assume that you used blt vm:init to do the initial configuration?

[haynescw]

Yes, I started my entire build from scratch and used all the new changes to the Readme's, which included blt vm:init

[grasmash]

My best guess is that you may have an older version of Vagrant. I've found the default config to work on Vagrant 1.8.1, vagrant -v.

[haynescw]

This was resolved by one of your commits, when i ran the command again,
after starting all over, fresh pull on everything, and changing my nfs
share to ../ ended up with everything working. If that makes sense.

On Thu, Jun 9, 2016 at 9:02 AM, Matthew Grasmick [email protected]
wrote:

My best guess is that you may have an older version of Vagrant. I've found
the default config to work on Vagrant 1.8.1, vagrant -v.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#132 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ADeNGa7308x-O5mVe0pej8xSKsVX_RKDks5qKBzugaJpZM4IxRYD
.

[grasmash]

The part that confuses me is that you shouldn't need to change the nfs share value.

[geerlingguy]

With the latest everything, it should work with .... but maybe @haynescw has an older/not-8.x-latest copy of Bolt/BLT that has some patches applied but others not. Also, Drupal VM had some changes between 2.5.1 -> 3.0.0 -> 3.1.0 that could require some differences with setup.

Note that the way Drupal VM is installed/added on has changed recently too, and the old way required ../ but the current way ..

[grasmash]

I'm pretty sure he generated his project with the most recent version of BLT, which pins Drupal VM to ~3.1 and Drupal ~8.1. So, the only think that I can think of that would be different is Vagrant or Virtual Box.

[haynescw]

To clarify, when i submit my issues, i do my best to start from scratch. Fresh clone of blt and drupalvm. So if I do get an issue on a build, I do a get pull on blt and see if there are changes. if there is I start completely from scratch to abstract myself for old, outdated code.

[kevinquillen]

I also just ran into this very same error.

Are we to run ./blt.sh local:setup from inside the VM, or the hostmachine? Changing the local path did nothing for me. Otherwise I am stuck trying to get BLT to build from the standard setup with lightning.

[grasmash]

@kevinquillen Try removing the -r ${DIR}/docroot from drush.wrapper and let me know if that helps.

[grasmash]

If not, open a new issue and share your log output and configuration.

[kevinquillen]

Running.... that worked. What was the issue there?

On Thu, Jul 21, 2016 at 11:37 AM, Matthew Grasmick <[email protected]

wrote:

If not, open a new issue and share your log output and configuration.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#132 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAWGwIfifHHYx3xZeHtSpnJ97obq2Vqpks5qX5JIgaJpZM4IxRYD
.

[grasmash]

The -r argument tells drush where the docroot is, but that script is using the host machine's filesystem to set the argument value. Within the VM that causes issues. We should remove it from BLT until we find a more dynamic solution.

[sodacrackers]

For anyone else, drush worked for me by using site aliases: drush @mysite.local en some_module -t