Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not all updates are being installed even when using multiple update-restart cycles #114

Closed
artiomello opened this issue Jun 17, 2022 · 3 comments

Comments

@artiomello
Copy link

artiomello commented Jun 17, 2022

Hello,

We're using packer to create Win Server 16/19/19 core/22 OVF templates in our vCenter. Seeing how it's a lot of manual work and time wasted for nothing - this plugin/provisioner is definitely a time savior for us, but not without its issues.

What've noticed is that not all updates are being installed on these 4 OS even after multiple update/restart cycles in the build block. After checking packer output logs and looking into the actual situation in the OS, we see that sometimes certain updates are installed in the first cycle, sometimes in the second or third. The fourth cycle is usually saying there are no new updates to install.

However when we boot up the supposedly updated image - there's always at least one update that is discovered by manually triggering win updates. And it's not something that was released just now - it can be some older security patch from April 2022 (and we're almost in July now) and perhaps some other update as well. Other times that other update is actually installed in the first cycle. Go figure.

Additionally, it seems that without using multiple cycles it's not possible to install cumulative updates, because they are appearing after some other updates plus a system reboot.

Right now we're putting 3 such cycles and still have to finalize with a manual update action:

<....>
  provisioner "windows-update" {
    pause_before = "2m"
    max_retries  = 2
  }

  provisioner "windows-restart" {
    pause_before = "5m"
    timeout      = "25m"
    max_retries  = 2
  }
<....>

It would be nice not have to play this guessing game of "how many cycles do I need" plus a manual finishing touch and have the provisioner actually do its job fully instead in a single provisioner "windows-update" { } block with clear instructions on required arguments to go with it.

@rgl
Copy link
Owner

rgl commented Jun 17, 2022

Its working for me at https://github.com/rgl/windows-vagrant. The only time I needed to fiddle with the default settings and use more than one provisioner step, was to first install the Servicing Stack Update update at rgl/windows-vagrant@e594a05. But with recent windows 10/2019/11/2022, a single provisioner "windows-update" {} with the default settings does the trick.

Maybe in your environment, its trying to install more than Microsoft updates (e.g. VMware drivers), and those might temporarily reconfigure/restart something that is being used by this plugin (e.g. the network might have a temporary blip/restart, and this plugin failed to recover from that situation). If that's the case, you can do like in:

https://github.com/rgl/windows-vagrant/blob/a9a819d0f291b59baf0b03c707f31c6b700a922d/windows-2022-vsphere.pkr.hcl#L122-L127

As an alternative, maybe you could use Ansible like in https://github.com/rgl/my-windows-ansible-playbooks/blob/8a8fd19b958cebe5c721e9fc08b54a17e7196e05/roles/base/tasks/main.yml#L59-L69.

@GertVanderstukken
Copy link

Also have a look at "Issue": Win2022 - "Optional quality update available
(#111)

Maybe that's your "problem"

@artiomello
Copy link
Author

Sorry for the delay in updates. Even without using any additional parameters, it's now working rather consistently with just two iterations that I put just to be on the safe side, I suppose.

I did however notice that on one of WS versions, 2016 if memory serves me right, regardless of how many update cycles I put in the config - it doesn't install some VMware drivers that are only discovered and installed when manually running Windows Update from the OS. Seeing how it's going out of support, I just left it at that, but might try to see if filters = ["include:$true"] will do the trick. Thanks for the tip!

Gonna close the issue for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants