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

Vagrant 2.4.0 is not using the most recently published box #13274

Closed
gebailey opened this issue Oct 18, 2023 · 3 comments · Fixed by #13278
Closed

Vagrant 2.4.0 is not using the most recently published box #13274

gebailey opened this issue Oct 18, 2023 · 3 comments · Fixed by #13278

Comments

@gebailey
Copy link

I'm a vagrant cloud box author, and I publish periodic versions of the gbailey/amzn2 box. The current version is v20231004.0.0 and has the amd64 architecture tag associated with the virtualbox provider. The older versions of this box have unknown 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 the v20230914.0.0 version that has the unknown architecture. Similarly, operations like vagrant 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

  1. Clear .vagrant.d configuration files
  2. vagrant init gbailey/amzn2
  3. vagrant up

Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :

# All Vagrant configuration is done below. The "2" in Vagrant.configure
# configures the configuration version (we support older styles for
# backwards compatibility). Please don't change it unless you know what
# you're doing.
Vagrant.configure("2") do |config|
  # The most common configuration options are documented and commented below.
  # For a complete reference, please see the online documentation at
  # https://docs.vagrantup.com.

  # Every Vagrant development environment requires a box. You can search for
  # boxes at https://vagrantcloud.com/search.
  config.vm.box = "gbailey/amzn2"

  # Disable automatic box update checking. If you disable this, then
  # boxes will only be checked for updates when the user runs
  # `vagrant box outdated`. This is not recommended.
  # config.vm.box_check_update = false

  # Create a forwarded port mapping which allows access to a specific port
  # within the machine from a port on the host machine. In the example below,
  # accessing "localhost:8080" will access port 80 on the guest machine.
  # NOTE: This will enable public access to the opened port
  # config.vm.network "forwarded_port", guest: 80, host: 8080

  # Create a forwarded port mapping which allows access to a specific port
  # within the machine from a port on the host machine and only allow access
  # via 127.0.0.1 to disable public access
  # config.vm.network "forwarded_port", guest: 80, host: 8080, host_ip: "127.0.0.1"

  # Create a private network, which allows host-only access to the machine
  # using a specific IP.
  # config.vm.network "private_network", ip: "192.168.33.10"

  # Create a public network, which generally matched to bridged network.
  # Bridged networks make the machine appear as another physical device on
  # your network.
  # config.vm.network "public_network"

  # Share an additional folder to the guest VM. The first argument is
  # the path on the host to the actual folder. The second argument is
  # the path on the guest to mount the folder. And the optional third
  # argument is a set of non-required options.
  # config.vm.synced_folder "../data", "/vagrant_data"

  # Disable the default share of the current code directory. Doing this
  # provides improved isolation between the vagrant box and your host
  # by making sure your Vagrantfile isn't accessable to the vagrant box.
  # If you use this you may want to enable additional shared subfolders as
  # shown above.
  # config.vm.synced_folder ".", "/vagrant", disabled: true

  # Provider-specific configuration so you can fine-tune various
  # backing providers for Vagrant. These expose provider-specific options.
  # Example for VirtualBox:
  #
  # config.vm.provider "virtualbox" do |vb|
  #   # Display the VirtualBox GUI when booting the machine
  #   vb.gui = true
  #
  #   # Customize the amount of memory on the VM:
  #   vb.memory = "1024"
  # end
  #
  # View the documentation for the provider you are using for more
  # information on available options.

  # Enable provisioning with a shell script. Additional provisioners such as
  # Ansible, Chef, Docker, Puppet and Salt are also available. Please see the
  # documentation for more information about their specific syntax and use.
  # config.vm.provision "shell", inline: <<-SHELL
  #   apt-get update
  #   apt-get install -y apache2
  # SHELL
end
@gebailey
Copy link
Author

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.

@chrisroberts
Copy link
Member

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.

@ilearner777
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 5, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants