<p>パッカーは0バイトのvmdkを生成します</p>

ああ、macOS 10.13.3とAPFS、Packer 1.2.1、VirtualBox5.2.8で問題を再現できます

$ 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

古いPackerバージョン1.1.3、まだmacOS 10.13.3とAPFS、VirtualBox 5.2.8で再試行しましたが、その後ボックスファイルは正常に表示されます。

$ 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*

Packer1.1.3とPacker1.2.1の違いは何ですか？

func DirToBoxは1.2.1では大幅に異なりますか？

申し訳ありませんが、gitはあまり得意ではないので、あなたが行ったようにそのコードをプルアップする方法がわかりません

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

gitのせいは、packer / post-processor / vagrant /util.goのpacker1.1.1以降の変更を示していません。
Packer1.1.3はGo1.9でコンパイルされ、Packer1.2.1はGo1.10でコンパイルされます。

それは本当にGolang1.10の問題のように見えます。

packer / post-processor / vagrant / util.goファイルを小さなmain.goに抽出し、packer.UiなしでDirToBox関数を呼び出しました。

そのコードをGolang1.9でコンパイルすると、作成されたtarファイルは見栄えがします。
そのコードをGolang1.10でコンパイルすると、tarファイルにゼロバイトのファイルが表示されます。

この問題は、圧縮レベル= 0でも発生するため、pgzipパッケージから独立しています。

ダーウィンバイナリをビルドするためのサンプルソースdirtobox.go 、 Dockerfile 、およびbuild.shスクリプトは、次の要点にあります： https ：

大きなファイルを使用してサンプルのinディレクトリを作成し、Darwin用にdirtoboxバイナリをコンパイルして、テストを実行しました。

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

Dockerfileをgolang：1.9に戻す

FROM golang:1.9

WORKDIR /go/src/app
COPY . .

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

./build.shと./dirtobox再度実行すると、正しいtarファイルが生成されます。

$ 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

8GByteを超えるファイルで発生するようです。

golangで問題を開く時間ですか？

優れたトリアージ@StefanScherer

今日、Vagrantで非常によく似た問題が発生しました。こちらをご覧ください。

Vagrant 2.0.3に組み込まれているtarユーティリティの長短は、大きなファイルを含むアーカイブの解凍で問題が発生します-bsdtarを使用してボックスtarアーカイブからファイルを抽出すると、非常にスリムなvmdkがゼロバイトになります！ 小さい箱は問題を引き起こしません。

システムtarは、同じボックス/ tarアーカイブからファイルを抽出する際に問題がないことに注意してください...

$ /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-問題の原因となっているのは、使用しているtarバージョンではないことを確認しますか？

@StefanScherer参考までに：

$ 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申し訳ありません-元の問題をここで確認しました。

これは、ここで報告されているのと同じ問題です。パッカーの問題ではありません。

ヘッズアップをしてくれた
macOSのbsdtarに問題がある可能性があります。
Packerの問題はGolang1.10にあるようです。 それは明らかにGolang1.9と1.10の間で異なるtarファイルを作成します。

https://github.com/mholt/archiver/releasesから別のGoバイナリを使用して、Golang1.9および1.10でコンパイルされた上記のdirtoboxサンプルコードで作成されたtarファイルを抽出しました。

アーカイバは、dirtobox Golang1.9バイナリで作成されたtarファイルからファイルを抽出できます。
そして、アーカイバは、dirtobox Golang1.10バイナリで作成されたtarファイルを抽出する空のファイルを作成しました。

そのテストにはtar / bsdtarバイナリは含まれていませんでした。

Vagrant 2.0.2の埋め込みbsdtarを使用したテストでも、大きなファイルを抽出できます

$ /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ああ...

最近問題が発生しましたが、Packer1.1.3に戻すことで前進することができません。 他にアイデアはないと思いますか？

（プラグインの問題だと思ったので、問題はhttps://github.com/Parallels/vagrant-parallels/issues/319に記載されています！）

