Vagrant-ssh, Chocolatey, Dotnet, WMF errors & chatGPTs responses
jetson02 opened this issue · 8 comments
Issue Description
I've been trying to get meta3 running for a couple weeks. I've tried on ubuntu as well as kali, with automatic build and manual, with qemu and virtualbox and they all end up with the same errors. The most recognizable being when the script runs vagrant-ssh.ps1 & chocolatey.ps1. Both give the same very long error(s).
In searching the problem I noticed someone with the same errors mention DotNet wasn't downloading, so I looked & found the same thing in the VM's logs. dotnet-install.log says failed to download file, and the Windows Management Framework 5 install log says the same, yet OpenSSH downloads, installs, and works fine, & I can browse & DL within the VM. (Does the problem start with a failed download or update?) I've tried using different network settings, and went to other forks and even found an ovf of a meta3 VM but can't get it to load on my system. I'd tried setting this up before doing all the latest updates, as well as afterwards, and I've tried purging all the necessary programs, rebooting, and reinstalling them multiple times.
I ran the errors from vagrant-ssh & chocolatey below through chatGPT & included its responses below, but I also posted the vagrant-ssh code & it finds nothing wrong with it. The errors I receive are really much longer and full of mess but I cleaned them up for posting.
I'd really appreciate any assistance and love to hear from anyone that has the VM operational using the latest versions available.
Thank you
Host System
- OS:6.0.0-kali6-amd64 (update & upgrade & dist-upgrade 1/14/23)
- Packer Version: 1.6.6 (latest as of 1/14/23)
- Vagrant Version: 2.3.4 (latest as of 1/14/23)
- VirtualBox Version: 7.0.4 (latest as of 1/14/23)
Command Output
">Exception setting "SecurityProtocol": "Cannot convert null to type due to invalid enumeration values. Specify one of the folowing enumeration values and try again. The possible enumeration values aresl3, Tls[Net.ServicePointManager]:: SecurityProtocol = [Net.SecurityProtol::Tls12;
ChatGPT: "The error message states that the value provided is not a valid enumeration value and suggests that either "Ssl3" or "Tls" should be used instead."
DownloadFile('https://raw.githubusercontent.com/mitchellh/vagrant/master/keys/vagrant.pub', 'C:\Users\vagrant.ssh\authorized_keys'+ CategoryInfo InvalidOperation: (:) [], RuntimeException_Error"> FullyQualifiedErrorId : PropertyAssignmentException="Error">Exception calling "DownloadFile" with "2" argument(s):
ChatGPt: "This is an error message indicating that there is a problem with a script or code that is attempting to download a file from a URL using the .DownloadFile method of the System.Net.WebClient class. The error message states that there was an issue with the underlying connection and that it was closed with an "unexpected error occurred on a send." Additionally, it seems to be indicating that this error occurred at line 2, character 135 in some script or code.
It's also indicating that there is a problem with the SecurityProtocol settings, which is being set to Tls12.
It is also indicating that the PropertyAssignmentException and DotNetMethodException are occurred.
It is recommended to check your internet connection, URL, and the SecurityProtocol settings to fix the issue."
Same issues!
Simple solution: Download all install file require in scripts folder and attach to guest instead of download need SSL/TLS by guest!
Duplicates #575 as new pattern is needed adjust download process for these initial files.
As a primary maintainer on this project closing duplicate issues reporting a known problem and linking the reports has value. Even closed issues can be found in search.
@jetson02, I have fully reviewed this report, the issue is rooted in the reference to Tls[Net.ServicePointManager]:: SecurityProtocol = [Net.SecurityProtol::Tls12; this is what the issue I linked documents. The download failure is due to the need for TLS 1.2 to be available in the VM during the build. My evaluation is also in line with what your own ChatGPT search identified. By referencing the issue when closing I have added a comment breadcrumb to lead users to the root cause. The response may have been a bit terse, however closing was not rash by any means. Since the issue was not locked it can be reopened if it is found that my conclusion is incorrect.
If you are just looking to get a working version of the VM you can use the Quick-start method and have vagrant download the last build that completed and publish prior to the TLS issue with downloading external resources by the guest OS, instead of building from scratch.
To offer solutions to the issue I linked or ideas on how to address it, please look over that issue and the comments there. Note the possible approach to addressing it or offer new ideas in that issue. PRs are welcome if you have a working solution to restore end-to-end capabilities to build the Windows VM from scratch.
Request provider [:libvirt]
The message from vagrant states that vagrant is configured for libvirt instead of virtualbox as noted in your original report. Currently VMs are published in vagrantcloud for vmware and virtualbox only. If you configure vagrant to use virtualbox you may be able to utilize a downloaded VM from vagrantcloud.
How is anyone going to connect the vagrantssh.ps1 fail (where dotnet's failure causes the 1st error message; ) with that dotnet issues post?
Marking this report as a duplicate of that issue is how users can now link the issues together, I for one appreciate your report here as perspective and output can be different for various environments. This issue and the various other I linked this week will aid future users in finding that the failures were related. In a perfect world the original issue would have been resolved before this issue was opened.
#575 was opened when the issue was found and it notes the first error message as the root cause, I suspect the same log line was seen on at least one of your test runs. Unfortunately there are later errors from provisioners as packer does not recognize the issue occurring during initial OS install which allows provisioners to attempt to execute further steps.
Hopefully the solution for installation of dotnet and powershell that just landed fixes the build for your environment. It was tested with virtualbox and vmware however it should also meet the requirements for libvirt as well.