Hm, now that is interesting. I'm not clear how they manage their URLs, but it seems like they may have missed a hardcoded value used by their update functionality.
On Feb 5, 2018 3:01 PM, "Nick Allen" <n...@nickallen.org> wrote: > 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. > > > > > >
