What is the difference between vagrant box repackage (docs) and vagrant package (docs)?
I realise that vagrant package works only with the VirtualBox provider, but in case only VirtualBox is used - what's the difference? Maybe there's a specific reason vagrant package was created?
vagrant package
If you have a running VirtualBox VM, you created without vagrant first, did your things using VirtualBox, and you now want to use Vagrant to manage this VM. As vagrant needs box to start VM, you will run vagrant package to create a vagrant box based on the existing VirtualBox VM
vagrant repackage
You will use this option when you have an existing vagrant box installed on your system. So you use vagrant with a given box, again you will make change to the VM and you want to save those changes (software installed ...) as a new box, you will run vagrant repackage on this box, and it will create an updated version of this box so it can be used as starting box for new VM.
I will answer with the specific example of the VirtualBox provider on macOS, but this can be generalized to any provider on any host. Although not asked by the op, I will also explain --base NAME because I think it helps in clarifying the difference. I will also use the --output OUTPUT_NAME to distinguish between the packaged boxes.
vagrant package
~/code/vagrant/vm1 > vagrant package --output vm1-package.box
Attempts graceful shutdown of currently running VM which is found from ./.vagrant/... directory
Clears any previously set forwarded ports
Exports the VM (using the provider's export tools) and adds vagrant_private_key
Archives (using tar) everything into ./vm1-package.box
==> vm1: Attempting graceful shutdown of VM...
==> vm1: Clearing any previously set forwarded ports...
==> vm1: Exporting VM...
==> vm1: Compressing package to: /Users/user/code/vagrant/vm1/vm1-package.box
To verify:
~/code/vagrant/vm1 > tar -C /tmp/vm1 -xvf ./vm1-package.box
x ./vagrant_private_key
x ./metadata.json
x ./box.ovf
x ./Vagrantfile
x ./box-disk001.vmdk
Since this packages the currently running VM that Vagrant manages, the above list includes the vagrant_private_key file (which is loaded by the packaged Vagrantfile).
Now, we can add this box to Vagrant's internal storage in ~/.vagrant.d:
~/code/vagrant/vm1 > vagrant box add vm1-package.box --name vm1
==> box: Box file was not detected as metadata. Adding it directly...
==> box: Adding box 'vm1' (v0) for provider:
box: Unpacking necessary files from: file:///Users/user/code/vagrant/vm1/vm1-package.box
==> box: Successfully added box 'vm1' (v0) for 'virtualbox'!
which you can also verify by:
~/code/vagrant/vm1 > ls -lF ~/.vagrant.d/boxes/vm1/0/virtualbox/
total 1152400
-rw-r--r-- 1 user staff 630 13 Dec 16:26 Vagrantfile
-rw-r--r-- 1 user staff 575710720 13 Dec 16:26 box-disk001.vmdk
-rwx------ 1 user staff 6838 13 Dec 16:26 box.ovf*
-rw-r--r-- 1 user staff 25 13 Dec 16:26 metadata.json
-rw------- 1 user staff 1675 13 Dec 16:26 vagrant_private_key
~/code/vagrant/vm1 > vagrant box list
hashicorp/bionic64 (virtualbox, 1.0.282)
vm1 (virtualbox, 0)
vagrant package --base vm_name
~/code/vagrant/vm1 > vagrant package --base vm1 --output vm1-base-package.box
Attempts graceful shutdown of currently running VM which is found from ./.vagrant/... directory
Clears any previously set forwarded ports
Exports the VM (using the provider's export tools) but does not add vagrant_private_key
Archives (using tar) everything into ./vm1-base-package.box
==> vm1: Exporting VM...
==> vm1: Compressing package to: /Users/user/code/vagrant/vm1/vm1-base-package.box
To verify:
~/code/vagrant/vm1 > tar -C /tmp/vm1-base -xvf ./vm1-base-package.box
x ./metadata.json
x ./box.ovf
x ./Vagrantfile
x ./box-disk001.vmdk
Since this packages the currently running VM that Virtualbox manages, the above list does not includes the vagrant_private_key file.
Now, we can add this box to Vagrant's internal storage in ~/.vagrant.d:
~/code/vagrant/vm1 > vagrant box add vm1-base-package.box --name vm1-base
==> box: Box file was not detected as metadata. Adding it directly...
==> box: Adding box 'vm1-base' (v0) for provider:
box: Unpacking necessary files from: file:///Users/user/code/vagrant/vm1/vm1-base-package.box
==> box: Successfully added box 'vm1-base' (v0) for 'virtualbox'!
~/code/vagrant/vm1 > vagrant box list
hashicorp/bionic64 (virtualbox, 1.0.282)
vm1 (virtualbox, 0)
vm1-base (virtualbox, 0)
~/code/vagrant/vm1 > ls -lF *.box
-rw-r--r-- 1 user staff 561848649 13 Dec 16:50 vm1-base-package.box
-rw-r--r-- 1 user staff 561767838 13 Dec 16:19 vm1-package.box
If you delete the box files from the current directory...
~/code/vagrant/vm1 > rm *.box
... you may now use vagrant repackage to get them back:
vagrant box repackage
~/code/vagrant/vm1 > vagrant box repackage vm1 virtualbox 0
This takes the files from Vagrant's internal storage ~/.vagrant.d/... and re-packages them back into a box in the current directory called package.box. In this case, you cannot name the file using the command, so you may want to rename it:
~/code/vagrant/vm1 > mv package.box vm1-package.box
and for the base box:
~/code/vagrant/vm1 > vagrant box repackage vm1-base virtualbox 0
~/code/vagrant/vm1 > mv package.box vm1-base.box
~/code/vagrant/vm1 > ls -lF *.box
-rw-r--r-- 1 user staff 561848571 13 Dec 17:28 vm1-base.box
-rw-r--r-- 1 user staff 561767855 13 Dec 17:24 vm1-package.box
Additional note
The manual is not very clear on the syntax of the vagrant package command with and without the --base option. I think the clarification should be:
vagrant package [options] [vm_name|vm_id]
It should specify that if [vm_name|vm_id] is not specified, then the currently running VM is packaged, otherwirse, the VM specified by [vm_name|vm_id] is packaged.
It should also specify that if you use the --base option, the command should be:
vagrant package --base MANDATORY_NAME [vm_name|id]
but in this case, [vm_name|id] is completely ignored, since the VM has already been specified by MANDATORY_NAME
I verified this by issuing:
vagrant package --base vm1 --output vm1-base-package.box non-existent-vm-name
and it still generated vm1-base-package.box without any errors.
Related
I started using fedora 24 last year for my study/work computer. First time I run into an issue I cannot figure out within a reasonable amount of time.
We need to use Vagrant for a project, and I'm trying to get it running on my computer. The command vagrant up fails at the mounting nfs. Here's the output after the command:
Bringing machine 'default' up with 'libvirt' provider...
==> default: Starting domain.
==> default: Waiting for domain to get an IP address...
==> default: Waiting for SSH to become available...
==> default: Creating shared folders metadata...
==> default: Exporting NFS shared folders...
==> default: Preparing to edit /etc/exports. Administrator privileges will be required...
[sudo] password for feilz:
Redirecting to /bin/systemctl status nfs-server.service
● nfs-server.service - NFS server and services
Loaded: loaded (/etc/systemd/system/nfs-server.service; enabled; vendor preset: disabled)
Drop-In: /run/systemd/generator/nfs-server.service.d
└─order-with-mounts.conf
Active: active (exited) since Wed 2017-02-15 15:17:58 EET; 19h ago
Main PID: 16889 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 512)
CGroup: /system.slice/nfs-server.service
Feb 15 15:17:58 feilz systemd[1]: Starting NFS server and services...
Feb 15 15:17:58 feilz systemd[1]: Started NFS server and services.
==> default: Mounting NFS shared folders...
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
mount -o 'vers=4' 192.168.121.1:'/home/feilz/env/debian64' /vagrant
Stdout from the command:
Stderr from the command:
stdin: is not a tty
mount.nfs: access denied by server while mounting 192.168.121.1:/home/feilz/env/debian64
My Vagrantfile looks like: (I skipped the commented out lines)
Vagrant.configure(2) do |config|
config.vm.box = "debian/jessie64"
config.vm.provider :libvirt do |libvirt|
libvirt.driver = "qemu"
end
end
I can run the vagrant ssh command to log in, and write the command
sudo mount -o 'vers=4' 192.168.121.1:'/home/feilz/env/debian64' /vagrant
inside vagrant to try again.Then the output becomes
mount.nfs: access denied by server while mounting 192.168.121.1:/home/feilz/env/debian64
I've gone through loads of webpages. I fixed missing ruby gems (nokogiri and libffi). I tried modifying the /etc/exports file, it doesn't work, and it gets reset after I run vagrant halt / up.
I have installed the vagrant plugin vagrant-libvirt
What haven't I tried yet, that would allow me to use the NFS file sharing for Vagrant?
I'm using the CoreOS vagrant repository (https://github.com/coreos/coreos-vagrant) on Fedora 24, with the distro-supplied vagrant (vagrant-1.8.1-3.fc24.noarch). When I run vagrant up I get the following:
$ vagrant up
Bringing machine 'core-01' up with 'virtualbox' provider...
==> core-01: Box 'coreos-alpha' could not be found. Attempting to find and install...
core-01: Box Provider: virtualbox
core-01: Box Version: >= 0
==> core-01: Box file was not detected as metadata. Adding it directly...
==> core-01: Adding box 'coreos-alpha' (v0) for provider: virtualbox
core-01: Downloading: https://storage.googleapis.com/alpha.release.core-os.net/amd64-usr/current/coreos_production_vagrant.json
The box failed to unpackage properly. Please verify that the box
file you're trying to add is not corrupted and try again. The
output from attempting to unpackage (if any):
bsdtar: Error opening archive: Unrecognized archive format
Looking in Vagrantfile I can see that the box is referred to by a remote URL:
config.vm.box_url = "https://storage.googleapis.com/%s.release.core-os.net/amd64-usr/%s/coreos_production_vagrant.json" % [$update_channel, $image_version]
When I try and add the box explicitly using the remote JSON file directly I get:
$ vagrant box add https://storage.googleapis.com/alpha.release.core-os.net/amd64-usr/current/coreos_production_vagrant.json
==> box: Box file was not detected as metadata. Adding it directly...
A name is required when adding a box file directly. Please pass
the `--name` parameter to `vagrant box add`. See
`vagrant box add -h` for more help.
If I download the JSON file and add the box referencing the local file, it works fine, but I end up with a reference to the local file in the box's metadata_url in ~/.vagrant and I lose the functionality of vagrant's box update check.
I read that this might be caused by the fact that the remote JSON is not served with the correct Content-type, however, that is certainly not the problem here:
curl -sv https://storage.googleapis.com/alpha.release.core-os.net/amd64-usr/current/coreos_production_vagrant.json 2>&1 | grep -i Content-type
< content-type:application/json
I have followed the tutorial on https://laravel.com/docs/5.0/homestead and when running the step 'vagrant up', I get the following error message (below)
Any ideas what the problem is? Running latest version of Oracle VirtualBox and the latest version of Vagrant. Regards
--
C:\Users\Anders\Vagrant\Homestead>vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'laravel/homestead'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'laravel/homestead' is up to date...
==> default: Setting the name of the VM: homestead-7
==> 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: 80 (guest) => 8000 (host) (adapter 1)
default: 443 (guest) => 44300 (host) (adapter 1)
default: 3306 (guest) => 33060 (host) (adapter 1)
default: 5432 (guest) => 54320 (host) (adapter 1)
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!
GuestAdditions versions on your host (5.0.16) and guest (5.0.12) do not match.
Reading package lists...
Building dependency tree...
Reading state information...
dkms is already the newest version.
linux-headers-3.19.0-25-generic is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
Copy iso file C:\Program Files\Oracle\VirtualBox\VBoxGuestAdditions.iso into the
box /tmp/VBoxGuestAdditions.iso
mount: block device /tmp/VBoxGuestAdditions.iso is write-protected, mounting rea
d-only
Installing Virtualbox Guest Additions 5.0.16 - guest version is 5.0.12
Verifying archive integrity... All good.
Uncompressing VirtualBox 5.0.16 Guest Additions for Linux............
VirtualBox Guest Additions installer
Removing installed version 5.0.12 of VirtualBox Guest Additions...
Stopping VirtualBox Additions ...fail!
(Cannot unload module vboxguest)
Removing existing VirtualBox DKMS kernel modules ...done.
Removing existing VirtualBox non-DKMS kernel modules ...done.
Stopping VirtualBox Guest Addition service ...done.
Copying additional installer modules ...
Installing additional modules ...
Removing existing VirtualBox DKMS kernel modules ...done.
Removing existing VirtualBox non-DKMS kernel modules ...done.
Building the VirtualBox Guest Additions kernel modules ...done.
Doing non-kernel setup of the Guest Additions ...done.
You should restart your guest to make sure the new modules are actually used
Installing the Window System drivers
Could not find the X.Org or XFree86 Window System, skipping.
An error occurred during installation of VirtualBox Guest Additions 5.0.16. Some
functionality may not work as intended.
In most cases it is OK that the "Window System drivers" installation failed.
==> default: Checking for guest additions in VM...
==> default: Setting hostname...
==> default: Configuring and enabling network interfaces...
==> default: Mounting shared folders...
default: /vagrant => C:/Users/Anders/Vagrant/Homestead
default: /home/vagrant/Code => C:/Users/Anders/Code
Failed to mount folders in Linux guest. This is usually because
the "vboxsf" file system is not available. Please verify that
the guest additions are properly installed in the guest and
can work properly. The command attempted was:
mount -t vboxsf -o uid=`id -u vagrant`,gid=`getent group vagrant | cut -d: -f3`,
actimeo=1 home_vagrant_Code /home/vagrant/Code
mount -t vboxsf -o uid=`id -u vagrant`,gid=`id -g vagrant`,actimeo=1 home_vagran
t_Code /home/vagrant/Code
The error output from the last command was:
unknown mount option `actimeo=1'
valid options:
rw mount read write (default)
ro mount read only
uid =<arg> default file owner user id
gid =<arg> default file owner group id
ttl =<arg> time to live for dentry
iocharset =<arg> i/o charset (default utf8)
convertcp =<arg> convert share name from given charset to utf8
dmode =<arg> mode of all directories
fmode =<arg> mode of all regular files
umask =<arg> umask of directories and regular files
dmask =<arg> umask of directories
fmask =<arg> umask of regular files
C:\Users\Anders\Vagrant\Homestead>
--
vagrant file:
--
require 'json'
require 'yaml'
VAGRANTFILE_API_VERSION = "2"
confDir = $confDir ||= File.expand_path("~/.homestead")
homesteadYamlPath = confDir + "/Homestead.yaml"
homesteadJsonPath = confDir + "/Homestead.json"
afterScriptPath = confDir + "/after.sh"
aliasesPath = confDir + "/aliases"
require File.expand_path(File.dirname(__FILE__) + '/scripts/homestead.rb')
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
if File.exists? aliasesPath then
config.vm.provision "file", source: aliasesPath, destination: "~/.bash_aliases"
end
if File.exists? homesteadYamlPath then
Homestead.configure(config, YAML::load(File.read(homesteadYamlPath)))
elsif File.exists? homesteadJsonPath then
Homestead.configure(config, JSON.parse(File.read(homesteadJsonPath)))
end
if File.exists? afterScriptPath then
config.vm.provision "shell", path: afterScriptPath
end
end
--
yaml file:
--
---
ip: "192.168.10.10"
memory: 2048
cpus: 1
provider: virtualbox
authorize: ~/Vagrant/Homestead/homestead.pub
keys:
- ~/.ssh/id_rsa
folders:
- map: ~/Code
to: /home/vagrant/Code
type: "nfs"
sites:
- map: homestead.app
to: /home/vagrant/Code/Laravel/public
hhvm: true
databases:
- homestead
The issue you're experiencing with Homestead has been documented in Github. There is a workaround provided, which is as follows:
Solution: Remove type: "nfs" on your folders of Homestead.yaml.
http://docs.vagrantup.com/v2/synced-folders/nfs.html
"Windows users: NFS folders do not work on Windows hosts. Vagrant will
ignore your request for NFS synced folders on Windows.
Original Answer (for the question before it was edited)
Now the issue seems to be with your ssh key, or lackthereof.
No such file or directory # rb_sysopen - C:/Users/Anders/.ssh/id_rsa (Errno::ENOENT)
The section in the guide you linked titled Set Your SSH Key has the following instructions to help you generate one (trimmed to the relevant Windows instructions):
Set Your SSH Key
[...]
On Windows, you may install Git and use the Git Bash shell included with Git to issue the command above. Alternatively, you may use PuTTY and PuTTYgen.
Once you have created a SSH key, specify the key's path in the authorize property of your Homestead.yaml file.
If you are not that comfortable with commandlines, I would recommend using the PuTTYgen method.
This is a problem with your Homestead.yaml file in ~/.homestead directory. I need see the file content to help you more.
After you had fixed the indention style to use only space characters, the another problem happenned because you not generate a pair (public and private) of keys yet. To do that:
mkdir -p ~/.ssh && cd ~/.ssh
ssh-keygen -b 2048 -t rsa -C "you#domain.com"
You can let the default file name (id_rsa), type the password and repeat the same password.
In case anyone else ends up here via Google and didn't read all the comments too well (like I did).
I ran into the same issue of not being able to vagrant up with the following error:
Vagrant was unable to mount VirtualBox shared folders. This is usually
because the filesystem "vboxsf" is not available. This filesystem is
made available via the VirtualBox Guest Additions and kernel module.
Please verify that these guest additions are properly installed in the
guest. This is not a bug in Vagrant and is usually caused by a faulty
Vagrant box. For context, the command attempted was:
mount -t vboxsf -o actimeo=1,nolock,uid=1000,gid=1000 var_www_dev.mybox /var/www/dev.mybox
The error output from the command was:
fmask =<arg> umask of regular files
As Lucas mentioned here Windows users can install the vagrant-winnfsd plugin which allows you to use NFS shared folders in Vagrant and Homestead).
So I solved this error by running vagrant plugin install vagrant-winnfsd followed by a vagrant up.
I am absolutly new in Vagrant and I have the following problem. I am using Windows 8.1.
I have done the following operations:
First I have download this into a folder of my host from github, by this statment:
git clone https://github.com/Udacity/ud381
Then I performed:
vagrant up
that downloaded the Vagrant Box containing the guest VM
and when now I perform the vagrant up command I obtain this message:
C:\Users\Andrea\Documents\workspaces\Real-Time\ud381>vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'udacity/ud381' is up to date...
==> default: There was a problem while downloading the metadata for your box
==> default: to check for updates. This is not an error, since it is usually due
==> default: to temporary network problems. This is just a warning. The problem
==> default: encountered was:
==> default:
==> default: Failed connect to atlas.hashicorp.com:443; No error
==> default:
==> default: If you want to check for box updates, verify your network connectio
n
==> default: is valid and try again.
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
==> default: Forwarding ports...
default: 5000 => 5000 (adapter 1)
default: 22 => 2222 (adapter 1)
==> 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: Warning: Remote connection disconnect. Retrying...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
==> default: Mounting shared folders...
default: /vagrant => C:/Users/Andrea/Documents/workspaces/Real-Time/ud381
==> default: Machine already provisioned. Run `vagrant provision` or use the `--
provision`
==> default: flag to force provisioning. Provisioners marked to run always will
still run.
I think that it is correct but I am not absolutly sure about it because it seems that I have some warning message but it say: default: Machine booted and ready! so I think that it is ok (is it ok?)
Then I try to connect to it by SSH performing the vagrant ssh statment but I obtain this error message:
C:\Users\Andrea\Documents\workspaces\Real-Time\ud381>vagrant ssh
`ssh` executable not found in any directories in the %PATH% variable. Is an
SSH client installed? Try installing Cygwin, MinGW or Git, all of which
contain an SSH client. Or use your favorite SSH client with the following
authentication information shown below:
Host: 127.0.0.1
Port: 2222
Username: vagrant
Private key: C:/Users/Andrea/Documents/workspaces/Real-Time/ud381/.vagrant/machi
nes/default/virtualbox/private_key
Searching on Google I found that to use this statment I need the git path into the PATH environment variable. I check and I have it setted, infact inside the PATH variable I have these 2 values:
C:\HashiCorp\Vagrant\bin;C:\Program Files\Git\bin
the first one is the vagrant path and the second one the Git path.
So this is not the problem. Searching online I also found this StacOverflow discussion:
`ssh` executable not found in any directories in the %PATH%
that send to this link for this kind of problem: https://gist.github.com/haf/2843680
In this link it show how to modify an ssh.rb file into this folder C:\vagrant\vagrant\embedded\lib\ruby\gems\1.9.1\gems\vagrant-1.0.3\lib\vagrant\ssh.rb
The problem is that I have not this folder but something like this:
C:\HashiCorp\Vagrant\embedded\lib\ruby\gems\2.0.0\gems\
and this folder don't contain the *vagrant-1.0.3\lib\vagrant* subfolder (that contain the ssh.rb file) but contain 3 directory respectivelly named rake-0.9.6, rdoc-4.0.0 and test-unit-2.0.0.0 that don't contain the ssh.rb file.
Searching this file I found 2 different version into these folder:
C:\HashiCorp\Vagrant\embedded\gems\gems\vagrant-1.7.4\plugins\kernel_v1\config
and
C:\HashiCorp\Vagrant\embedded\gems\gems\vagrant-1.7.4\plugins\kernel_v2\config
I think that maybe the difference from the tutorial could depend by the fact that it is referred to a very old Vagrant version (it is 4 year old) and I have installed the 1.7.4 version of Vagrant.
So how can I connect in SSH to the VM handled by Vagrant?
The error message
C:\Users\Andrea\Documents\workspaces\Real-Time\ud381>vagrant ssh `ssh`
executable not found in any directories in the %PATH% variable. Is an
SSH client installed?
states that the cli you are currently using (wich is probably cmd or powershell when you are working under windows) could not find an installed ssh client. That means your cli was not able to find a programm that can handle connecting to another server (in this case your vagrantbox) via ssh.
This is a pretty common scenario since windows does not come with an ssh client out of the box (unlike ubuntu or osx).
AFAIK there is no ssh program/command that you can easily install and put into your PATH so that it will work with cmd.
What you probably want to do in this situation is installing a different cli that comes with these features. You have several Options here, they are also stated in the error message:
Try installing Cygwin, MinGW or Git, all of which
contain an SSH client
I recommend you using Git Bash which you probably already have installed on your system since you are using git.
So to perform a vagrant ssh your first step will be starting Git Bash either by executing the program itself (which comes with git, on my system it could be found under: C:\Program Files\Git\git-bash.exe) or by right clicking in a directory listing in Windows Explorer and selecting Git Bash here (this will only work if you checked a certain box upon Git install).
It will open a new cli which works with linux like commands.
You should be able to cd into your vagrant directory and perform a vagrant ssh now.
The solution you linked to in your question no longer seems to work since the path of the ssh client comming with git seems to have changed.
See Ygor Thomaz' comment in the other SO post you found. The PATH path has changed to:
C:\Program Files\Git\usr\bin
..so run this in cmd:
set PATH=%PATH%;C:\Program Files\Git\usr\bin
Related:
How do you update the GIT_SSH environment variable on Windows
https://stackoverflow.com/a/16247703/1869660
I am using windows 8.1 Pro pc running vagrant and cygwin's rsync.
I am configuring as such:
config.vm.synced_folder "../sharedFolder", "/vagrant_data", type: "rsync"
And when I execute vagrant up I get the following error:
C:\dev\vagrantBoxes\coreOS>vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'yungsang/coreos' is up to date...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
==> default: Forwarding ports...
default: 22 => 2222 (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: core
default: SSH auth method: private key
default: Warning: Connection timeout. Retrying...
==> default: Machine booted and ready!
==> default: Rsyncing folder: /c/dev/vagrantBoxes/sharedFolder/ => /vagrant_data
There was an error when attempting to rsync a synced folder.
Please inspect the error message below for more info.
Host path: /c/dev/vagrantBoxes/sharedFolder/
Guest path: /vagrant_data
Command: rsync --verbose --archive --delete -z --copy-links --chmod=ugo=rwX --no-perms --no-owner --no-group --rsync-path sudo rsync -e ssh -p 2222 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/d
ev/null -i 'C:/Users/aaron.axisa/.vagrant.d/insecure_private_key' --exclude .vagrant/ /c/dev/vagrantBoxes/sharedFolder/ core#127.0.0.1:/vagrant_data
Error: Warning: Permanently added '[127.0.0.1]:2222' (RSA) to the list of known hosts.
rsync: change_dir "/c/dev/vagrantBoxes/sharedFolder" failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at /usr/src/ports/rsync/rsync-3.0.9-1/src/rsync-3.0.9/main.c(1052) [sender=3.0.9]
I assume it is an issue with how it is changing the directory path to /c/dev rather than C:\dev
like I commented in the github-issue, following line in your Vagrantfile will most certainly fix your problem
ENV["VAGRANT_DETECTED_OS"] = ENV["VAGRANT_DETECTED_OS"].to_s + " cygwin"
since this is local in your Vagrantfile, the source-files can be kept untouched
workaround: just ln -s /cygdrive/c/ /c on cygwin terminal
There is a hacky way to fix this (worked for me anyway) where you have to change
hostpath = Vagrant::Util::Platform.cygwin_path(hostpath)
to
hostpath = "/cygdrive" + Vagrant::Util::Platform.cygwin_path(hostpath)
on line 43 in C:\HashiCorp\Vagrant\embedded\gems\gems\vagrant-[VERSION]\plugins\synced_folders\rsync\helper.rb
It's different for 1.5.x, you can read this thread here about it: https://github.com/mitchellh/vagrant/issues/3230
I will, however, be the first to admit that editing the core is far from ideal.
From my testing, if you are using cygwin, use the solution by #osroot25 .
If you are using cwRsync and do not have cygwin, there is no workaround using Vagrant except editing the source code as #Andrew Myers details. Tested using Vagrant v1.6.5.
My workaround that works for me is to bypass Vagrant altogether and use cwRsync directly. This works for me because I am syncing a folder that hardly ever changes. I might change it quite a few times in one day (so I have to remember step 2 below each time), but I then go weeks (or months) without any changes. Remember that to use cwRsync you have to edit and use the cwrsync.cmd script. Attempting to access the rsync.exe command directly or by adding it to your path will fail. Step 1: I added the following line to the end of cwrsync.cmd (in the installed folder):
rsync -re "ssh -p 2222" /cygdrive/b/VCS/packages/ vagrant#localhost:packages --exclude ".git/"
Step 2: I have a separate cmd window open that I run the cwrsync.cmd using the full path. Then if I need to sync changes onto the VM, I activate that window, up-arrow, return and updating is instant!
Modifying ENV to set cygwin fix by #osroot25 doesn't work with cwRsync because when you force cygwin detection, the "vagrant ssh" command will not work because it requires the cygpath command in cygwin, which you won't have, so you cannot ssh into the VM. Well you can if you use the ssh command directly with all the right options.