first off I'm very new to programming and web development. I'm currently working through a Udacity course on SQL.
I'm trying to install VM and Vagrant and have run into this issue. Vagrant installed fine, and I'm able to run vagrant up, but when I run vagrant ssh I'm getting this message:
.ssh/config: terminating, 1 bad configuration options
I'll attach a screen here.
I'm on a Mac. Big Sur 11.5.2
Vagrant version 2.2.18
Any help provided would be greatly appreciated! Thanks in advance![enter image description here][1]
bash-3.2$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'bento/ubuntu-16.04-i386' version '2.3.5' is up to date...
==> default: Machine already provisioned. Run vagrant provision or use the --provision
==> default: flag to force provisioning. Provisioners marked to run always will still run.
bash-3.2$ vagrant ssh
/Users/scott27/.ssh/config: terminating, 1 bad configuration options
bash-3.2$
Consider moving your config file to a backup and trying again.
mv /Users/scott27/.ssh/config /Users/scott27/.ssh/config.bak
Then try vagrant up again and if it works then the issue is in your config file, troubleshoot that separately.
Instead of moving the existing ssh config file it is better to instead let vagrant point to its own config file using the config.ssh.config in vagrantfile
I am on Windows but I assume it is similar on mac. I updated my Vagrantfile like so:
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
config.ssh.config = File.expand_path(File.dirname(__FILE__) + '/ssh_config')
As you can see I point to a ssh_config file that I created, since an empty string resulted in an error.
Related
I destroyed my CoreOS vagrant box, then tried to re-up but it's hanging at:
==> core-01: Matching MAC address for NAT networking...
==> core-01: Checking if box 'coreos-alpha' is up to date...
==> core-01: Setting the name of the VM: coreos-vagrant_core-01_1447605695441_10076
In my VirtualBox graphical user interface, coreos-vagrant_core-01_1447605695441_10076 is shown as being Powered Off.
And then, nothing happens.
My question is: how best to debug this? How can I get more information about what is going on and where it's hanging?
vagrant up --debug will give you logging info from the VM
I had the same problem on Windows.
The suggestion (solution) based on my experience:
If you have updated/modified your puphpet config.yaml file recently:
If recenlty downloaded from puphpet.com make sure you have compatible vagrant version, currently: Minimum required Vagrant version is 1.7.4
Try changing your sync_type: to default (recommended for win is SMB, but for me personally this would cause to hang, until changed to default)
And last but not least, try running (up) with debug option, like so:
vagrant up --debug
P.S. Notice the double -- dash
I am new to packer.
For a start I tried to build: https://github.com/shiguredo/packer-templates/tree/develop/ubuntu-14.04 which worked fine. But when I want to sin it up via vagrant up I get the following error:
Vagrant environment or target machine is required to run this
command. Run `vagrant init` to create a new Vagrant environment. Or,
get an ID of a target machine from `vagrant global-status` to run
this command on. A final option is to change to a directory with a
Vagrantfile and to try again.
After calling vagrant init a config file which looks like a default config file is created. But still there are errors:
Bringing machine 'default' up with 'parallels' provider...
==> default: Box 'base' could not be found. Attempting to find and install...
default: Box Provider: parallels
default: Box Version: >= 0
==> default: Adding box 'base' (v0) for provider: parallels
default: Downloading: base
An error occurred while downloading the remote file. The error
message, if any, is reproduced below. Please fix this error and try
again.
Couldn't open file /Downloads/packer-templates-develop/ubuntu-14.04/base
How can I start my packer-generated VM locally?
Is the only solution to keep track of the Vagrantfile manually?
Edit:
if I call vagrant init myNewlyCreatedBox.box
Then vagrant will try too boot the VM but
Failed to mount folders in Linux guest. This is usually because
the "prl_fs" file system is not available. Please verify that
Parallels Tools are properly installed in the guest and
can work properly. If so, the VM reboot can solve a problem.
The command attempted was:
mount -t prl_fs -o uid=`id -u vagrant`,gid=`getent group vagrant | cut -d: -f3` vagrant /vagrant
mount -t prl_fs -o uid=`id -u vagrant`,gid=`id -g vagrant` vagrant /vagrant
Those templates will generate a Vagrant box for you. If the process completes successfully you should have ubuntu-14-04-x64-virtualbox.box and ubuntu-14-04-x64-vmware.box file as specified by template.json file. To use those newly created boxes in Vagrant you'll need to add the one corresponding to your specific hypervisor to the list of boxes that Vagrant knows about by the following:
vagrant box add <nameToReferToBox> <pathToBoxYouJustCreated>
for example
vagrant box add ubuntu-14-04-x64 ubuntu-14-04-x64-virtualbox.box
Then to create an instance of that box (a VM) you can simply create a Vagrant file targeting the new box you just imported:
vagrant init ubuntu-14-04-x64
and then spin up a VM based on the base box:
vagrant up
I'm currently trying to create a virtual environment for wordpress development. I've installed Git Bash, ConEmu, Virtual Box, Vagrant, Vagrant Host updater, Vagrant triggers, and Varying Vagrant Vagrants. the first time I used vagrant up, I got this message:
default: Successfully added box 'ubuntu/trusty64' (v20150609.0.10) for 'virtualbox'! There are errors in the configuration of this machine. Please fix the following errors and try again:
vm: * The 'fix-no-tty' provisioner could not be found.
I don't really have any idea what this means and have had little success finding information on the internet. Does anyone know what the fix-no-tty provisioner is and how i could fix it?
I encountered the same issue today with a new clone of VVV while running Vagrant 1.6.3. The fix-no-tty provisioner was introduced on April 29. Named provisioner support was added to Vagrant in version 1.7.0. I upgraded to Vagrant 1.7.2 and was able to bring the VM up.
I know this is a stupid question, I'm still struggling to grok vagrant.
I run vagrant on a windows host, and I'm building Linux guest VMs using VirtualBox. My guest VM is running, and now I want to package it.
The Vagrant documentation says "A common misconception is that the --vagrantfile option will package a Vagrantfile that is used when vagrant init is used with this box. This is not the case. Instead, a Vagrantfile is loaded and read as part of the Vagrant load process when the box is used. For more information, read about the Vagrantfile load order."
Got it. But that's what I want to do! When I run "vagrant package --output myboxname.box", my carefully-crafted Vagrant file does not appear to be in the package. I test the box as follows (in Windows, after copying the new box):
cd \some_new_dir
vagrant box add myboxname.box --name boxname
vagrant init boxname
The new Vagrantfile is the generic vagrant version, with none of my changes.
When I
vagrant up
The vm comes up fine, but (not surprisingly) none of Vagrantfile directives have happened.
I know I'm missing something basic -- can someone please help me out?
Try copying the Vagrantfile from the directory you ran vagrant package in to the \some_new_dir directory. Then, without running vagrant init (because this will overwrite the Vagrantfile with an empty file), run vagrant up to use the Vagrantfile.
I made changes to my Vagrantfile (added config.vm.share_folder, config.vm.customize lines) and now I want them to show up on the box. Do I need to run
vagrant destroy && vagrant up
Or is it sufficient to run
vagrant reload
? I am unclear about whether vagrant reload will read anything from the Vagrantfile, since it seems to shutdown the VM and run the provisioner.
I don't think you need to destroy your VM. You can make changes to VM configuration when the VM is not running and powered down.
Try using vagrant halt and then vagrant up.
It should make the modifications to the VM as specified in Vagrantfile.
and you could also do vagrant up --no-provision to avoid re-provisioning as you bring up the VM.
and vagrant reload [vm-name] --no-provision should do the same trick.
vagrant reload is same as running vagrant halt followed by vagrant up please refer the doc for reload. Here is an excerpt from the doc
"This command is usually required for changes made in the Vagrantfile to take effect. After making any modifications to the Vagrantfile, a reload should be called." So in your case, I would suggest you to only use,
vagrant reload
Use:
vagrant reload --provision