<p>Der Packer erzeugt 0 Byte vmdk</p>

Oh, ich kann das Problem unter macOS 10.13.3 und APFS, Packer 1.2.1, VirtualBox 5.2.8 wiederholen

$ packer build --only=virtualbox-iso windows_2016_docker.json
$ ls -l windows_2016_docker_virtualbox.box
-rw-r--r--   1 stefan  staff  10146394489 Mar  8 12:16 windows_2016_docker_virtualbox.box
$ tar tvf windows_2016_docker_virtualbox.box
-rw-r--r--  0 stefan staff    2286 Mar  8 12:16 Vagrantfile
-rw-r--r--  0 stefan staff       0 Mar  8 12:16 WindowsServer2016Docker-disk001.vmdk
-rw-r--r--  0 stefan staff   10411 Mar  8 12:16 box.ovf
-rw-r--r--  0 stefan staff      26 Mar  8 12:16 metadata.json

Ich habe es mit einer älteren Packer-Version 1.1.3, immer noch MacOS 10.13.3 und APFS, VirtualBox 5.2.8, wiederholt und die Box-Datei sieht danach gut aus:

$ ls -l *box
-rw-r--r--  1 stefan  staff  10817278351 Mar 11 14:28 windows_2016_docker_virtualbox.box
$ tar tvf windows_2016_docker_virtualbox.box 
-rw-r--r--  0 501    20        2286 Mar 11 14:27 Vagrantfile
-rw-r--r--  0 501    20 10952051712 Mar 11 14:27 WindowsServer2016Docker-disk001.vmdk
-rw-r--r--  0 501    20       10412 Mar 11 14:27 box.ovf
-rw-r--r--  0 501    20          26 Mar 11 14:27 metadata.json
~/code/packer-windows on my*

Was könnte der Unterschied zwischen Packer 1.1.3 und Packer 1.2.1 sein?

Unterscheidet sich die func DirToBox in 1.2.1 signifikant?

Sorry, nicht sehr gut mit Git, also weiß ich nicht, wie ich diesen Code aufrufen soll, wie du es getan hast

https://github.com/hashicorp/packer/blob/4d3a762e85e7e8050134a4e33e1f87a54029dcb8/post-processor/vagrant/util.go#L71 -L155

Eine Git-Schuld zeigt keine Änderungen seit Packer 1.1.1 in Packer / Postprozessor / Vagrant / Util.go.
Packer 1.1.3 wird mit Go 1.9 kompiliert, Packer 1.2.1 wird mit Go 1.10 kompiliert.

Es sieht wirklich nach einem Problem mit Golang 1.10 aus.

Ich habe die Datei packer / postprozessor / vagrant / util.go in eine kleine Datei main.go extrahiert, die die Funktion DirToBox ohne packer.Ui aufruft.

Wenn Sie diesen Code mit Golang 1.9 kompilieren, sieht die erstellte TAR-Datei gut aus.
Beim Kompilieren dieses Codes mit Golang 1.10 zeigt die TAR-Datei eine Null-Byte-Datei.

Das Problem tritt auch bei der Komprimierungsstufe = 0 auf, sodass es unabhängig vom pgzip-Paket ist.

Die Beispielquelle dirtobox.go , das Skript Dockerfile und build.sh zum Erstellen der Darwin-Binärdatei finden Sie in dieser Übersicht: https://gist.github.com/StefanScherer/c55fd0ae752687c806f8d5fb40cadc78

Ich habe ein Beispielverzeichnis in mit einer großen Datei erstellt, die Binärdatei dirtobox für Darwin kompiliert und den Test ausgeführt

$ ./build.sh 

$ ls -l in
total 21509960
-rw-r--r--  1 stefan  staff  11012556800 Mar 12 15:11 abigfile.tar
-rw-r--r--  1 stefan  staff            6 Mar 12 15:08 asmallfile.txt

$ ./dirtobox 
2018/03/12 15:35:02 Turning dir into box: in => out.tar
2018/03/12 15:35:02 Skipping directory 'in' for box 'out.tar'
2018/03/12 15:35:02 Box add: 'in/abigfile.tar' to 'out.tar'
Compressing: %s abigfile.tar
2018/03/12 15:35:32 Box add: 'in/asmallfile.txt' to 'out.tar'
Compressing: %s asmallfile.txt

$ ls -l out.tar
-rw-r--r--  1 stefan  staff  11012560384 Mar 12 15:27 out.tar

$ tar tvf out.tar
-rw-r--r--  0 stefan staff       0 Mar 12 15:11 abigfile.tar
-rw-r--r--  0 stefan staff       6 Mar 12 15:08 asmallfile.txt

Ändern der Dockerfile zurück in Golang: 1.9

FROM golang:1.9

WORKDIR /go/src/app
COPY . .

RUN go get -d -v ./...
RUN GOOS=darwin go build dirtobox.go

Wenn Sie ./build.sh und ./dirtobox erneut ausführen, wird eine korrekte TAR-Datei erstellt:

$ ls -l out.tar 
-rw-r--r--  1 stefan  staff  11012559360 Mar 12 15:37 out.tar

$ tar tvf out.tar 
-rw-r--r--  0 501    20 11012556800 Mar 12 15:11 abigfile.tar
-rw-r--r--  0 501    20           6 Mar 12 15:08 asmallfile.txt

Es scheint mit Dateien> 8 GByte zu passieren.

Zeit, eine Ausgabe bei Golang zu

Ausgezeichnetes Triaging @StefanScherer

Ich bin heute mit Vagrant auf ein sehr ähnliches Problem gestoßen - siehe HIER .

Kurz und gut, das in Vagrant 2.0.3 eingebettete Dienstprogramm tar hat Probleme beim Entpacken von Archiven mit großen Dateien. Wenn Sie bsdtar zum Extrahieren der Dateien aus dem Box-Tar-Archiv verwenden, erhalten Sie ein sehr schlankes VMDK mit null Byte! Kleinere Boxen verursachen keine Probleme.

Beachten Sie, dass der System- Tar keine Probleme beim Extrahieren der Dateien aus demselben Box- / Tar-Archiv hat ...

$ /opt/vagrant/embedded/bin/bsdtar --version
bsdtar 3.2.2 - libarchive 3.2.2 zlib/1.2.11 liblzma/5.2.3

$ tar --version
tar (GNU tar) 1.29

@StefanScherer - Sind Sie sicher, dass nicht die von Ihnen verwendete Tar-Version die Probleme verursacht?

@StefanScherer Nur als Referenz:

$ sw_vers 
ProductName:    Mac OS X
ProductVersion: 10.11.6
BuildVersion:   15G19009

$ go version
go version go1.10 darwin/amd64

$ packer version
Packer v1.2.2-dev...

@basictheprogram @StefanScherer Entschuldigung - HIER angesehen .

Das ist das gleiche Problem, das HIER gemeldet wurde - kein Packer-Problem!

Danke @DanHam für das Heads-up.
Möglicherweise liegt ein Problem mit bsdtar unter macOS vor.
Das Problem in Packer scheint bei Golang 1.10 zu liegen. Es werden offensichtlich unterschiedliche TAR-Dateien zwischen Golang 1.9 und 1.10 erstellt.

Ich habe eine andere Go-Binärdatei von https://github.com/mholt/archiver/releases verwendet , um die TAR-Dateien zu extrahieren, die mit dem oben mit Golang 1.9 und 1.10 kompilierten Dirtobox-Beispielcode erstellt wurden.

Der Archivierer kann die Datei aus der mit der Dirtobox Golang 1.9-Binärdatei erstellten TAR-Datei extrahieren.
Und der Archivierer hat gerade eine leere Datei geschrieben, die die mit der Dirtobox Golang 1.10-Binärdatei erstellte TAR-Datei extrahiert.

In diesem Test war keine tar / bsdtar-Binärdatei enthalten.

Ein Test mit dem eingebetteten bsdtar meines Vagrant 2.0.2 kann auch große Dateien extrahieren

$ /opt/vagrant/embedded/bin/bsdtar tvf out-go1.9.tar 
-rw-------  0 501    20 10737418240 Mar 23 23:02 10Gigfile
$ /opt/vagrant/embedded/bin/bsdtar xvf out-go1.9.tar 
x 10Gigfile
$ ls -l 10Gigfile 
-rw-------  1 stefan  staff  10737418240 Mar 23 23:02 10Gigfile


$ /opt/vagrant/embedded/bin/bsdtar tvf out-go1.10.tar 
-rw-------  0 stefan staff       0 Mar 23 23:02 10Gigfile
$ /opt/vagrant/embedded/bin/bsdtar xvf out-go1.10.tar 
x 10Gigfile
$ ls -l 10Gigfile 
-rw-------  1 stefan  staff  0 Mar 23 23:02 10Gigfile

