<p>empacotador produz 0 byte vmdk</p>

Posso reproduzir o problema no macOS 10.13.3 e APFS, Packer 1.2.1, VirtualBox 5.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

Tentei novamente com um Packer versão 1.1.3 mais antigo, ainda macOS 10.13.3 e APFS, VirtualBox 5.2.8 e o arquivo de caixa parece bom depois:

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

Qual pode ser a diferença entre o Packer 1.1.3 e o Packer 1.2.1?

A função DirToBox é significativamente diferente em 1.2.1?

Desculpe, não é muito bom com git, então não sei como obter esse código como você

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

A culpa do git não mostra mudanças desde o packer 1.1.1 em packer / post-processor / vagrant / util.go.
Packer 1.1.3 é compilado com Go 1.9, Packer 1.2.1 é compilado com Go 1.10.

Realmente parece um problema com Golang 1.10.

Extraí o arquivo packer / post-processor / vagrant / util.go em um pequeno main.go chamando a função DirToBox sem o packer.Ui.

Compilar esse código com Golang 1.9, o arquivo tar criado parece bom.
Compilando esse código com Golang 1.10, o arquivo tar mostra um arquivo de zero byte.

O problema também ocorre com o nível de compactação = 0, portanto, é independente do pacote pgzip.

A fonte de amostra dirtobox.go , o script Dockerfile e build.sh para construir o binário Darwin podem ser encontrados neste gist: https://gist.github.com/StefanScherer/c55fd0ae752687c806f8d5fb40cadc78

Eu criei um diretório de amostra in com um arquivo grande, compilei o binário dirtobox para Darwin e executei o teste

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

Alterando o Dockerfile volta para golang: 1,9

FROM golang:1.9

WORKDIR /go/src/app
COPY . .

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

e executar ./build.sh e ./dirtobox novamente produz um arquivo tar correto:

$ 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

Parece acontecer com arquivos> 8 GByte.

Está na hora de abrir um assunto no

Excelente triagem @StefanScherer

Eu tive um problema muito semelhante com o Vagrant hoje - veja AQUI .

De forma resumida, o utilitário tar incorporado ao Vagrant 2.0.3 está tendo problemas para descompactar arquivos com arquivos grandes - ao usar o bsdtar para extrair os arquivos do arquivo tar da caixa, acabo com um vmdk muito estreito de zero bytes! Caixas menores não causam problemas.

Observe que o tar do sistema não tem problemas para extrair os arquivos do mesmo arquivo box / 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 - Tem certeza de que não é a versão tar que está usando que está causando os problemas?

@StefanScherer Apenas para referência:

$ 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 Desculpe - acabei de AQUI .

Esse é o mesmo problema relatado AQUI - não é um problema do Packer!

Obrigado @DanHam pelo
Pode haver um problema com o bsdtar no macOS.
O problema no Packer parece ser com Golang 1.10. Obviamente, ele cria arquivos tar diferentes entre Golang 1.9 e 1.10.

Usei outro binário Go de https://github.com/mholt/archiver/releases para extrair os arquivos tar criados com o código de amostra dirtobox acima compilado com Golang 1.9 e 1.10.

O arquivador pode extrair o arquivo do arquivo tar criado com o binário dirtobox Golang 1.9.
E o arquivador apenas escreveu um arquivo vazio extraindo o arquivo tar criado com o binário dirtobox Golang 1.10.

Nenhum binário tar / bsdtar foi incluído nesse teste.

Um teste com o bsdtar embutido do meu Vagrant 2.0.2 também pode extrair arquivos grandes

$ /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. Pensei que já tivéssemos explicado aquele! Boa sorte rastreando o bug ...

Tenho tido esse problema recentemente, mas não consigo fazer nenhum progresso com a reversão para o Packer 1.1.3. Suponho que você não tenha outras idéias.

