I was experiencing this issue with both Ansible 1.8.1 and 2.0.2. I just found that now it seems to only spit out that warning when checking for updates; not when downloading new images. If I remove the older image to force it to re-download, it does seem to work. But after re-downloading the image, it gets an error checking to see if the image is up-to-date.
I have no idea what's going on, but at least it doesn't seem to be hindering our development environments... yet. $ cd ~/Development/metron/metron-deployment/development/ubuntu14 $ vagrant box outdated /Users/nallen/Development/metron/metron-deployment/development/ubuntu14/Vagrantfile:28: warning: constant ::TRUE is deprecated Running with ansible-skip-tags: ["sensors"] DEPRECATION: The 'sudo' option for the Ansible provisioner is deprecated. Please use the 'become' option instead. The 'sudo' option will be removed in a future release of Vagrant. Checking if box 'ubuntu/trusty64' is up to date... There was a problem while downloading the metadata for your box to check for updates. This is not an error, since it is usually due to temporary network problems. This is just a warning. The problem encountered was: The requested URL returned error: 404 Not Found If you want to check for box updates, verify your network connection is valid and try again. $ vagrant box remove ubuntu/trusty64 --all $ vagrant up /Users/nallen/Development/metron/metron-deployment/development/ubuntu14/Vagrantfile:28: warning: constant ::TRUE is deprecated Running with ansible-skip-tags: ["sensors"] DEPRECATION: The 'sudo' option for the Ansible provisioner is deprecated. Please use the 'become' option instead. The 'sudo' option will be removed in a future release of Vagrant. Bringing machine 'node1' up with 'virtualbox' provider... ==> node1: Box 'ubuntu/trusty64' could not be found. Attempting to find and install... node1: Box Provider: virtualbox node1: Box Version: >= 0 ==> node1: Loading metadata for box 'ubuntu/trusty64' node1: URL: https://vagrantcloud.com/ubuntu/trusty64 ==> node1: Adding box 'ubuntu/trusty64' (v20180125.0.0) for provider: virtualbox node1: Downloading: https://vagrantcloud.com/ubuntu/boxes/trusty64/ versions/20180125.0.0/providers/virtualbox.box ==> node1: Successfully added box 'ubuntu/trusty64' (v20180125.0.0) for 'virtualbox'! ==> node1: Importing base box 'ubuntu/trusty64'... ==> node1: Matching MAC address for NAT networking... ==> node1: Checking if box 'ubuntu/trusty64' is up to date... ==> node1: There was a problem while downloading the metadata for your box ==> node1: to check for updates. This is not an error, since it is usually due ==> node1: to temporary network problems. This is just a warning. The problem ==> node1: encountered was: ==> node1: ==> node1: The requested URL returned error: 503 Service Unavailable ==> node1: ==> node1: If you want to check for box updates, verify your network connection ==> node1: is valid and try again. ==> node1: Setting the name of the VM: ubuntu14_node1_1517850259612_86441 ==> node1: Clearing any previously set forwarded ports... ==> node1: Clearing any previously set network interfaces... ==> node1: Preparing network interfaces based on configuration... node1: Adapter 1: nat node1: Adapter 2: hostonly ==> node1: Forwarding ports... node1: 22 (guest) => 2222 (host) (adapter 1) ==> node1: Running 'pre-boot' VM customizations... ==> node1: Booting VM... ==> node1: Waiting for machine to boot. This may take a few minutes... node1: SSH address: 127.0.0.1:2222 node1: SSH username: vagrant node1: SSH auth method: private key On Mon, Feb 5, 2018 at 11:48 AM, Michael Miklavcic < michael.miklav...@gmail.com> wrote: > I had this problem on a machine running Vagrant 1.8.1. I thought it was > only Ubuntu at first, so I removed some additional boxes and found it to be > a problem for all of them. I didn't see any relevant articles other than > some old stuff talking about a bundled curl command being a problem, but > that didn't help anything. Not surprising since the URL being attempted > with curl didn't work via browser either. 404, as Nick mentioned. > > {17:08}~ ➭ vagrant box add hashicorp/precise64 > The box 'hashicorp/precise64' could not be found or > could not be accessed in the remote catalog. If this is a private > box on HashiCorp's Atlas, please verify you're logged in via > `vagrant login`. Also, please double-check the name. The expanded > URL and error message are shown below: > > URL: ["https://atlas.hashicorp.com/hashicorp/precise64"] > Error: The requested URL returned error: 404 Not Found > > My last ditch attempt here was to upgrade Vagrant to 2.0.2. That seems to > have fixed it for me, but per their warning message I'm not sure if this > new location is permanent or if OSS Hashicorp Vagrant consumers need to > find an alternative. The new location appears to be > https://vagrantcloud.com > . > > Mike > > > > On Mon, Feb 5, 2018 at 6:45 AM, Nick Allen <n...@nickallen.org> wrote: > > > When launching either of the development environments, you are probably > > seeing a warning message like this. > > > > Bringing machine 'node1' up with 'virtualbox' provider... > > > ... > > > ==> node1: There was a problem while downloading the metadata for your > > box > > > ==> node1: to check for updates. This is not an error, since it is > > usually > > > due > > > ==> node1: to temporary network problems. This is just a warning. The > > > problem > > > ==> node1: encountered was: > > > ==> node1: > > > ==> node1: The requested URL returned error: 404 Not Found > > > ==> node1: > > > ==> node1: If you want to check for box updates, verify your network > > > connection > > > ==> node1: is valid and try again. > > > > > > > > I believe the problem is that Hashicorp has chosen to no longer host the > > base images that we rely on (outside of paying enterprise customers.) > > > > The Packer, Artifact Registry and Terraform Enterprise (Legacy) features > of > > > Atlas will no longer be actively developed or maintained and will be > > fully > > > decommissioned on Friday, March 30, 2018. Please see our guide on > > building > > > immutable infrastructure with Packer on CI/CD for ideas on implementing > > > Packer and Artifact Registry features yourself and the Upgrading From > > > Terraform Enterprise (Legacy) guide to migrate to the new Terraform > > > Enterprise. > > > > > > > > If you already have the base images downloaded, do not delete them! The > > development environments will continue to work as long as you have those > > images. > > > > The problem is that new users will no longer be able to download these > > images. And ultimately I am suspect that future updates will occur on > > these base images. > > > > Is everyone experiencing this problem? Does anyone have any other > details > > to share on this? > > > > I am concerned that this is going to force us into some significant work > in > > the short-term to ensure that our development environments continue to > > work. I have some alternative options to discuss, but I want to make > sure > > we have all the information on what's happening before discussing those. > > >