@StefanScherer Ah ... OK. Ich dachte, wir hätten das weg erklärt! Viel Glück beim Aufspüren des Fehlers ...

Ich hatte das Problem kürzlich, kann aber mit der Rückkehr zu Packer 1.1.3 keine Fortschritte erzielen. Ich nehme an, Sie haben keine anderen Ideen?

(Das Problem ist unter https://github.com/Parallels/vagrant-parallels/issues/319 dokumentiert, da ich dachte, es sei ein Plugin-Problem!)

Also noch etwas nachforschen;
Ich habe unter OSX 10.12 auf Packer 1.1.2 zurückgegriffen, und das hat es geschafft, eine stabile Box zu produzieren, die ich verwenden konnte.
Testen mit Packer 1.1.2 unter OSX 10.13 und das schlägt aus irgendeinem Grund fehl? Die Festplatte sagt, es ist 0 :

$ tar -tvf sdk-mac.box 
-rw-r--r--  0 user group     180 27 Mar 12:57 Vagrantfile
-rw-r--r--  0 user group      25 27 Mar 12:57 metadata.json
-rw-r--r--  0 user group   65536 27 Mar 12:56 sdk-mac.pvm/NVRAM.dat
-rw-r--r--  0 user group    7224 27 Mar 12:56 sdk-mac.pvm/VmInfo.pvi
-rw-r--r--  0 user group   26381 27 Mar 12:56 sdk-mac.pvm/config.pvs
-rw-r--r--  0 user group    1710 27 Mar 12:56 sdk-mac.pvm/harddisk.hdd/DiskDescriptor.xml
-rw-r--r--  0 user group       0 27 Mar 12:56 sdk-mac.pvm/harddisk.hdd/harddisk.hdd
-rw-r--r--  0 user group       0 27 Mar 12:57 sdk-mac.pvm/harddisk.hdd/harddisk.hdd.0.{5fbaabe3-6958-40ff-92a7-860e329aab41}.hds
-rw-r--r--  0 user group    8816 27 Mar 12:57 sdk-mac.pvm/harddisk.hdd/harddisk.hdd.drh

Sieht also definitiv so aus, als wäre es irgendwo ein Packer-Problem ... wie gehen Sie beim Debuggen vor, da ich wirklich Vagabund für diese Maschinen zum Laufen bringen muss!

Zu Ihrer Information. Für Sierra gibt es heute einen neuen Packer und Golang von Homebrew. Und neuer Packer für High Sierra.

@basictheprogram Danke für das Update!

Ich habe beide auf den neuesten Packer aktualisiert, der auf Homebrew (1.2.2) verfügbar ist.

• Sierra funktioniert gut
• High Sierra kann die Festplatte immer noch nicht verbinden

Ich bin mir nicht sicher, was dieses Problem außer dem Unterschied im Betriebssystem noch verursachen könnte.

Was seltsam ist, ist, dass das Ausführen von $ tar .box zeigt, dass für beide Betriebssysteme die Festplatte eine Größe von 0 ... aber das Ausführen von vagrant up funktioniert gut für die Sierra. (Beide führen Vagrant 2.0.3 aus).

Sierra:

$ tar tvf sdk-mac.box 
-rw-r--r--  0 user group     180 27 Mar 15:25 Vagrantfile
-rw-r--r--  0 user group      25 27 Mar 15:25 metadata.json
-rw-r--r--  0 user group   65536 27 Mar 15:23 sdk-mac.pvm/NVRAM.dat
-rw-r--r--  0 user group    7224 27 Mar 15:23 sdk-mac.pvm/VmInfo.pvi
-rw-r--r--  0 user group   26385 27 Mar 15:23 sdk-mac.pvm/config.pvs
-rw-r--r--  0 user group    1710 27 Mar 15:23 sdk-mac.pvm/harddisk.hdd/DiskDescriptor.xml
-rw-r--r--  0 user group       0 27 Mar 15:23 sdk-mac.pvm/harddisk.hdd/harddisk.hdd
-rw-r--r--  0 user group       0 27 Mar 15:25 sdk-mac.pvm/harddisk.hdd/harddisk.hdd.0.{5fbaabe3-6958-40ff-92a7-860e329aab41}.hds
-rw-r--r--  0 user group    6784 27 Mar 15:25 sdk-mac.pvm/harddisk.hdd/harddisk.hdd.drh

Hohe Sierra:

$ tar tvf sdk-mac.box 
-rw-r--r--  0 user group     180 27 Mar 15:29 Vagrantfile
-rw-r--r--  0 user group      25 27 Mar 15:29 metadata.json
-rw-r--r--  0 user group   65536 27 Mar 15:29 sdk-mac.pvm/NVRAM.dat
-rw-r--r--  0 user group    7224 27 Mar 15:29 sdk-mac.pvm/VmInfo.pvi
-rw-r--r--  0 user group   26381 27 Mar 15:29 sdk-mac.pvm/config.pvs
-rw-r--r--  0 user group    1710 27 Mar 15:29 sdk-mac.pvm/harddisk.hdd/DiskDescriptor.xml
-rw-r--r--  0 user group       0 27 Mar 15:29 sdk-mac.pvm/harddisk.hdd/harddisk.hdd
-rw-r--r--  0 user group       0 27 Mar 15:29 sdk-mac.pvm/harddisk.hdd/harddisk.hdd.0.{5fbaabe3-6958-40ff-92a7-860e329aab41}.hds
-rw-r--r--  0 user group    7728 27 Mar 15:29 sdk-mac.pvm/harddisk.hdd/harddisk.hdd.drh

Auf Sierra Upgrade Packer installiert gehen.

$ sw_vers
Produktname: Mac OS X.
Produktversion: 10.12.6
BuildVersion: 16G1212

$ go Version
go version go1.10 darwin / amd64

Auf High Sierra wurde das Upgrade des Packers nicht installiert

$ sw_vers
Produktname: Mac OS X.
Produktversion: 10.13.3
BuildVersion: 17D102

$ welche gehen

$ ls -l / usr / local / bin / go *
ls: / usr / local / bin / go *: Keine solche Datei oder kein solches Verzeichnis

Ich habe go manuell installiert und die Dinge funktionieren jetzt für mich.

Ich muss dies alles bei anderen Installationen bestätigen.

Packer 1.2.2 Binary für MacOS (https://releases.hashicorp.com/packer/1.2.2/packer_1.2.2_darwin_amd64.zip) wird mit Golang 1.8.1 kompiliert. Ich gehe davon aus, dass es wieder funktionieren sollte.

Homebrew Packer 1.2.2 wurde mit Golang 1.10 kompiliert
Mann, warum müssen sie Binärdateien kompilieren, wenn Binärdateien bereits von HashiCorp bereitgestellt werden?

Tolle Nachforschungen, Leute. Es klingt für mich so, als wäre dies eher ein Fehler in Homebrew als ein Fehler in Packer - würden Sie alle zustimmen? Soll ich dieses Ticket schließen?

Ich denke, der Bug ist in Golang und der Packer ist mit einem Buggy Golang kompiliert. Hashicorp sollte seinen Packer mit Golang 1.10 kompilieren.

Klingt so, als ob die Buggy-Binärdatei von Homebrew stammt und die HashiCorp-Binärdatei funktioniert?

Jemand sollte die HashiCorp 1.2.2-Binärdatei testen. Kann es morgen testen.

Ich werde den HashiCorp 1.2.2 neu kompilieren und erneut veröffentlichen. binär auf Golang 1.10 jetzt. Wir sollten das auf dem neuesten Golang haben.

Hm, aber dann wird es wahrscheinlich als 1.2.1 kaputt sein.

Hier ist die Golang-1.8-kompilierte Binärdatei für diejenigen, die eine Problemumgehung benötigen:
packer_1.2.2_darwin_amd64.zip . Die Veröffentlichung mit 1.8 kompiliert war ein Unfall, und nur weil es diesen Fehler behebt, heißt das nicht, dass es keine anderen einführt.

@basictheprogram Auf meinen Systemen war bereits go installiert, als ich die Prüfung durchführte:

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.12.6
BuildVersion:   16G1212
$ go version
go version go1.10 darwin/amd64

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.13.3
BuildVersion:   17D102
$ go version
go version go1.10 darwin/amd64

Ich habe gerade die 1.8-kompilierte Binärdatei von Packer 1.2.2 @SwampDragons getestet, die oben veröffentlicht wurde:
Sierra: Vagrant Box schlägt fehl (Festplatte zu finden)
High Sierra: Die Vagabundkiste ist erneut ausgefallen (gleiches Problem)

Testen des mit 1.10 kompilierten Standardpackers 1.2.2:
Sierra: Vagrant Box schlägt fehl (Festplatte zu finden)
High Sierra: Die Vagabundkiste ist erneut ausgefallen (gleiches Problem)

Die .pvm -Datei hat 16 GB, die komprimiert werden sollen, und die Ausgabebox hat 9 GB ...
Ich fange an zu denken, dass es jetzt etwas mit meinem System zu tun hat.

Kann jemand bestätigen, dass 1.2.2 funktioniert, und wenn ja, welches Setup?

(Seltsame Notiz; ich sagte früher, dass ich es mit Brew's Packer an Sierra arbeiten ließ, es funktioniert jetzt nicht ...)

@ SwampDragons wie erwartet:

• Mit Golang 1.8 kompilierter Packer 1.2.2 erstellt Box-Dateien, die mit dem macOS tar (bsdtar 2.8.3 - libarchive 2.8.3) einwandfrei funktionieren.
• Mit Golang 1.10 kompilierter Packer 1.2.2 erstellt Box-Dateien, die macOS tar nicht extrahieren kann (0-Byte-Dateien).
• Beide generierten Box-Dateien funktionieren gut mit GNU tar (ich habe nur eine Linux-Version in einem Container mit docker run -it -v $(pwd):/test -w /test ubuntu tar tvf windows_2016_docker_virtualbox-brew-packer-1.2.2-golang-1.10.box ausprobiert.

@ SwampDragons Ich habe go 1.10 (über MacPorts installiert) verwendet, um meine Packer-Binärdateien zu kompilieren. Wie oben erwähnt, kann ich ohne Probleme große Kisten erstellen ...

@ SurferL Mein Setup:

$ sw_vers 
ProductName:    Mac OS X
ProductVersion: 10.11.6
BuildVersion:   15G19009

$ go version
go version go1.10 darwin/amd64

$ packer version
Packer v1.2.2-dev...

Wenn ich die Box (mit GNU tar) aus meinem Windows 2016-Build entpacke, habe ich folgende Möglichkeiten:

.
└── [        340]  vmware_desktop
    ├── [        983]  Vagrantfile
    ├── [         30]  metadata.json
    ├── [       8684]  windows2016-vmware-iso.nvram
    ├── [13725794304]  windows2016-vmware-iso.vmdk
    ├── [          0]  windows2016-vmware-iso.vmsd
    ├── [       3515]  windows2016-vmware-iso.vmx
    └── [        277]  windows2016-vmware-iso.vmxf

1 directory, 7 files

Aus diesem Grund war ich (zunächst) so überzeugt, dass wir dieses Problem eher als ein Problem mit Packer sahen. Die Arbeit von @StefanScherer scheint jedoch darauf

EDIT: Habe gerade den Kommentar von

Dies wurde möglicherweise in https://golang.org/doc/devel/release.html#go1.10.minor behoben

Ich kann einen Fix für Archiv / Zip in 1.10.1 sehen. Ich habe es mit einem abgespeckten Beispielcode versucht, aber es gibt immer noch das Problem. Es tritt auch bei einer Linux-Golang-Binärdatei auf. Der macOS tar (bsdtar) kann die Dateigröße nicht richtig lesen.

Ich habe https://github.com/golang/go/issues/24599 erstellt

Hier ist ein Packer, der mit go 1.10.1 für Darwin gebaut wurde. Würde mich über jede Hilfe beim Testen freuen, wenn dies das Problem löst.

packer-1.2.2-go-1.10.1.zip

Vielen Dank an @StefanScherer für das Einreichen des Upstream-Fehlers. Es gibt eine Menge nützlicher Informationen

Was kannst du tun?
Mit Go1.10 kann der Benutzer das Ausgabeformat genauer steuern. Sie können tar.Header.Format bis tar.FormatGNU sehen, um den libarchiven Fehler zu umgehen.

Das scheint so zu sein. Wenn jemand eine PR einreichen möchte, tun Sie dies bitte, andernfalls fügen wir die Problemumgehung für die nächste Punktveröffentlichung hinzu. Das Kompilieren von Packern mit einer älteren Version von go sollte vorerst eine praktikable Problemumgehung sein.

Wird nach einigen Tests tun.

Ich fürchte, ich bekomme immer noch den gleichen Fehler mit Packer, der mit go 1.10.1 für Darwin erstellt wurde und den @mwhooker bereitgestellt hat ... das am Ende generierte .box enthält eine leere Festplatte, angeblich für eine Boxgröße von 12 GB

$ tar -tvf sdk-mac.box 
-rw-r--r--  0 user group     180  3 Apr 11:26 Vagrantfile
-rw-r--r--  0 user group      25  3 Apr 11:26 metadata.json
-rw-r--r--  0 user group   65536  3 Apr 11:25 sdk-mac.pvm/NVRAM.dat
-rw-r--r--  0 user group    7224  3 Apr 11:25 sdk-mac.pvm/VmInfo.pvi
-rw-r--r--  0 user group   26381  3 Apr 11:25 sdk-mac.pvm/config.pvs
-rw-r--r--  0 user group    1710  3 Apr 11:25 sdk-mac.pvm/harddisk.hdd/DiskDescriptor.xml
-rw-r--r--  0 user group       0  3 Apr 11:25 sdk-mac.pvm/harddisk.hdd/harddisk.hdd
-rw-r--r--  0 user group       0  3 Apr 11:26 sdk-mac.pvm/harddisk.hdd/harddisk.hdd.0.{5fbaabe3-6958-40ff-92a7-860e329aab41}.hds
-rw-r--r--  0 user group    8336  3 Apr 11:26 sdk-mac.pvm/harddisk.hdd/harddisk.hdd.drh

(und das Ausführen von vagrant up schlägt mit dem Festplattenfehler fehl)

Ich erhalte auch immer noch den Fehler ( vagrant up Festplatte) mit Packer 1.1.3 , also bin ich mir nicht sicher, ob es etwas mit meinem System ist?
Auch wenn die Festplatte hier initialisiert zu sein scheint?

$ tar -tvf sdk-mac.box 
-rw-r--r--  0 501    20        180  3 Apr 12:24 Vagrantfile
-rw-r--r--  0 501    20         25  3 Apr 12:24 metadata.json
-rw-r--r--  0 501    20      65536  3 Apr 12:23 sdk-mac.pvm/NVRAM.dat
-rw-r--r--  0 501    20       7224  3 Apr 12:23 sdk-mac.pvm/VmInfo.pvi
-rw-r--r--  0 501    20      26381  3 Apr 12:23 sdk-mac.pvm/config.pvs
-rw-r--r--  0 501    20       1710  3 Apr 12:23 sdk-mac.pvm/harddisk.hdd/DiskDescriptor.xml
-rw-r--r--  0 501    20          0  3 Apr 12:23 sdk-mac.pvm/harddisk.hdd/harddisk.hdd
-rw-r--r--  0 501    20 19503513600  3 Apr 12:24 sdk-mac.pvm/harddisk.hdd/harddisk.hdd.0.{5fbaabe3-6958-40ff-92a7-860e329aab41}.hds
-rw-r--r--  0 501    20        7472  3 Apr 12:24 sdk-mac.pvm/harddisk.hdd/harddisk.hdd.drh

Haben Sie Packer von Brew versucht?

@basictheprogram Ja, ich habe die neueste ausprobiert und bin mit Brew auf 1.1.3 zurückgegangen, aber beide haben nicht mit den oben genannten Problemen gearbeitet

@SurferL Verwenden Sie vagrant box add... ? Ich bin mir ziemlich sicher, dass die in Vagrants eingebettete Version von tar diese Probleme verursachen wird, unabhängig von dem Fix, der in Packer eingegangen ist. Siehe meinen Kommentar hier .

Lang und kurz müssen Sie die Box möglicherweise manuell an der richtigen Stelle im Verzeichnis .vagrant.d ... entpacken, indem Sie GNU tar anstelle von bsdtar verwenden, bis die nächste Version von Vagrant veröffentlicht wird.

@DanHam Danke, dass hast - ich habe nicht vagrant box add , und dadurch funktionierte mein Build mit Packer 1.1.3 !

Nur noch ein paar Infos:
Die Verwendung von Packer 1.2.2 aus dem Brauen (und die Verwendung von vagrant box add hat nicht funktioniert) und die Verwendung von Packer mit go 1.10.1 für Darwin (und die Verwendung von vagrant box add ) ...

Ich werde dieses Problem sperren, da es seit 30 Tagen geschlossen ist. Dies hilft unseren Betreuern, die aktiven Themen zu finden und sich darauf zu konzentrieren.

Wenn Sie ein ähnliches Problem gefunden haben, öffnen Sie bitte ein neues Problem und vervollständigen Sie die Problemvorlage, damit wir alle Details erfassen können, die zur weiteren Untersuchung erforderlich sind.