それで、もう少し調査します。
OSX10.12でPacker1.1.2に戻したところ、使用できる安定したBoxを作成できました。
OSX10.13でPacker1.1.2を使用してテストしましたが、何らかの理由で失敗しましたか？ ハードドライブはそれが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

だから間違いなくどこかでパッカーの問題のように見えます...私は本当にこれらのマシンでvagrantを動作させる必要があるので、これをデバッグするにはどうすればよいですか？

ご参考までに。 シエラのために今日自作から新しいパッカーとgolangがあります。 そして、ハイシエラの新しいパッカー。

@basictheprogram更新してくれてありがとう！

両方をHomebrewで利用可能な最新のPacker（1.2.2）に更新しました

• シエラは正常に動作します
• HighSierraはまだハードドライブを接続できません

OSの違い以外に、この問題の原因が他に何であるかわかりませんか？

奇妙なことに、 $ tar .boxを実行すると、両方のOSでハードディスクのサイズが0と考えられますが、Sierra vagrant upても問題なく動作します。 （どちらもVagrant 2.0.3を実行しています）。

シエラ：

$ 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

ハイシエラ：

$ 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

インストールされているシエラアップグレードパッカーに行きます。

$ sw_vers
製品名：Mac OS X
ProductVersion：10.12.6
BuildVersion：16G1212

$ goバージョン
goバージョンgo1.10darwin / amd64

High Sierraでは、アップグレードパッカーがインストールされませんでした

$ sw_vers
製品名：Mac OS X
ProductVersion：10.13.3
BuildVersion：17D102

行く$

$ ls -l / usr / local / bin / go *
ls：/ usr / local / bin / go *：そのようなファイルまたはディレクトリはありません

goを手動でインストールしましたが、現在は機能しています。

他のインストールでこれらすべてを確認する必要があります。

macOS用のPacker1.2.2バイナリ（https://releases.hashicorp.com/packer/1.2.2/packer_1.2.2_darwin_amd64.zip）は、Golang1.8.1でコンパイルされています。 私はそれが再び働くはずだと思います。

Homebrew Packer1.2.2はGolang1.10でコンパイルされています
バイナリがHashiCorpによってすでにデプロイされているのに、なぜバイナリをコンパイルする必要があるのですか？

素晴らしい調査、皆さん。 これはPackerのバグではなく、Homebrewのバグのように思えますが、皆さんも同意しますか？ このチケットを閉じる必要がありますか？

バグはGolangにあり、パッカーはバグのあるGolangでコンパイルされていると思います。 Hashicorpは、Golang1.10を使用してパッカーをコンパイルする必要があります。

バギーバイナリはHomebrewのものであり、HashiCorpバイナリは機能しているように聞こえますか？

誰かがHashiCorp1.2.2バイナリをテストする必要があります。 明日テストできます。

HashiCorp1.2.2を再コンパイルして再リリースします。 golang1.10のバイナリになりました。 最新のgolangでそれを持っている必要があります。

うーん、でもそれならおそらく1.2.1として壊れてしまうでしょう。

回避策が必要な人のために、golang-1.8でコンパイルされたバイナリを次に示します。
packer_1.2.2_darwin_amd64.zip 。 1.8でコンパイルされたものをリリースするのは偶然であり、このバグを修正したからといって、他の人を紹介しないというわけではありません。

@basictheprogramチェックを行ったとき、私のシステムにはすでにgoインストールされていました。

$ 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

上記のPacker1.2.2@SwampDragonsの1.8コンパイル済みバイナリをテストしました。
シエラ：vagrantボックスが失敗する（ハードドライブを見つけるため）
High Sierra：vagrant boxが再び失敗しました（同じ問題）

1.10でコンパイルされたデフォルトのPacker1.2.2のテスト：
シエラ：vagrantボックスが失敗する（ハードドライブを見つけるため）
High Sierra：vagrant boxが再び失敗しました（同じ問題）

.pvmファイルは圧縮しようとする16GBで、出力ボックスは9GBです...
私はそれが私のシステムと関係があると今考え始めています。

誰かが1.2.2が機能していることを確認できますか？もしそうなら、どのような設定ですか？

