Closed corbob closed 5 months ago
@chrisroberts do you happen to know when it is expected that this fix will be shipped in a release? Thank you!
@chrisroberts could we re-open this issue? It doesn't appear to be fixed, at least not in the latest release: https://github.com/hashicorp/vagrant/releases/tag/2.4.1.dev%2B000100-f33ac0bc. (I can get a fresh debug output if it's needed or would help)
@corbob Yep, thanks for the ping. The detection is working as expected now but the actual loading is failing so I'm investigating to determine the problem.
I'm dealing with the same issue. Do you maybe know any work-around before the fixes in the official release of the app?
@robmicah10 for me, I am using vagrant 2.3.6 on my Mac, and it works there for me.
@chrisroberts Thanks for working on this issue! The issue also exists on Arch Linux with Vagrant 2.4.0. That said, the current git version seems to have fixed the issue for me. Tested with Orange-Cyberdefense/GOAD, see https://github.com/Orange-Cyberdefense/GOAD/issues/141#issuecomment-1814321465
@chrisroberts I'm not sure if it's helpful, but I did some digging yesterday to see if I could fix the issue, and I have come up with some things that may or may not help:
I was trying to trace the code flow, and at one point deleted a bunch of lines of code (I don't remember which ones, but I believe they were mostly exception handling code). This led to an exception bubbling up about OpenSSL initialization failure with OpenSSL::Digest::DigestError
. Somehow I was lead to this issue: https://github.com/winrb/winrm/issues/340. On a whim, I found an older version of Ruby on homebrew and installed it. Using this older version of Ruby, my source build of vagrant did not exhibit this issue. So I kept upgrading my Ruby version until the issue started occuring again. It appears that with Ruby 3.2.1, the issue does not occur, but with 3.2.2 (the latest) it does. Obviously the answer isn't to downgrade the version of Ruby used, but hopefully knowing there's a change in there might be.
And for completeness sake: to circle back to what I said above about using 2.3.6
, if someone is using homebrew, an easy way to get that version is with a variation of this command: brew install --cask https://raw.githubusercontent.com/Homebrew/homebrew-cask/08e7a8455629e77bf7dbb63ed0a29a731a9bbee3/Casks/vagrant.rb
(note: you may need to do reinstall
if install
fails)
@chrisroberts I'm not sure which commit fixed it (actually, looking at the latest comment on that WinRb/WinRM issue, perhaps it's this commit bumping to Ruby 3.3: https://github.com/hashicorp/vagrant/commit/d7ec3bffe9ffd199b99e73d9fed8527897937c60), but it appears to be fixed for me on the latest 2.4.1 release:
Perhaps @robmicah10 might be able to test with 2.4.1 and confirm that it's not just my system that it's fixed for.
Hi @corbob. The fix for this issue is located in the vagrant-installers and was occurring due to the legacy algos bundle not properly getting marked as a file that should combined. As a result, only the arm64 architecture was being included in the file. Now it is a proper "fat" file including both architectures and loading as expected.
Cheers!
Debug output
https://gist.github.com/corbob/031f53b3eb860b183071b6973d3427f5
Expected behavior
vagrant up
should boot and provision the guest.Actual behavior
Reproduction information
Vagrant version
Vagrant 2.4.0
Host operating system
macOS 13.4.1
Guest operating system
Windows (version does not matter)
Steps to reproduce
vagrant init stefanscherer/windows_2022
vagrant up
Vagrantfile
I'm going to leave this out, because it is the most minimal Vagrantfile I know of...
Additional Details
I also saw this on Windows hosts, but those were resolved with vagrant 2.4.0. It seems related to https://github.com/hashicorp/vagrant/issues/13211, but that was for POP_OS.