We’re happy to hear it. When people post on the forum with just an error and say “This is the error message I get. I’m not sure what do do here.”, we don’t know any of that. We also don’t have much to go on to help you.
Hey @swalkinshaw, Yes it follows the directory and the system requirements are installed. Under the
current directory there was just an empty directory called
web and a
.env file with the correct variables for the db_password, site, login and all that…but that was it. No composer file…am I to manually install or create one there too, b/c the docs make no mention of that.
I understand @kalenjohnson that you don’t have much to go to help me, which is why I would expect follow up questions from people who do know what they are doing to help me figure it out. I am learning this Roots toolset, I’m following the docs to a “t”, and when I or others post an error and only saying “I don’t know what to do here”, it’s b/c it’s all I got back from the computer too. I don’t know what else more I can say or what other information I can give, much less what to look for, unless I’m asked so I can provide it. An alternative I can think of is just writing a huge page full of what could be unrelated info like the machine I’m on or editor or whatever. I like what @swalkinshaw did and gave me something to look for so I can help me help me, I much prefer that than people seeing my simple error code and question and just moving on. I don’t know…I’m just really frustrated. ha
This means that Vagrant shared folder feature hasn’t worked apparently. Vagrant “shares” (syncs) the root directory on your host machine to the virtual machine. If that isn’t working, nothing will.
Please do the following in your trellis project directory:
rm -rf .vagrant
Then copy and paste the entire Vagrant log in here.
I tried those commands but now nothing at all shows up beneath the /srv/ directory
I’m getting the vagrant log
Where would I find the log you need at? I’m still unfamiliar with this Vagrant software, having second thoughts
Just to triple check, and I think the answer is yes, but does your mac (the “host” machine; not the VM) have the bedrock files in
example.com/site directory, including the
composer.json file? See discussion (and how
local_path variable functions). If the files are not there, you need to clone bedrock to that
site directory and
vagrant reload --provision
If the files (including
composer.json) are present in the
site directory on your mac (host machine), it indeed suggests a problem with the syncing of
site into the VM at
current. You mentioned that the “etc/hosts address has been uncommented.” I hope that means you do have a
127.0.0.1 localhost entry in your
/etc/hosts, which would affect whether the nfs sync dirs work (details). If you had to uncomment or add this entry, you may then need to repeat some steps you’ve tried such as vagrant destroy, double-check
/etc/exports, etc., maybe even uninstall and reinstall vagrant.
As for vagrant log, you could just post the output that appears in your console when you run
vagrant up. In rare cases of investigating tricky vagrant issues, you can boost the verbosity of the vagrant output, e.g., with
vagrant up --debug (vagrant debugging details), which also mention option to output to log file:
vagrant up --debug &> vagrant.log).
I do not see the same
composer.json issue when I do a fresh
vagrant up with the same specs:
System info: Ansible 220.127.116.11; Vagrant 2.0.1; Darwin Trellis at "Fix `raw_vars` functionality for Ansible 2.4.1"
Here is a link to a gist of the vagrant log/output on my console right before the error: https://gist.github.com/adrianvalenz/c71b9e41626cedebece1c264d3e3c3e6
I tried making a new site and I really don’t know what is going on.
@fullyint I’m about to read your latest reply now
Hope its ok to share this.
So it is uncommented, but always has been.
The composer.json file is in example.com/site in my “host” machine, not VM.
local_path does point to
vagrant destroy and double-checking
/etc/exports and all… I’m really stumped :*(
Oh and here is the vagrant.log with the --debug option
I just now uninstalled and reinstalled vagrant via homebrew, and only reinstalled virtualbox…
If I can’t figure this out in the next hour, this is too much stress and I’m not even sure if I will like the workflow, such a bummer. I am still interested in using Bedrock and I have enjoyed Sage for months now, but I just really want a nice workflow that I can enjoy in a similar way when developing Rails applications. I see the value of WordPress for end users/clients, but dev workflow for years has been disgustingly sloppy, which is why I really want this Trellis to work…even if I get it working, I still have to figure out if I can use it with Dokku or just plain DigitalOcean. I know I have more headaches to come.
You need a server running a bare/stock version of Ubuntu 16.04 Xenial. If you’re using a host such as DigitalOcean, then just select their Ubuntu 16.04 option.
/etc/hosts, it appears you may have multiple vagrant VMs active, which normally isn’t a problem, but troubleshooting is often a process of simplifying as much as possible, so you may want to shut down or destroy those VMs while troubleshooting the current issue (remember to export DB and save files before destroying).
When you resolve the current issue and later attempt to load the
timewisestudios.com domain in your browser, it could likely be a problem that you may have additional VMs with the same IP of
192.168.50.5. If these are each Trellis VMs, set a different IP for each. If these other VMs no longer exist, you’ll want to remove their entries from your
/etc/hosts file. Once the VMs are halted/destroyed, it may work to simply run
vagrant hostmanager. Otherwise you may need to manually remove those entries.
To help identify running VMs, try
vagrant global-status. Also load the VirtualBox GUI to see and shut down running VMs, especially any that may have somehow been orphaned/abandoned by Vagrant (i.e., of which vagrant somehow lost control).
The biggest issue I noticed so far, however, is that your VM boot output shows nothing related to sync dirs or file mounts. Compare your opening output (non-debug version) with the following output I get:
$ vagrant up Bringing machine 'default' up with 'virtualbox' provider... ==> default: Importing base box 'bento/ubuntu-16.04'... ==> default: Matching MAC address for NAT networking... ==> default: Checking if box 'bento/ubuntu-16.04' is up to date... ==> default: Setting the name of the VM: example.dev ==> default: Clearing any previously set network interfaces... ==> default: Preparing network interfaces based on configuration... default: Adapter 1: nat default: Adapter 2: hostonly ==> default: Forwarding ports... default: 22 (guest) => 2222 (host) (adapter 1) ==> default: Running 'pre-boot' VM customizations... ==> default: Booting VM... ==> default: Waiting for machine to boot. This may take a few minutes... default: SSH address: 127.0.0.1:2222 default: SSH username: vagrant default: SSH auth method: private key default: default: Vagrant insecure key detected. Vagrant will automatically replace default: this with a newly generated keypair for better security. default: default: Inserting generated public key within guest... default: Removing insecure key from the guest if it's present... default: Key inserted! Disconnecting and reconnecting using new SSH key... ==> default: Machine booted and ready! ==> default: Checking for guest additions in VM... ==> default: Setting hostname... ==> default: Configuring and enabling network interfaces... ==> default: Exporting NFS shared folders... ==> default: Preparing to edit /etc/exports. Administrator privileges will be required... ==> default: Mounting NFS shared folders... ==> default: Mounting shared folders... default: /vagrant => /Users/philip/projects/roots/example.com/trellis ==> default: Checking for bindfs in VM... default: Package manager detected: apt-get default: Fuse kernel module is installed default: Fuse kernel module is loaded ==> default: Bindfs seems to not be installed on the virtual machine, installing now default: Bindfs 1.12.6 is installed ==> default: Machine is ready to use bindfs! ==> default: Creating bind mounts after synced_folders... default: /vagrant-nfs-example.com => /srv/www/example.com/current default: /ansible-nfs => /home/vagrant/trellis default: /home/vagrant/trellis/bin => /home/vagrant/trellis/bin ==> default: [vagrant-hostmanager:guests] Updating hosts file on active guest virtual machines... ==> default: [vagrant-hostmanager:host] Updating hosts file on your workstation (password may be required)... ==> default: Running provisioner: ansible... Vagrant has automatically selected the compatibility mode '2.0' according to the Ansible version installed (18.104.22.168). Alternatively, the compatibility mode can be specified in your Vagrantfile: https://www.vagrantup.com/docs/provisioning/ansible_common.html#compatibility_mode default: Running ansible-galaxy... <snip> default: Running ansible-playbook... <snip> PLAY [WordPress Server: Install LEMP Stack with PHP 7.1 and MariaDB MySQL] ***** <snip>
- Have you modified the
vagrant.default.ymlat all? Especially in a way that could have disabled all the Vagrant sync functionality?
- Do you have other vagrant-related projects/code running on your machine that could be conflicting? Like some kind of global Vagrant settings for your machine generally, which could be interfering? I’m not familiar with Local by Flywheel, but perhaps some of its settings are conflicting.
WE did it!!!
I specified the directories Local by Flywheel has access to in the
/etc/exports file and after destroying/double-checking duplicate sites…
Thank you so much @fullyint for your help and taking the time to respond to my questions and all.
How can I make my topic listed vs unlisted?
Thanks @adrianvalenz @fullyint and Roots team for working this. I downloaded Local by Flywheel several weeks ago out of curiosity, but it seems to alter a lot of things that mess with setups like Trellis.
Happy to report that removing all Local by Flywheel references in
/etc/exports solved this issue for me too on MacOS HSierra.