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.
> >
>

Reply via email to