chocolatey / chocolatey-ansible

The Chocolatey module collection for Ansible
GNU General Public License v3.0
47 stars 29 forks source link

win_chocolatey fails to install completely #118

Open LukeSemikin-CAL opened 1 year ago

LukeSemikin-CAL commented 1 year ago

Checklist

What You Are Seeing?

When using win_chocolatey to install any packages as part of a packer build, the win_chocolatey steps fails with error:

vsphere-iso.windows2019: fatal: [default]: FAILED! => {"changed": true, "msg": "Failed to find choco.exe, make sure it is added to the PATH or the env var 'ChocolateyInstall' is set", "rc": 0}

Packer uses a winrm connection to connect in, with the task being:

name: Install OpenSSH win_chocolatey: name: openssh state: present I managed to pause the build to see the status of the choco install by ansible within the C:/ProgramData/chocolatey directory and its an incomplete install. Only the lib directory existing, instead of the expected multiple directories with a bin directory expected, containing the choco.exe.

Steps taken to fix this include:

Installing choco prior to running ansible -> ansible doesnt respect this choco install so fails Installing choco through nuget within ansible -> ansible doesnt respect this choco isntall either Installing choco with name: Install OpenSSH win_chocolatey: name: chocolatey state: present and then installing OpenSSH once on the system -> fails as tries to install choco Adding path prior to installing choco -> obviously fails as the choco.exe doesnt exist

What is Expected?

Choco should be successfully installed prior to attempting to install any other packages.

How Did You Get This To Happen?

Create a task with this included (or any choco install)

name: Install OpenSSH win_chocolatey: name: openssh state: present

Execute a packer build with an ansible provisioner calling the task to configure a windows virtual machine on vsphere (don't know if this issue exists on other platforms).

System Details

Installed Packages

Attempting any package fails, related to the chocolatey install that occurs when running win_chocolatey for the first time on any new vm.

Output Log

choco : The term 'choco' is not recognized as the name of a cmdlet, function, script file, or operable program. Check
the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ choco
+ ~~~~~
    + CategoryInfo          : ObjectNotFound: (choco:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Occurs as win_chocolatey fails to install chocolatey properly.

Additional Context

No response

pauby commented 1 year ago

You mentioned you are installing it on Windows Server 2019? Chocolatey CLI 2.0.0 requires .NET 4.8 to be installed, which the installation script will install for you, but it requires a reboot. If you reboot your Packer build at that point and try the installation again, does it work?

Alternatively, you could install .NET 4.8, reboot, then try to install Chocolatey CLI.

See the upgrade guide for more information.

LukeSemikin-CAL commented 1 year ago

@pauby thanks for the reply. I have tried this aswell unfortunately.

Using the task which should install choco:

with a subsequent reboot (win_reboot) step also fails. It never actually tries to reach the reboot step as win_chocolatey tries to install chocolatey and fails with the same error message.

Ive managed to fix the issue, by instead of handling installation as part of the win_chocolatey module, extracting the chocolatey directory from a working manually configured vm from its C:/ProgramData/. This is then copied over as part of the role with values set for the required environmental variables. I wonder if adding a block rescue around the above task to then always trigger a reboot may resolve the issue. Then can retry installing choco. Ill also try installing net 4.8 outside of the choco install as a pre-requisite to see if this fixes the issue as moving the directory is a messy and non-ideal way of dealing with this.

Windos commented 1 year ago

I've been looking into this a bit today and I don't think the specific issue you're reporting here is related to Chocolatey CLI 2.0.0 and its requirement on .NET 4.8 (though that will certainly come into play and need to be addressed) as the error messages you would get from that are different from what you're seeing.

@LukeSemikin-CAL, which version of the chocolatey.chocolatey Ansible collection are you running on your Ubuntu runner?

This looks similar to #58 which was fixed in v1.2.0 of the collection that was released early last year. If you're on a newer version than that we may need to get some additional information about what's happening during the Chocolatey CLI install.

jonlofty commented 1 year ago

We received this exact same issue in our Packer Build pipelines when using the Win_Choco command.

After investigation I believe the issue comes from the run of "win_chocolatey.ps1" trying to pull in the latest version of Choco (now the 2.0.0 CLI).

We are using an older version of the pip ansible package, but it is a larger piece of work to upgrade/test 8.0 we can't currently commit to (so this issue may be resolved there?)

Using module file /usr/local/rlg/venv/python3.8/ansible-4.8.0/lib/python3.8/site-packages/ansible_collections/chocolatey/chocolatey/plugins/modules/win_chocolatey.ps1

I believe this script fails due to .Net 4.8 Framework not being pre installed on the image.

[WARNING]: Chocolatey was missing from this system, so it was installed during this task run.

msg: Failed to find choco.exe, make sure it is added to the PATH or the env var 'ChocolateyInstall' is set rc: 0

We were able to resolve this adding a role to our Playbook invoked by Ansible/Packer that installed .Net 4.8 directly from Microsoft and did a reboot if required.

- name: Installing .NET Framework 4.8
  win_package:
    path: "https://go.microsoft.com/fwlink/?LinkId=2085155"
    product_id: none
    state: present
    arguments: /q
  register: install_response

- win_reboot:
  when: install_response.changed == true and install_response.rc == 3010

Hopefully this helps resolve the issue for you @LukeSemikin-CAL

github-actions[bot] commented 1 week ago

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? This issue will be closed in 14 days if it continues to be inactive.