Trusty64 not found
curtismchale opened this issue · comments
I just pulled from master and the latest change to the default ubuntu box isn't found when I type vagrant up.
I rolled it back manually to precise32 and problems were resolved.
I was running everything else on the master branch, just the precise32 change was made.
Did you try a vagrant destroy? That's the recommended way to upgrade to 14.04.
b1764ce
You can also try vagrant box add ubuntu/trusty64. I haven't tried it, but it should work.
I always destroy since I work between 2 machines and sync everything with Dropbox. Halt leaves the DB locked to the VM on the other machine.
I will give that a try as well. I should also make sure that I'm running latest VirtualBox probably.
I'm having this same issue, even after detroy. Running vagrant box add ubuntu/trusty64 returns the same error. I'm using Vagrant 1.4.3, but I'll try updating to 1.5.4.
Well, it works fine with 1.5.4, so at least for me, 1.4.3 was the problem.
Ahhh, I forgot about that change. The new shorthand in Vagrant 1.5.x uses those box names instead of the full URL. We should probably check the Vagrant version or just use the full URL instead of the short name.
I updated Vagrant and Virtualbox and went back to the stock master branch. Everything works fine now.
I ran into this issue too. Updating Vagrant to latest version helped. Happened when I git pull because I was having issues with #287
Confirming that the old version of vagrant was the issue with trusty64 not being found.
FWIW, Vagrant 1.5.4 is more or less the minimum version for 1.2-working+.
Seems like upgrading Vagrant to latest version should resolve and copy the boxes over to the new trusty64. I wouldn't know though, I deleted my box while trying to figure out why it wouldn't work :)
Mine were previously on precise32
Once I upgraded Vagrant / Virtual Box, vvv was able to set itself up properly
The error seems to return on Vagrant 1.6.2
default: Downloading: https://vagrantcloud.com/ubuntu/trusty64/version/1/provider/virtualbox.box
An error occurred while downloading the remote file. The error
message, if any, is reproduced below. Please fix this error and try
again.
The requested URL returned error: 404 Not Found
compy386:vvv kraft$ vagrant -v
Vagrant 1.6.2
EDIT: Disregard. Opted to try it again and it went through. Must have been something with vagrantcloud.com.
Still not working, I just upgraded to Vagrant 1.6.5, tried both "trusty64" and "ubuntu/trusty64", quite frustrating really.
It seems I had the wrong box_url:
config.vm.box = "trusty64"
config.vm.box_url = "https://cloud-images.ubuntu.com/vagrant/trusty/current/trusty-server-cloudimg-amd64-vagrant-disk1.box"
It's working now.
I think the Vagrant 1.6.x requirement is good enough here. I would be willing to revisit if there's a good reason to stick with Vagrant 1.5.x.
The amd64 build of this image is definitely not there as of today 2014-11-26:
https://cloud-images.ubuntu.com/vagrant/trusty/current/
Index of /vagrant/trusty/current
Icon Name Last modified Size Description
[DIR] Parent Directory -
[ ] MD5SUMS 26-Nov-2014 04:57 80
[ ] MD5SUMS.gpg 26-Nov-2014 04:57 836
[ ] SHA1SUMS 26-Nov-2014 04:57 88
[ ] SHA1SUMS.gpg 26-Nov-2014 04:57 836
[ ] SHA256SUMS 26-Nov-2014 04:57 112
[ ] SHA256SUMS.gpg 26-Nov-2014 04:57 836
[ ] trusty-server-cloudimg-i386-vagrant-disk1.box 26-Nov-2014 04:57 354M Ubuntu Server 14.04 LTS (Trusty Tahr) daily builds
Apache/2.2.22 (Ubuntu) Server at cloud-images.ubuntu.com Port 443
+1 can confirm it's pointing at the wrong URL now (seems to have changed in past 24hrs).
Looks like the box URL used by Vagrant redirects to:
and only this image exists in the /current directory:
https://cloud-images.ubuntu.com/vagrant/trusty/current/trusty-server-cloudimg-i386-vagrant-disk1.box
Agree.. However you can get the build from a couple of days ago:
Just put this as the value of 'config.vm.box_url' in your vagrant file. Not ideal, but it seems to works.
Edit: as pointed out by @keeran that link was for the 32 bit version.
Use instead: https://cloud-images.ubuntu.com/vagrant/trusty/20141125/trusty-server-cloudimg-amd64-vagrant-disk1.box
Yes that's right -- I just realized I had linked to the 32-bit version, apologies!
Note: the box is now back in current/.
I was using windows 7 and trying to get vagrant up to work - kept getting trusty not found, so finally I followed this https://stackoverflow.com/questions/34848146/vagrant-error-the-box-hashicorp-precise32-could-not-be-found-windows-10-d/34848147#34848147 and that solved the problem! Note - I am NOT a windows 7 user anymore lol.. I use Ubuntu - but my developers use win 7 so needed to create a guide for them to use vagrant on win 7!
Ditto for firecentaur's note. I'm also Win7/x64 / vagrant 1.8.1 and got the same vague error message about "'ubuntu/trusty64' could not be found." For me it was resolved by installing the VC10 x86 runtimes: https://www.microsoft.com/en-us/download/details.aspx?id=8328
Just installing VC ++ 2010 x86 has resolved my issue on win 8.1 with vagrant 1.8.4
@waqariz +1, you are goddamn right
The solution @mrosen provided fixed this on Windows 10 x64 with Vagrant 1.8.5.
I'm using mac os v 10.12.1 - i removed the curl that was packaged with vagrant in /opt/vagrant/embedded/bin so that it would use the version installed by the os and it fixed the problem for me.
Usinx OSX 10.11.6, I had the same problem and followed the suggestion of @knesbit to remove the vagrant version of curl, which fixed the problem.
I had the same problem and @kensbit solution worked for me.
@knesbit's solution worked well for me.
@knesbit solution worked for me also. Well done on fixing that 👍
Can anyone write this up for the wiki?
Same for me: @knesbit solution solves my problem 👍
As suggested by @knesbit, removing vagrant's curl fixes the issue on macOS Sierra (10.12.1). Thanks!
Yeah just ran into this issue, removing the Vagrant curl resolved it -- sudo rm /opt/vagrant/embedded/bin/curl
I'm on El Capitan, and removing the embedded curl worked for me as well.
It looks like there were a couple waves of possibilities on this ticket. I'm going to reopen as something that should be documented more officially as an FAQ.
Same here, on OSX Yosamite 10.10.5 (14F2009) - deleting the curl file fixed the vagrant up step
Confirm on macOS latest Sierra.
Confirming this issue exists and @knesbit solution works.
@mkjonesuk Just ran into this same issue this morning!
sudo rm /opt/vagrant/embedded/bin/curl fixed it for me too.
How is this an issue from May 8, 2014 and still not resolved? Brand new computer with MacOS Sierra and executing sudo rm /opt/vagrant/embedded/bin/curl fortunately worked for me too.
This issue is a Vagrant issue, it didn't have anything to do with VVV specifically for me (FYI)
Agreed - this is nothing to do with vvv. I eventually downgraded to an older version of Vagrant and no longer have the problem.
I am on El Capitan, sudo rm /opt/vagrant/embedded/bin/curl worked for me too. Thanks!
sudo rm /opt/vagrant/embedded/bin/curl worked for me too.Thanks
vagrant -v
Vagrant 1.8.7
We should point this issue to vagrant project tho.
It looks like the Vagrant development team is aware of this issue but have been dragging their feet at releasing Vagrant 1.8.8:
hashicorp/vagrant#7969
Needed to run this today (sudo rm /opt/vagrant/embedded/bin/curl) on OSX on Vagrant 1.8.7
Had to run
sudo rm /opt/vagrant/embedded/bin/curl
MacOS 10.12.1
Vagrant 1.8.7
+1 this is quite annoying but sudo rm /opt/vagrant/embedded/bin/curl works
was getting the same:
The box 'ubuntu/trusty64' 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/ubuntu/trusty64"]
but doing this as @wallnerryan commented fixed it for me,
sudo rm /opt/vagrant/embedded/bin/curl
I had HTTP2 custom curl enabled for my dev environment,
sudo rm /opt/vagrant/embedded/bin/curl works
I'm going to close this one out now that a solution appears to have been found. If anybody encounters this on the newer VVV 2 and replicate on the develop branch, please open a new ticket
I tried everything. I was on fresh install of Windows 10 and Vagrant 1.9, so I downloaded curl for windows. I also removed the curl in C:/Vagrant/embedded/ . And like @robvdl suggested, I made sure I was downloading the right box. It finally worked.
config.vm.box = "ubuntu/trusty64"
config.vm.box_url = "https://cloud-images.ubuntu.com/vagrant/trusty/current/trusty-server-cloudimg-amd64-vagrant-disk1.box"
Ah the current version of Vagrant at the moment is 2.0.2, you should uninstall 1.9 then do a clean upgrade to 2.0.2
$ vagrant box add ubuntu/trusty64
==> box: Loading metadata for box 'ubuntu/trusty64'
box: URL: https://vagrantcloud.com/ubuntu/trusty64
==> box: Adding box 'ubuntu/trusty64' (v20180201.0.1) for provider: virtualbox
box: Downloading: https://vagrantcloud.com/ubuntu/boxes/trusty64/versions/20180201.0.1/providers/virtualbox.box
==> box: Box download is resuming from prior download progress
box:
An error occurred while downloading the remote file. The error
message, if any, is reproduced below. Please fix this error and try
again.
how to fix it
@rajupydi did you use a USB drive on a contributor day to setup a VVV install, at any point on your machine, even if you then deleted everything?
If so, you need to remove the ubuntu/trusty64 box then try again.
If not, then I don't know, that's a generic Vagrant issue, not a VVV issue.
Again, make sure you are on the latest version of Vagrant, the current latest version is 2.0.2. If in doubt, uninstall Vagrant and install the latest version ( vagrantup.com )
Just to repeat:
If anybody encounters this on the newer VVV 2 and can reproduce it on the develop branch, open a new ticket
it will fix your error.
run command "vagrant destroy".
use version 5.18 of virtual box.
then install version 1.9.2 of vagrant.
restart your computer.
now go to the directory you want to work in.
"vagrant init ubuntu/trusty64" run command.
"vagrant up" run command.
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.