Open rferguson10 opened 3 years ago
I find myself experiencing same problem as @rferguson10 but in a different environment as of this morning (~7:30 AM Pacific time).
2.2.15
Mac OS Big Sur 11.3
Ubuntu 20.04
Vagrant.configure("2") do |config|
config.vm.box = "bento/ubuntu-20.04"
config.vm.define('demo') do |demo|
demo.vm.provision 'chef_solo' do |chef|
chef.arguments = '--chef-license accept'
end
end
end
https://gist.github.com/ralfbetazi/ccf740f9e2267aa629165ef4f3d00f91
Command vagrant up
should launch a guest running Ubuntu 20.04.
Command vagrant up
exits with error. Final output reads:
==> demo: Running provisioner: chef_solo...
demo: Installing Chef (latest)...
Vagrant could not detect Chef on the guest! Even after Vagrant
attempted to install Chef, it could still not find Chef on the system.
Please make sure you are connected to the Internet and can access
Chef's package distribution servers. If you already have Chef
installed on this guest, you can disable the automatic Chef detection
by setting the 'install' option in the Chef configuration section of
your Vagrantfile:
chef.install = false
returning exit code 1.
Addendum to previous comment:
Saw issue #12338 and on assumption chef infra client installed but cleanup failed discovered an ugly stopgap workaround. One can get through provisioning by running vagrant up
once, letting it fail (chef is installed, but machine is not provisioned), disabling chef installation, then running vagrant provision
to complete provisioning. In other words:
vagrant up
. It will fail with the message described by the original poster, but chef-solo
is installed, but the cleanup failed.Vagrantfile
to add inside the chef-solo
provision block add the following line:
chef.install = false
vagrant provision
. The guest will provision using chef-solo
installed during Step 1.This ugly stopgap measure might keep others from being completely stymied by this issue until it can be more properly resolved.
As an alternative: You could set chef.version to "16" (wich should still work). This was the last version that works for me. Either it was the removal of knife or the version string is different now so Vagrant fails to detect?
I was still having this problem with vagrant 2.2.18
Looks like the problem was that chef 17 removed knife from the install:
INFO ssh: Execute: test -x /opt/chef/bin/knife (sudo=true) DEBUG ssh: stderr: 41e57d38-b4f7-4e46-9c38-13873d338b86-vagrant-ssh DEBUG ssh: Exit status: 1
After some reading I decided the best way to "fix" this is to add:
chef.product = "chef-workstation"
... to my Vagrantfile somewhere around the chef.arguments = "--chef-license accept"
bit
I searched a bit in the codebase, it seems that Vagrant is checking whether Chef is installed by testing if knife
binary exists, in plugins/provisioners/chef/cap/linux/chef_installed.rb.
For some reason, the chef-solo
installation doesn't come with knife
. This also matches @clayg 's solution, where chef-workstation
probably has the knife
binary.
@rferguson10 This should be fixed now in Vagrant 2.2.19
Vagrant version
Vagrant 2.2.15
Host operating system
Windows 10 Home
Guest operating system
Centos 8 and 8.3
Vagrantfile
Debug output
https://gist.github.com/rferguson10/a130b436c1106c1e8a170d88d3d65b88
Expected behavior
Chef should install into the guest OS and continue to provision using the provided recipe
Actual behavior
I'm presented with the following output:
Vagrant could not detect Chef on the guest! Even after Vagrant attempted to install Chef, it could still not find Chef on the system. Please make sure you are connected to the Internet and can access Chef's package distribution servers. If you already have Chef installed on this guest, you can disable the automatic Chef detection by setting the 'install' option in the Chef configuration section of your Vagrantfile:
Steps to reproduce