Closed gebailey closed 8 months ago
FWIW, if I run the reproduction steps on a CentOS 7 (x64) box, I get the expected, most recent box, so the Linux vagrant
cli appears to behave in the expected manner.
This dev build includes the above modifications and shows the correct behavior. Setting the VAGRANT_HOST_ARCHITECTURE
environment variable to "amd64"
will provide a temporary workaround for the 2.4.0 release until the next point release is shipped.
This dev build includes the above modifications and shows the correct behavior. Setting the
VAGRANT_HOST_ARCHITECTURE
environment variable to"amd64"
will provide a temporary workaround for the 2.4.0 release until the next point release is shipped.
Thanks, Will try it out.
I'm a vagrant cloud box author, and I publish periodic versions of the
gbailey/amzn2
box. The current version isv20231004.0.0
and has theamd64
architecture tag associated with thevirtualbox
provider. The older versions of this box haveunknown
as the architecture.If I clear my vagrant configuration, and perform a
vagrant init gbailey/amzn2
operation, the box that is used is NOT the most recent one, but rather thev20230914.0.0
version that has theunknown
architecture. Similarly, operations likevagrant box update
, etc., do not download the most recent box.It's not clear from the documentation how or if I should be specifying my host architecture, but I would expect the most recent box to be used. I'm running vagrant 2.4.0 on Windows 11 (x64), with VirtualBox 7.0.12.
Debug output
https://gist.github.com/gebailey/03a39a43fd5921284c4c7bd247b09db2
Expected behavior
The most recent box for my architecture
v20231004.0.0
would be used.Actual behavior
An older box
v20230914.0.0
was used.Reproduction information
Vagrant version
2.4.0
Host operating system
Windows 11
Guest operating system
Amazon LInux 2
Steps to reproduce
vagrant init gbailey/amzn2
vagrant up
Vagrantfile