Error downloading box: "bsdtar: Inconsistent compressed size" [Windows 10]

[dwickern]

The following command fails: vagrant box add withinboredom/Trusty64

Based on the debug output, I ran the same commands manually. bsdtar exits with code 1 due to a warning, although it appears to decompress the files just fine.

C:\Users\dwickern>"C:\\HashiCorp\\Vagrant\\embedded\\bin/curl.EXE" "-q" "--fail" "--location" -k "--max-redirs" "10" "--user-agent" "Vagrant/1.8.1 (+https://www.vagrantup.com; ruby2.2.3)" "--continue-at" "-" "--output" "C:/Users/dwickern/.vagrant.d/tmp/box5f63298963885f6dc0ed728a14e304f93139a2ad" "https://atlas.hashicorp.com/withinboredom/boxes/Trusty64/versions/0.2.0/providers/hyperv.box"
C:\Users\dwickern>"C:\\HashiCorp\\Vagrant\\embedded\\gnuwin32\\bin/bsdtar.EXE" "-v" "-x" "-m" "-C" "C:/Users/dwickern/.vagrant.d/tmp/vagrant-box-add-temp-20160223-4692-12wg7u4" "-f" "C:/Users/dwickern/.vagrant.d/tmp/box5f63298963885f6dc0ed728a14e304f93139a2ad"
x metadata.json
x Virtual Hard Disks/
bsdtar.EXE: Inconsistent compressed size
x Virtual Hard Disks/ubuntu-14.vhdx
x Virtual Machines/
x Virtual Machines/50BA5128-D926-4617-92AC-737C14256032.XML
bsdtar.EXE: Error exit delayed from previous errors.

My workaround was to replace bsdtar.exe with this one from the mingw distribution

Vagrant version

fails on version 1.8.1 and 1.7.4

Host operating system

fails on Windows 10 and Windows Server 2016 TP4

[ByteJuggler]

Ran into this issue today. Running on Windows 10 x64 (Version 10.0.10586) and Vagrant 1.8.1, bsdtar 3.1.2 (libarchive 3.1.2) as reported via ""c:\HashiCorp\Vagrant\embedded\gnuwin32\bin\bsdtar.exe" --version". (As an aside, I had to copy zlib1.dll from C:\HashiCorp\Vagrant\embedded\bin\zlib1.dll to be able to run this from the command line.)

I note that curiously there is another version of bsdtar.exe installed under "C:\HashiCorp\Vagrant\embedded\mingw\bin\bsdtar.exe". This version (as of this writing) is bsdtar 2.8.3 (libarchive 2.8.3). Why are 2 versions are included?

It turns out that replacing the gnuwin32 version with the one linked above from the mingw distribution, effectively reverts it back from 3.1.2 to 2.8.3. I can also confirm as reported above by dwickern that this works around the issue for me.

The workaround/version numbers seems to suggest that this issue would not exist if Vagrant used the mingw (2.8.3) version of bsdtar (which is also included in the distribution.) It makes me wonder why the (newer) gunwin32 version is persent at all? Is is perhaps the case that this issue can be "fixed" (for the time being) by simply removing the gnuwin32 version of bsdtar? Why does Vagrant include 2 versions of bsdtar?

[phawxby]

Experiencing the same problem too. I'm also attempting to create a box today but compressing with 7zip to zip always results in this error.

C:\Users\z269cjbb\Downloads\vagrant box\exported>vagrant box add TestTrusty "Trusty Tahr.box"
==> box: Box file was not detected as metadata. Adding it directly...
==> box: Adding box 'TestTrusty' (v0) for provider:
    box: Unpacking necessary files from: file://C:/Users/z269cjbb/Downloads/vagrant%20box/exported/Trusty%20Tahr.box
    box: Progress: 100% (Rate: 382M/s, Estimated time remaining: --:--:--)
The box failed to unpackage properly. Please verify that the box
file you're trying to add is not corrupted and try again. The
output from attempting to unpackage (if any):

x metadata.json
x Vagrantfile
x Virtual Hard Disks/
bsdtar.EXE: Inconsistent compressed size
x Virtual Hard Disks/Trusty Tahr.vhdx
x Virtual Machines/
x Virtual Machines/B855AD48-BC31-4264-86D5-7F05939869AE.vmcx
x Virtual Machines/B855AD48-BC31-4264-86D5-7F05939869AE.VMRS
bsdtar.EXE: Error exit delayed from previous errors.

[chrisroberts]

@dwickern Can you confirm if this is still an issue with the latest release of Vagrant? Thanks!

[Sisyphus67]

I can; I am running into the issue myself:

PS C:\Users\jeffrey\PycharmProjects\networking> vagrant --version
Vagrant 1.9.1
PS C:\Users\jeffrey\PycharmProjects\networking>

PS C:\Users\jeffrey\PycharmProjects\networking> vagrant box add withinboredom/Trusty64
==> box: Loading metadata for box 'withinboredom/Trusty64'
box: URL: https://atlas.hashicorp.com/withinboredom/Trusty64
This box can work with multiple providers! The providers that it
can work with are listed below. Please review the list and choose
the provider you will be working with.

1. hyperv
2. virtualbox

Enter your choice: 1
==> box: Adding box 'withinboredom/Trusty64' (v0.2.0) for provider: hyperv
box: Downloading: https://atlas.hashicorp.com/withinboredom/boxes/Trusty64/versions/0.2.0/providers/hyperv
.box
box: Progress: 100% (Rate: 3265k/s, Estimated time remaining: --:--:--)
The box failed to unpackage properly. Please verify that the box
file you're trying to add is not corrupted and try again. The
output from attempting to unpackage (if any):

x metadata.json
x Virtual Hard Disks/
bsdtar.EXE: Inconsistent compressed size
x Virtual Hard Disks/ubuntu-14.vhdx
x Virtual Machines/
x Virtual Machines/50BA5128-D926-4617-92AC-737C14256032.XML
bsdtar.EXE: Error exit delayed from previous errors.
PS C:\Users\jeffrey\PycharmProjects\networking>

[svpernova09]

Any update on this issue? I've tried using different versions of bsdtar.exe and no luck.

[pauby]

Just to confirm this issue has nothing to do with Hyper-V - problem occurs unpacking a VMware Workstation box that has just been created by me.

My environment is Windows 10 x64 using vagrant 1.9.1 and packaged the box using 7Zip.

[svpernova09]

I have tried just about everything I can think of with no success. I exported a Hyper-V VM. Then tried using Winrar, 7zip, and even Powershell to create the box file from the exported files. I've also tried copyingthe files to a Linux system, used tar to create the box file, copied to the box back to the Windows system and still have the error (or some variation of bsdtar.exe error)

[chrisroberts]

I believe the new windows builds will resolve this issue.

[briancain]

Hi there,

It looks like this has been resolved within a previously shipped version of Vagrant so I am now closing this issue. If the original issue was not fully resolved, please reopen this issue or create a new one.

Cheers!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.