chef-solo provisioner fails with a CookbookNotFound error if a reboot occurs after vagrant up

[sneal]

The chef provisioner symbolic links are broken after a reboot until the user opens a share through Explorer. This makes it impossible to run multiple provisioners where one of the steps reboots the box.

Repro:

1. vagrant up --no-provision
2. Reboot the box from the guest (and not through Vagrant)
3. After the box has rebooted run vagrant provision

[sneal]

This is similar, yet different than hashicorp/vagrant#1587

[kashook]

I hit this as well! I found that if you issue a "net use" command (with no additional arguments) that it seems to "wake up" the symbolic link.

[kashook]

In my case, my Vagrantfile had a shell provisioner that would reboot the box so that a new host name would take effect. Later in the same Vagrantfile I had a chef provisioner, and the chef run would fail with a CookbookNotFound error. I added another shell provisioner to my Vagrantfile after the reboot but before the chef provisioner that issues a net use command, and so far that seems to have eliminated the CookbookNotFound problems.

[sneal]

I've been playing with this fix locally in the chef-solo provisioner.:

@machine.communicate.execute('& net use a-non-existant-share', :error_check => false)

Sounds like you came up with the same solution 😄

I'd like to be able to have a single Vagrantfile with multiple provisioner blocks, some with reboots in between (we're talking about Windows here after all).

[sneal]

Fixed in 1.2.3

[kashook]

Nice! I actually got on here to report what I had found and to make a case for dealing with this problem in vagrant-windows (even though this problem is not vagrant-windows' fault) and ended up finding that you had logged this issue. I'd love to see the plugin deal with this so we don't have to put workarounds in our vagrantfiles. A net use with no additional arguments seems to do the trick, and I don't think it returns an error status like the non-existant-share would. (With no arguments I think all it does is list the current mapped drives).

[kashook]

When I started writing my last comment, you had not yet closed the issue. Feel free to ignore. :)

[sneal]

Cool. I just pushed the 1.2.3 gem.

I'll try tweaking the syntax in a future release, thanks!

[dawilliams]

sneal,

I just upgraded and retested this with vagrant-windows 1.2.3. Here the steps I ran. Did this fix address the failure on vagrant up or do you have to run vagrant provision after vagrant up?

1. vagrant up
   My cookbook triggers a reboot
   The machine reboots and Chef kicks off again automatically
   Chef fails with:
   Chef::Exceptions::CookbookNotFound: Cookbook windows not found. If you're loading windows from another cookbook, make sure you configure the dependency in your metadata

2. vagrant provision
   Chef kicks off
   Chef fails with:
   Chef::Exceptions::CookbookNotFound: Cookbook windows not found. If you're loading windows from another cookbook, make sure you configure the dependency in your metadata

   Chef kicks off again automatically
   Chef runs successfully

[sneal]

PR #122 fixes the the CookBookNotFound error when the chef provisioner fails on the first attempt and has to retry. The fix for #119 only fixed the issue if there was a reboot before the first attempt.

So yeah, this issue was only sort of fixed.

[dawilliams]

Ok, thanks for the follow up.