（奇妙なことに、Brew's Packerを使用してSierraで動作させたと以前に言いましたが、現在は動作していません...）

期待どおり@SwampDragons ：

• Golang1.8でコンパイルされたPacker1.2.2は、macOS tar（bsdtar 2.8.3-libarchive 2.8.3）で正常に動作するボックスファイルを作成します。
• Golang1.10でコンパイルされたPacker1.2.2は、macOS tarが抽出できないボックスファイルを作成します（0バイトファイル）
• 生成された両方のボックスファイルはGNUtarで正常に動作します（ docker run -it -v $(pwd):/test -w /test ubuntu tar tvf windows_2016_docker_virtualbox-brew-packer-1.2.2-golang-1.10.boxコンテナーでLinuxバージョンのみを試しました。

@SwampDragons私は

@SurferL私の設定：

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

Windows 2016ビルドから（GNU tarを使用して）ボックスを解凍すると、次のようになります。

.
└── [        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

これが、Packerの問題ではなく、@ StefanSchererが行った作業は、問題が他の場所にあることを示唆しているようです...

編集：上記の@StefanSchererのコメントを見た

これはhttps://golang.org/doc/devel/release.html#go1.10.minorで修正されている可能性があり

1.10.1でarchive / zipの修正を見ることができます。 簡略化したサンプルコードで試しましたが、まだ問題があります。 LinuxGolangバイナリでも発生します。 macOS tar（bsdtar）はファイルサイズを正しく読み取ることができません。

https://github.com/golang/go/issues/24599を作成しました

これは、ダーウィン用にgo1.10.1で構築されたパッカーです。 これで問題が解決するかどうかをテストする際に助けていただければ幸いです。

packer-1.2.2-go-1.10.1.zip

アップストリームのバグを報告してくれた@StefanSchererに感謝します。 そこにはたくさんの有用な情報があります

あなたは何ができますか？
Go1.10を使用すると、ユーザーは出力形式をより細かく制御できます。 libarchiveのバグを回避するために、tar.Header.Formatからtar.FormatGNUを確認できます。

それはそうあるべきだと思われます。 誰かがPRを提出したい場合は、提出してください。提出しない場合は、次のポイントリリースの回避策を追加します。 古いバージョンのgoでpackerをコンパイルすることは、今のところ実行可能な回避策になるはずです。

いくつかのテストの後に行います。

@mwhookerが提供したDarwin用のgo1.10.1でビルドされたPackerでも同じエラーが発生するのではないかと.boxは、おそらくボックスサイズが12GBの空のハードディスクが含まれています

$ 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

（そしてvagrant up実行

Packer 1.1.3を使用しても（ vagrant upハードディスク）エラーが発生するので、システムに問題があるかどうかわかりませんか？
ハードディスクはここで初期化されているようですが？

$ 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

brewからpackerを試しましたか？

@basictheprogramええ、私は最新の1.2.2を試し、Brewで1.1.3に戻りましたが、どちらも上記の同じ問題では機能しませんでした

@SurferL vagrant box add...ますか？ tarのVagrants埋め込みバージョンは、Packerに加えられた修正に関係なく、これらの問題を引き起こすと確信しています。 ここで私のコメントを参照して

長くも短くも、Vagrantの次のバージョンがリリースされるまで、bsdtarではなくGNU tarを使用して、.vagrant.d ...ディレクトリ内の適切な場所にボックスを手動で解凍する必要がある場合があります。

@DanHam指摘してくれてありがとう-私はvagrant box addを使用していなかったので、ビルドはPacker 1.1.3 ！

さらにいくつかの情報：
brewからPacker 1.2.2を使用する（そしてvagrant box addを使用することは機能しませんでした）、またダーウィン用にgo 1.10.1で構築されたPackerを使用する（そしてvagrant box add ）...

_ 30日間_⏳クローズされたため、この問題をロックします。 これは、メンテナがアクティブな問題を見つけて集中するのに役立ちます。

これに類似していると思われる問題を見つけた場合は、新しい問題を開いて問題テンプレートに記入してください。これにより、さらに調査するために必要なすべての詳細を取得できます。