Closed tomjn closed 5 years ago
Here is my result: Provisioning from a clean checkout works. Provisioning from existing project raises the mariadb error. (tried removing the database/data folder)
I can provide more information tomorrow if any.
After creating a fresh install of with latest v3, everything went well.
I had nginx.service and mariadb.service when trying to provision a site I tried importing from my v2 instance. I tried copying database and www folder, and run vagrant provision --provision-with site-mysite
and since that I can't reload the machine successfully. Did I missed something?
nginx/error.log shows:
2019/05/09 19:39:35 [emerg] 8627#8627: invalid number of arguments in "server_name" directive in /etc/nginx/custom-sites/vvv-auto-sitename-provision-364f05765617755deb6bf3b90f3fa472.conf:4
2019/05/09 19:39:36 [emerg] 9300#9300: invalid number of arguments in "server_name" directive in /etc/nginx/custom-sites/vvv-auto-sitename-provision-364f05765617755deb6bf3b90f3fa472.conf:4
2019/05/09 19:41:46 [emerg] 2651#2651: invalid number of arguments in "server_name" directive in /etc/nginx/custom-sites/vvv-auto-sitename-provision-364f05765617755deb6bf3b90f3fa472.conf:4
edit: my bad, fixed it with correct vvv-custom.yml formatting
Everything worked as expected for me, glad to be on 18.04! Host system: PopOS! 19.04
Provisioning now works for me but vagrant ssh -c "db_restore"
raises permission denied error.
db_restore is set within the vvv-custom.yml file?
@benlumia007 db_restore
is also the name of the db restoration script
@benedicksahagun @benlumia007 db_restore
issue was fixed in https://github.com/Varying-Vagrant-Vagrants/VVV/pull/1794, it just needed a chmod +x
@tsunamilx when you first created that setup, was it a VVV 1 or 2 install?
@tsunamilx when you first created that setup, was it a VVV 1 or 2 install?
@tomjn was vvv2, I decided to start from scratch and restored the database, so far so good 👍
I got this launching vagrant up
from the www
subfolder but in the past always worked.
Moving to the VVV root fixed.
@Mte90 I expect that's a bug that's always been there in the vagrant file, can you open a ticket for that?
edit: I have a fix for that in https://github.com/Varying-Vagrant-Vagrants/VVV/pull/1795, it's to do with copying the version file and config when in a subfolder, I switched them to using an absolute path
totally works for me.
Testing VVV3 now as my previous virtual machine died with strange errors and Trusty no longer works due to missing PHP.
My first run ended with the following error:
after running provision again, I got quite far, but ran into more errors:
I've tried to start with a completely new vagrant-local folder and removed all VMs from VirtualBox and vagrant.
Update: Seems like removing my ~/.vagrant.d folder resolved these errors.
v3.0.0 now uses Ubuntu 18.04, you may need to do a fresh install or git pull and do a vagrant destroy and try again.
I did perform a clean git clone to a new local directory, ran vagrant destroy, removed all machines from vagrant and virtualbox to get a brand new VM image and tried it multiple times. I only succeeded after removing ~/.vagrant.d folder.
@peterfabian your first error looks like the same issue 2 others encountered related to the vagrant-vbguest
plugin. I'm not sure of the cause, but I'm glad you got past it.
When you removed the ~/.vagrant.d
folder did you have to vagrant destroy and reprovision afterwards? Or was reprovisioning on its own enough?
I destroyed just to be sure to start with a clean state, so not sure, unfortunately.
@tomjn I currently have VVV version 2.6.0-10-g56bd99c installed, so I'm running the steps you've described here to update to version 3. I have a question. In the "Database Backups" section, you mention,
If you've turned off database backups, or haven't turned off your VM in a while, take the following steps:
You then list six steps to carry out. I'm trying to ascertain if I need to carry out these six steps. I haven't turned off database backups (to my knowledge). Additionally, I execute a 'vagrant halt' and shut down my computer every night--that means my VM is turned off every night, correct? Furthermore, in my database/backups
folder, I see a DB file for each of my existing VVV sites, and each has a 'date modified' of today's date. Lastly, each of these VVV sites also has a clone which resides on a remote server, meaning I have a full backup of each site's database. In light of that, would you say it's safe to skip these 6 steps?
FYI I'm also running:
Vagrant: v2.2.4 VirtualBox: v6.0.6r130049
Thanks.
A vagrant halt turns off the VM, and yes the database/backups
folder is where VVV backs them up to. Unless you've explicitly opted out of database backups then you have them, so yes skip those steps, you still have DB backups turned on.
So:
develop
branchOK got it. Does it matter which branch I'm on when I vagrant destroy
? FYI due to work in another VVV issue, I am currently on this branch: tomjn/modify/forcev3networkshares
@cagross it shouldn't, a lot of stuff happened since that branch anyway
OK. Step two reads:
vagrant checkout develop && git pull
Should that be
git checkout develop && git pull
?
Something like this:
vagrant halt
vagrant destroy
git checkout develop
git pull
vagrant up --provision
@tomjn OK all commands completed without issue until vagrant up --provision
I then encountered the same issue as 'Error 1' reported by @peterfabian earlier in this thread:
[default] GuestAdditions seems to be installed (6.0.6) correctly, but not running. bash: line 5: setup: command not found
Should I try deleting the ~/.vagrant.d
folder then another vagrant up --provision
, as done by @peterfabian? Or would you like me to test something else out at this juncture?
That's an issue with the vagrant-vbguest
plugin, it seems an issue is ongoing here:
https://github.com/dotless-de/vagrant-vbguest/issues/333
I think adding this to disable the plugin for VVV would be best:
if Vagrant.has_plugin?("vagrant-vbguest")
config.vbguest.auto_update = false
end
OK. I see I need to add that if
statement to my Vagrantfile
, is that correct? If so, where exactly?
@cagross I did that in https://github.com/Varying-Vagrant-Vagrants/VVV/pull/1806 which has been merged, a git pull
should get you the new change
OK, so I should:
git pull
vagrant up --provision
Correct?
correct 👍
OK. The reprovision step aborted, this time at a later stage.
default: E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/libx/libxcb/libxcb1_1.13-2~ubuntu18.04_amd64.deb Connection failed [IP: 91.189.88.161 80]
default: E: Aborting install.
default: Main packages check and install failed, halting provision
Thoughts?
That usually implies a networking interruption or that a bad mirror was chosen, I'd try again. As an aside, I see you disabled the DB share folder as shared_db_folder_disabled
is in your splash, this isn't needed to test
@tomjn
That usually implies a networking interruption or that a bad mirror was chosen, I'd try again.
OK. Over the past ~45 minutes I've tried several more times, and each fails similarly:
Any ideas how to troubleshoot this? I'm not doing anything else on this computer (or on my network) that would be causing any network issues.
As an aside, I see you disabled the DB share folder as shared_db_folder_disabled is in your splash, this isn't needed to test
I don't recall explicitly disabling that. How would I re-enable it?
@cagross Your logs all indicate that apt
is trying to download numerous packages as expected, but for whatever reason is unable to download some of them. This isn't so much a VVV problem but implies that you have an unstable connection or intermittent problems.
Since it mentions that 91.189.95.83
is where it's having trouble connecting to, can you do some standard network tests to verify your connectivity is stable? Things like ping
, traceroute
etc. If there are issues found, it would be your ISP you would talk to.
I'm pretty sure you've had similar issues in the past ( was it you who raised the issue about provisioning not working with a router or a phone? ), the common fix google suggests is changing the package source via a GUI to use a different mirror to avoid connection issues, but VVV has no GUI.
Note that you should still update VirtualBox to v6.0.8
I don't recall explicitly disabling that. How would I re-enable it?
In another issue there are instructions on disabling the shared DB folder using db_share_type
in the vvv-custom.yml
file, if you've done this, remove all references to db_share_type
, save, and reprovision. Also pull down the latest develop
Note that you should still update VirtualBox to v6.0.8
OK. I just did so, rebooted, and tried another provision. This time it was able to get past it's usual failure spot, and proceed well past that. But it still eventually failed, with the same error, on the same IP address. Full output here.
Since it mentions that 91.189.95.83 is where it's having trouble connecting to, can you do some standard network tests to verify your connectivity is stable? Things like ping, traceroute etc. If there are issues found, it would be your ISP you would talk to.
I just tried a ping
and a tracert
on that IP address, and both succeeded without issue.
I'm pretty sure you've had similar issues in the past ( was it you who raised the issue about provisioning not working with a router or a phone? ),
No, I don't believe that was me. I've never tried to connect via a router or a phone.
In another issue there are instructions on disabling the shared DB folder using db_share_type in the vvv-custom.yml file, if you've done this, remove all references to db_share_type, save, and reprovision.
I don't have any references to db_share_type
in my vvv-custom.yml file. I only have:
db_backup: true
db_restore: true
Also pull down the latest develop
OK I just tried that, then tried provisioning again. This time it ran without any fatal errors. After, I was able to open vvv.test in my browser, and it opened to VVV 3, as expected. But during output there were errors related to the database for each of my VVV sites, e.g.
default: Start MariaDB Database Import
default: ERROR
default: 1049 (42000)
default: at line 1
default: : Unknown database 'elsbuild'
default: * Error - Create elsbuild database via init-custom.sql before attempting import
Full output here. Furthermore, when I open one of my VVV sites, it indeed looks like it is using a default database, rather than its usual database (see the attached screenshot of the home page). Thoughts on that? I see there is still a 'backups' folder that contains my original database files--the same database files from my VVV 2.6 installation (which are presumably my correct database files).
Do I need to run
vagrant ssh -c "db_restore"
If you drop your databases then import those SQL files you should be good to go
On Wed, 15 May 2019 at 18:13, cagross notifications@github.com wrote:
Note that you should still update VirtualBox to v6.0.8
OK. I just did so, rebooted, and tried another provision. This time it was able to get past it's usual failure spot, and proceed well past that. But it still eventually failed, with the same error, on the same IP address. Full output here https://gist.github.com/cagross/aaac3f6d7559056f9c169fb974b197bc.
Since it mentions that 91.189.95.83 is where it's having trouble connecting to, can you do some standard network tests to verify your connectivity is stable? Things like ping, traceroute etc. If there are issues found, it would be your ISP you would talk to.
I just tried a ping and a tracert on that IP address, and both succeeded without issue.
I'm pretty sure you've had similar issues in the past ( was it you who raised the issue about provisioning not working with a router or a phone? ),
No, I don't believe that was me. I've never tried to connect via a router or a phone.
In another issue there are instructions on disabling the shared DB folder using db_share_type in the vvv-custom.yml file, if you've done this, remove all references to db_share_type, save, and reprovision.
I don't have any references to db_share_type in my vvv-custom.yml file. I only have:
db_backup: true db_restore: true
Also pull down the latest develop
OK I just tried that, then tried provisioning again. This time it ran without any fatal errors. After, I was able to open vvv.test in my browser, and it opened to VVV 3, as expected. But during output there were errors related to the database for each of my VVV sites, e.g.
default: Start MariaDB Database Import default: ERROR default: 1049 (42000) default: at line 1 default: : Unknown database 'elsbuild' default: * Error - Create elsbuild database via init-custom.sql before attempting import
Full output here https://gist.github.com/cagross/3b1323bd0cb0fdb77b9cdd6c7e3256be. Furthermore, when I open one of my VVV sites, it indeed looks like it is using a default database, rather than its usual database (see the attached screenshot of the home page). Thoughts on that? I see there is still a 'backups' folder that contains my original database files--the same database files from my VVV 2.6 installation (which are presumably my correct database files).
[image: ms-vvv-home] https://user-images.githubusercontent.com/10165488/57795150-75075200-776f-11e9-8667-338a16d7db9d.jpg
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Varying-Vagrant-Vagrants/VVV/issues/1792?email_source=notifications&email_token=AAAOLZ3ZQXMNT4YEKSSEVPDPVRAETA5CNFSM4HL365WKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVPKP3Y#issuecomment-492742639, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAOLZ4AKJH4VQTABQ3UXHLPVRAETANCNFSM4HL365WA .
OK sounds like we're getting there. So what's the exact process here? How do I drop the databases? And in-turn, how do I import those SQL files? Would I do both via phpmyadmin?
PHPMyAdmin should be able to do the job of dropping the databases, you can use it to import them too, or use the vagrant ssh -c "db_restore"
command
OK. I may try to use the vagrant ssh
command. But to be clear, will that lone command import all databases at once? If so, do I need to drop all databases before running vagrant ssh -c "db_restore"
?
does the db_restore/db_backup: true/false still works?
you need to drop the databases before running db_restore
, db_restore
should import the SQL files
does the db_restore/db_backup: true/false still works?
Yes, but using vagrant ssh -c "db_restore"
or vagrant ssh -c "db_backup"
will always work, and can be ran at any time assuming the VM is turned on
@tomjn OK I'll keep that in-mind when restoring the database. But after shutting down my computer for the night, I woke up and tried a vagrant up
. I was met with a new error, one related to my VM:
The name of your virtual machine couldn't be set because VirtualBox
is reporting another VM with that name already exists. Most of the
time, this is because of an error with VirtualBox not cleaning up
properly. To fix this, verify that no VMs with that name do exist
(by opening the VirtualBox GUI). If they don't, then look at the
folder in the error message from VirtualBox below and remove it
if there isn't any information you need in there.
VirtualBox error:
VBoxManage.exe: error: Could not rename the directory 'C:\Users\snarl\VirtualBox VMs\sites-vvv_02652ed77c8' to 'C:\Users\snarl\VirtualBox VMs\sites-vvv_33ebf71fcbd' to save the settings file (VERR_ALREADY_EXISTS)
VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component SessionMachine, interface IMachine, callee IUnknown
VBoxManage.exe: error: Context: "SaveSettings()" at line 3206 of file VBoxManageModifyVM.cpp
Full output here. To be clear, when I open VirtualBox, there is indeed already a VM with the name sites-vvv_33ebf71fcbd
It is in the 'Powered Off' state. Isn't that normal, and as expected?
Thanks.
Sweet. Works a treat on my old 2010 Mac Mini 10.13.6. BTW. I just got rid of all the old stuff and did a vagrant up (without --provision) Thanks Wordpress needs it's php ;)
Somewhat related to this, I think: I just tried building master on a brand new master and it failed hard on the php packages saying they weren't there. I'm guessing that's because of the end-of-life Ubuntu?
Also:
switch to the develop branch vagrant checkout develop && git pull
This should be git checkout develop && git pull
, right?
I tried the develop branch and it seems to be working for me. Could it be that master doesn't work at all now?
@coderkevin yes, u should be using develop, so if you haven't done git pull recently, you may want to do so and do vagrant destroy as well. since the develop branch is using the latest ubuntu 18.04
Master will work once VVV 3 is merged, it just needs to finish the release process, the release post has been written so I'll merge and tag it later today
Unless you fancy building Ubuntu 14 PHP packages from source for us :)
On Fri, 17 May 2019 at 06:36, Benjamin Lu notifications@github.com wrote:
@coderkevin https://github.com/coderkevin yes, u should be using develop, so if you haven't done git pull recently, you may want to do so and do vagrant destroy as well. since the develop branch is using the latest ubuntu 18.04
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Varying-Vagrant-Vagrants/VVV/issues/1792?email_source=notifications&email_token=AAAOLZ3MKWJ6OY7WVAAQG3DPVY76HA5CNFSM4HL365WKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVTY7UI#issuecomment-493326289, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAOLZ7C42VO2G236LSK72LPVY76HANCNFSM4HL365WA .
@cagross that's an odd error but it's a virtual box/vagrant one, was that the first time you'd done it after updating vbox? You didn't rename the folder did you?
On Fri, 17 May 2019 at 11:05, Tom Nowell contact@tomjn.com wrote:
Master will work once VVV 3 is merged, it just needs to finish the release process, the release post has been written so I'll merge and tag it later today
Unless you fancy building Ubuntu 14 PHP packages from source for us :)
On Fri, 17 May 2019 at 06:36, Benjamin Lu notifications@github.com wrote:
@coderkevin https://github.com/coderkevin yes, u should be using develop, so if you haven't done git pull recently, you may want to do so and do vagrant destroy as well. since the develop branch is using the latest ubuntu 18.04
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Varying-Vagrant-Vagrants/VVV/issues/1792?email_source=notifications&email_token=AAAOLZ3MKWJ6OY7WVAAQG3DPVY76HA5CNFSM4HL365WKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVTY7UI#issuecomment-493326289, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAOLZ7C42VO2G236LSK72LPVY76HANCNFSM4HL365WA .
@tomjn I checked it once more about 24 hours ago, and encountered the same issue. But I checked just now, and a vagrant up
now completes without issue. Sheesh. Not sure what happened there. But let me try to restore my databases now.
@tomjn Via phpmyadmin, I dropped the databases relating to my three custom sites. I then carried out:
vagrant ssh -c "db_restore"
It failed with:
Start MariaDB Database Import
ERROR 1049 (42000) at line 1: Unknown database 'elsbuild'
* Error - Create elsbuild database via init-custom.sql before attempting import
ERROR 1049 (42000) at line 1: Unknown database 'mrsamui'
* Error - Create mrsamui database via init-custom.sql before attempting import
ERROR 1049 (42000) at line 1: Unknown database 'samuiink'
* Error - Create samuiink database via init-custom.sql before attempting import
ERROR 1049 (42000) at line 1: Unknown database 'wordpressone'
* Error - Create wordpressone database via init-custom.sql before attempting import
ERROR 1049 (42000) at line 1: Unknown database 'wordpresstrunk'
* Error - Create wordpresstrunk database via init-custom.sql before attempting import
ERROR 1049 (42000) at line 1: Unknown database 'wordpresstwo'
* Error - Create wordpresstwo database via init-custom.sql before attempting import
Databases imported
Connection to 127.0.0.1 closed.
Thoughts?
This is a common problem and is is something that we cannot replicate. The problem is that the sql dump doesn't include the create table and happens that error.
VVV 3 is almost upon us!
Before it's merged into
master
, we need testers to confirm everything is as we think it is.What Happened?
VVV 2 ran on Ubuntu 14, with PHP packages from Ondrej. Last week, Ubuntu 14 reached end of support, and Ondrej deleted the PHP packages as planned. We thought we had a mirror of the PHP packages, but it was incomplete ☹️.
So, we took a pull request to update VVV to Ubuntu 18, switched it to 18.04 LTS Bionic, and set about making the necessary changes.
What Changed in VVV 3?
The big changes first:
database/data
, databases will now survive destroying and rebuilding the VMThis means that to update, you must back up your database, destroy the VM, update, then reprovision. Important: Destroying and reprovisioning will erase the database.
Other changes:
/srv/certificates
,/srv/provision
, and/srv/config
shared foldersKnown Issues
Database Backups
VVV by default takes backups when you run
vagrant halt/suspend
, so check yourdatabase/backups
folder. In future these will be indatabase/data/backups
.If you've turned off database backups, or haven't turned off your VM in a while, take the following steps:
git fetch --tags && git checkout 2.6.0
vagrant up
vagrant ssh -c "db_backup"
vagrant halt
git checkout develop
Updating Your VM To VVV 3+
If you're happy and have your database files, you can update your VM to VVV 3+ with these commands:
vagrant destroy
vagrant checkout develop && git pull
vagrant up --provision
vagrant ssh -c "db_restore"
Next Steps
Thanks for helping out and being patient, it's been a super tough week for myself and our contributors. If you're testing, let us know if it worked! If it didn't, feel free to comment below or in the relevant github issue.
If all is good you should see this at the end of provisioning:
And you should be able to visit http://vvv.test and use your existing sites.
If all is bad, put a copy of the provisioner output in a gist at https://gist.github.com and share it with us, don't forget to include the VVV splash! it has important info such as your OS, Vagrant and VirtualBox versions
Lets get this shipped!