(O problema está documentado em https://github.com/Parallels/vagrant-parallels/issues/319, pois pensei que fosse um problema de plug-in!)

Então, investigando um pouco mais;
Eu reverti para o Packer 1.1.2 no OSX 10.12, e que conseguiu produzir uma caixa estável que eu poderia usar.
Testando com Packer 1.1.2 no OSX 10.13 e isso falha por algum motivo? O disco rígido diz que é 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

Então, definitivamente parece que é um problema do empacotador em algum lugar ... como você fará para depurar isso, já que eu realmente preciso fazer o vagrant funcionar nessas máquinas!

PARA SUA INFORMAÇÃO. Há um novo packer e golang da homebrew hoje para Sierra. E um novo empacotador para High Sierra.

@basictheprogram Obrigado pela atualização!

Eu atualizei ambos para o Packer mais recente disponível no Homebrew (1.2.2)

• Sierra funciona bem
• High Sierra ainda não consegue conectar o disco rígido

Não tenho certeza do que mais poderia estar causando esse problema além da diferença do sistema operacional?

O que é estranho é que rodar $ tar .box mostra que para ambos os sistemas operacionais acho que o disco rígido tem um tamanho de 0 ... mas fazer vagrant up funciona bem para o Sierra. (Ambos estão executando o Vagrant 2.0.3).

Serra:

$ 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

High 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

Em Sierra upgrade packer instalado vá.

$ sw_vers
Nome do produto: Mac OS X
Versão do produto: 10.12.6
BuildVersion: 16G1212

versão $ go
go versão go1.10 darwin / amd64

Em High Sierra, o packer de atualização não foi instalado, go

$ sw_vers
Nome do produto: Mac OS X
Versão do produto: 10.13.3
BuildVersion: 17D102

$ que vai

$ ls -l / usr / local / bin / go *
ls: / usr / local / bin / go *: Não existe esse arquivo ou diretório

Instalei manualmente o go e as coisas estão funcionando para mim agora.

Preciso confirmar tudo isso em outras instalações.

O binário do Packer 1.2.2 para macOS (https://releases.hashicorp.com/packer/1.2.2/packer_1.2.2_darwin_amd64.zip) é compilado com Golang 1.8.1. Presumo que deve funcionar novamente.

Homebrew Packer 1.2.2 é compilado com Golang 1.10
Cara, por que eles têm que compilar binários quando binários já estão implantados pela HashiCorp?

Incrível investigação, pessoal. Parece-me que se trata de um bug no Homebrew em vez de um bug no Packer - vocês concordam? Devo fechar este tíquete?

Acho que o bug está em Golang e o empacotador é compilado com um Golang com buggy. Hashicorp deve compilar seu packer com Golang 1.10.

Parece que o binário cheio de erros é do Homebrew e o binário da HashiCorp funciona?

Alguém deve testar o binário HashiCorp 1.2.2. Pode testar amanhã.

Vou recompilar e relançar o HashiCorp 1.2.2. binário no golang 1.10 agora. Devíamos ter isso no último golang.

Hm, mas provavelmente será quebrado como 1.2.1.

Este é o binário compilado golang-1.8, para aquelas pessoas que precisam de uma solução alternativa:
packer_1.2.2_darwin_amd64.zip . Liberá-lo compilado com o 1.8 foi um acidente, e só porque corrige esse bug não significa que não introduza outros.

@basictheprogram Meus sistemas já tinham go instalado quando fiz a verificação:

$ 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

Acabei de testar o binário compilado 1.8 do Packer 1.2.2 @SwampDragons postado acima:
Sierra: vagrant box falhou (para encontrar o disco rígido)
High Sierra: a caixa vagrant falhou novamente (mesmo problema)

Testando o Packer 1.2.2 padrão compilado com 1.10:
Sierra: vagrant box falhou (para encontrar o disco rígido)
High Sierra: a caixa vagrant falhou novamente (mesmo problema)

O arquivo .pvm tem 16 GB, ele tenta compactar, e a caixa de saída tem 9 GB ...
Estou começando a achar que isso tem algo a ver com meu sistema agora.

Alguém pode confirmar se 1.2.2 está funcionando e, em caso afirmativo, qual configuração?

(Nota estranha; eu disse anteriormente que tinha funcionado no Sierra com o Brew's Packer, agora não está funcionando ...)

@SwampDragons conforme esperado:

• O Packer 1.2.2 compilado com Golang 1.8 cria arquivos box que funcionam bem com macOS tar (bsdtar 2.8.3 - libarchive 2.8.3).
• O Packer 1.2.2 compilado com Golang 1.10 cria arquivos box que o macOS tar não pode extrair (arquivos de 0 byte)
• Ambos os arquivos de caixa gerados funcionam bem com GNU tar (eu apenas tentei uma versão Linux em um contêiner com docker run -it -v $(pwd):/test -w /test ubuntu tar tvf windows_2016_docker_virtualbox-brew-packer-1.2.2-golang-1.10.box .

@SwampDragons Estou usando o go 1.10 (instalado via MacPorts) para compilar meus binários do Packer. Como afirmado acima, posso criar caixas grandes sem problemas ...

@SurferL Minha configuração:

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

Descompactar a caixa (usando GNU tar) da minha compilação do Windows 2016 me dá:

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

É por isso que eu estava tão convencido (no início) de que estávamos vendo esse problema, e não um problema com o Packer. No entanto, o trabalho que @StefanScherer fez parece sugerir que o problema está em outro lugar ...

EDIT: Acabei de ver o comentário de @StefanScherer acima ... então este pode ser o mesmo problema, embora com algumas informações adicionais fornecidas por Stefan?

Isso pode ter sido corrigido em https://golang.org/doc/devel/release.html#go1.10.minor

Posso ver uma correção para archive / zip em 1.10.1. Tentei com um código de amostra simplificado, mas ainda há o problema. Também ocorre com um binário Linux Golang. O macOS tar (bsdtar) não pode ler o tamanho do arquivo corretamente.

Criei https://github.com/golang/go/issues/24599

Aqui está o packer construído com go 1.10.1 para darwin. Agradeceria qualquer ajuda no teste se isso resolver o problema.

packer-1.2.2-go-1.10.1.zip

Obrigado @StefanScherer por preencher o bug do upstream. Há uma tonelada de informações úteis nele

O que você pode fazer?
Go1.10 oferece ao usuário um controle mais preciso sobre o formato de saída. Você pode ver tar.Header.Format em tar.FormatGNU para contornar o bug do libarchive.

Parece que deveria ser isso. Se alguém quiser enviar um PR, faça o favor, caso contrário, adicionaremos a solução alternativa para o próximo lançamento pontual. Compilar o empacotador com uma versão mais antiga do go deve ser uma solução alternativa viável por enquanto.

Faremos depois de alguns testes.

Infelizmente, ainda estou recebendo o mesmo erro com o Packer desenvolvido com go 1.10.1 para Darwin que @mwhooker forneceu ... o .box gerado no final contém um disco rígido vazio supostamente para o tamanho da caixa de 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

(e a execução de vagrant up falha com o erro do disco rígido)

Ainda estou recebendo o erro ( vagrant up disco rígido) usando Packer 1.1.3 , então não tenho certeza se é algo com meu sistema.
Mesmo que o disco rígido pareça ter sido inicializado aqui?

$ 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

Você já experimentou o packer from brew?

@basictheprogram Sim, eu tentei o 1.2.2 mais recente, bem como voltei para 1.1.3 com o Brew, mas os dois não funcionaram com os mesmos problemas acima

@SurferL Você está usando vagrant box add... ? Tenho certeza de que a versão embarcada do tar do Vagrants causará esses problemas, independentemente da correção que foi feita para o Packer. Veja meu comentário aqui .

De forma resumida, você pode precisar descompactar manualmente a caixa no local correto no diretório .vagrant.d ... usando GNU tar em vez de bsdtar até que a próxima versão do Vagrant seja lançada.

@DanHam Obrigado por apontar isso - eu não estava usando vagrant box add , e isso fez minha construção funcionar com Packer 1.1.3 !

Só mais algumas informações:
Usar Packer 1.2.2 da brew (e usar vagrant box add não funcionou), nem usar o Packer construído com go 1.10.1 para Darwin (e usar vagrant box add ) ...

Vou bloquear este problema porque ele está fechado há _30 dias_ ⏳. Isso ajuda nossos mantenedores a encontrar e focar nos problemas ativos.

Se você encontrou um problema semelhante a este, abra um novo problema e preencha o modelo de problema para que possamos capturar todos os detalhes necessários para uma investigação mais aprofundada.