<p>el empaquetador produce vmdk de 0 bytes</p>

Oh, puedo reproducir el problema en macOS 10.13.3 y 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

He vuelto a intentar con una versión anterior de Packer 1.1.3, todavía macOS 10.13.3 y APFS, VirtualBox 5.2.8 y el archivo de la caja se ve bien después:

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

¿Cuál podría ser la diferencia entre Packer 1.1.3 y Packer 1.2.1?

¿Func DirToBox es significativamente diferente en 1.2.1?

Lo siento, no es muy bueno con git, así que no sé cómo extraer ese código como lo hiciste con

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

Una culpa de git no muestra cambios desde packer 1.1.1 en packer / post-processor / vagrant / util.go.
Packer 1.1.3 se compila con Go 1.9, Packer 1.2.1 se compila con Go 1.10.

Realmente parece un problema con Golang 1.10.

Extraje el archivo packer / post-processor / vagrant / util.go en un pequeño main.go llamando a la función DirToBox sin packer.Ui.

Al compilar ese código con Golang 1.9, el archivo tar creado se ve bien.
Al compilar ese código con Golang 1.10, el archivo tar muestra un archivo de cero bytes.

El problema también ocurre con el nivel de compresión = 0, por lo que es independiente del paquete pgzip.

La fuente de muestra dirtobox.go , el script Dockerfile y build.sh para construir el binario de Darwin se pueden encontrar en esta esencia: https://gist.github.com/StefanScherer/c55fd0ae752687c806f8d5fb40cadc78

He creado un directorio in muestra con un archivo grande, compilé el binario dirtobox para Darwin y ejecuté la prueba

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

Cambiando Dockerfile nuevo a golang: 1.9

FROM golang:1.9

WORKDIR /go/src/app
COPY . .

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

y ejecutar ./build.sh y ./dirtobox nuevamente produce un archivo tar correcto:

$ 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 suceder con archivos> 8GByte.

¿Es hora de abrir un problema en golang ?

Excelente clasificación @StefanScherer

Hoy me encontré con un problema muy similar con Vagrant - vea AQUÍ .

Larga y corta, la utilidad tar incorporada con Vagrant 2.0.3 tiene problemas para desempaquetar archivos con archivos grandes; cuando utilizo bsdtar para extraer los archivos del archivo tar de caja, termino con un vmdk muy delgado de cero bytes. Las cajas más pequeñas no causan ningún problema.

Tenga en cuenta que el sistema tar no tiene problemas para extraer los archivos del mismo cuadro / archivo 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 : ¿estás seguro de que no es la versión tar que estás usando la que está causando los problemas?

@StefanScherer Solo como referencia:

$ 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 Lo siento, solo miré el número original AQUÍ .

Ese es el mismo problema que se informó AQUÍ , ¡no un problema de Packer!

Gracias @DanHam por el
Puede haber un problema con bsdtar en macOS.
El problema en Packer parece estar en Golang 1.10. Obviamente, crea diferentes archivos tar entre Golang 1.9 y 1.10.

Usé otro binario Go de https://github.com/mholt/archiver/releases para extraer los archivos tar creados con el código de muestra dirtobox anterior compilado con Golang 1.9 y 1.10.

El archivador puede extraer el archivo del archivo tar creado con el binario dirtobox Golang 1.9.
Y el archivador acaba de escribir un archivo vacío extrayendo el archivo tar creado con el binario dirtobox Golang 1.10.

No se incluyó ningún binario tar / bsdtar en esa prueba.

Una prueba con el bsdtar incrustado de mi Vagrant 2.0.2 también puede extraer archivos 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 ... Está bien. ¡Pensé que teníamos eso explicado! Buena suerte rastreando el error ...

He tenido el problema recientemente, pero no puedo avanzar para volver a Packer 1.1.3. Supongo que no tienes otras ideas.

(El problema está documentado en https://github.com/Parallels/vagrant-parallels/issues/319, ¡ya que pensé que era un problema de complemento!)

Así que investigando un poco más;
Volví a Packer 1.1.2 en OSX 10.12, y eso me las arreglé para producir una caja estable que pude usar.
¿Prueba con Packer 1.1.2 en OSX 10.13 y falla por alguna razón? El disco duro dice que es 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

Así que definitivamente parece que es un problema de empaquetador en alguna parte ... ¿cómo se hace para depurar esto, ya que realmente necesito que el vagabundo funcione para estas máquinas?

FYI. Hoy hay un nuevo empaquetador y golang de homebrew para Sierra. Y nueva empacadora para High Sierra.

@basictheprogram ¡ Gracias por la actualización!

Los he actualizado a ambos al último Packer disponible en Homebrew (1.2.2)

• Sierra funciona bien
• High Sierra todavía no puede conectar el disco duro

No estoy seguro de qué más podría estar causando este problema además de la diferencia del sistema operativo.

Lo extraño es que ejecutar $ tar .box muestra que para ambos sistemas operativos piensan que el disco duro tiene un tamaño de 0 ... pero hacer vagrant up funciona bien para Sierra One. (Ambos ejecutan Vagrant 2.0.3).

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

Sierra alta:

$ 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

En el paquete de actualización de Sierra instalado, vaya.

$ sw_vers
Nombre del producto: Mac OS X
Versión del producto: 10.12.6
BuildVersion: 16G1212

$ go versión
go versión go1.10 darwin / amd64

En High Sierra, el empaquetador de actualización no instaló go

$ sw_vers
Nombre del producto: Mac OS X
Versión del producto: 10.13.3
Versión de construcción: 17D102

$ que van

$ ls -l / usr / local / bin / go *
ls: / usr / local / bin / go *: No existe tal archivo o directorio

Instalé manualmente go y las cosas me están funcionando ahora.

Necesito confirmar todo esto en otras instalaciones.

El binario de Packer 1.2.2 para macOS (https://releases.hashicorp.com/packer/1.2.2/packer_1.2.2_darwin_amd64.zip) está compilado con Golang 1.8.1. Supongo que debería funcionar de nuevo.

Homebrew Packer 1.2.2 está compilado con Golang 1.10
Hombre, ¿por qué tienen que compilar binarios cuando HashiCorp ya los ha implementado?

Impresionante investigación, amigos. Me parece que esto es un error en Homebrew en lugar de un error en Packer. ¿Están todos de acuerdo? ¿Debo cerrar este ticket?

Creo que el error está en Golang y el empaquetador está compilado con un Golang con errores. Hashicorp debería compilar su empaquetador con Golang 1.10.

¿Suena como que el binario con errores es de Homebrew y el binario de HashiCorp funciona?

Alguien debería probar el binario de HashiCorp 1.2.2. Puedo probarlo mañana.

Voy a recompilar y volver a publicar HashiCorp 1.2.2. binario en golang 1.10 ahora. Deberíamos tener eso en el último golang.

Hm, pero entonces probablemente se romperá como 1.2.1.

Aquí está el binario compilado de golang-1.8, para aquellas personas que necesitan una solución alternativa:
packer_1.2.2_darwin_amd64.zip . Lanzarlo compilado con 1.8 fue un accidente, y solo porque corrige este error no significa que no introduzca otros.

@basictheprogram Mis sistemas ya tenían go instalado cuando hice la verificación:

$ 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

Acabo de probar el binario compilado 1.8 de Packer 1.2.2 @SwampDragons publicado arriba:
Sierra: vagrant box falla (para encontrar el disco duro)
High Sierra: the vagrant box falló de nuevo (mismo problema)

Probando el Packer 1.2.2 predeterminado compilado con 1.10:
Sierra: vagrant box falla (para encontrar el disco duro)
High Sierra: the vagrant box falló de nuevo (mismo problema)

El archivo .pvm tiene 16 GB que intenta comprimir y la caja de salida es de 9 GB ...
Empiezo a pensar que ahora tiene algo que ver con mi sistema.

¿Alguien puede confirmar que 1.2.2 está funcionando y, de ser así, qué configuración?

(Nota extraña; dije antes que lo tenía funcionando en Sierra con Brew's Packer, ahora no funciona ...)

@SwampDragons como se esperaba:

• Packer 1.2.2 compilado con Golang 1.8 crea archivos de caja que funcionan bien con macOS tar (bsdtar 2.8.3 - libarchive 2.8.3).
• Packer 1.2.2 compilado con Golang 1.10 crea archivos de caja que macOS tar no puede extraer (archivos de 0 bytes)
• Ambos archivos de caja generados funcionan bien con GNU tar (solo probé una versión de Linux en un contenedor con 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 He estado usando go 1.10 (instalado a través de MacPorts) para compilar mis binarios de Packer. Como se indicó anteriormente, puedo crear cajas grandes sin problema ...

@SurferL Mi configuración:

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

Desembalar la caja (usando GNU tar) de mi compilación de Windows 2016 me da:

.
└── [        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 eso estaba tan convencido (al principio) de que estábamos viendo este problema en lugar de un problema con Packer. Sin embargo, el trabajo que ha hecho @StefanScherer parece sugerir que el problema está en otra parte ...

EDITAR: Acabo de ver el comentario de @StefanScherer arriba ... ¿así que este podría ser el mismo problema aunque con información adicional proporcionada por Stefan?

Esto podría haberse solucionado en https://golang.org/doc/devel/release.html#go1.10.minor

Puedo ver una solución para el archivo / zip en 1.10.1. Lo intenté con un código de muestra simplificado, pero todavía existe el problema. También ocurre con un binario de Linux Golang. El tar de macOS (bsdtar) no puede leer el tamaño del archivo correctamente.

Creé https://github.com/golang/go/issues/24599

Aquí está el packer construido con go 1.10.1 para darwin. Agradecería cualquier ayuda en la prueba si esto resuelve el problema.

packer-1.2.2-go-1.10.1.zip

Gracias @StefanScherer por archivar el error upstream. Contiene un montón de información útil

¿Qué puedes hacer?
Go1.10 le da al usuario un control más preciso sobre el formato de salida. Puede ver tar.Header.Format en tar.FormatGNU para solucionar el error libarchive.

Parece que debería ser así. Si alguien desea enviar un PR, hágalo; de lo contrario, agregaremos la solución para el próximo lanzamiento de puntos. Compilar el empaquetador con una versión anterior de go debería ser una solución viable por ahora.

Lo haré después de algunas pruebas.

Me temo que sigo recibiendo el mismo error con Packer construido con go 1.10.1 para Darwin que @mwhooker proporcionó ... el .box generado al final contiene un disco duro vacío supuestamente para un tamaño de caja de 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

(y ejecutar vagrant up falla con el error del disco duro)

También sigo recibiendo el error ( vagrant up disco duro) usando Packer 1.1.3 , así que no estoy seguro de si es algo con mi sistema.
¿Aunque el disco duro parece estar inicializado aquí?

$ 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

¿Has probado el packer de brew?

@basictheprogram Sí, probé la última

@SurferL ¿Estás usando vagrant box add... ? Estoy bastante seguro de que la versión incrustada de tar de Vagrants causará estos problemas independientemente de la solución que se haya aplicado a Packer. Vea mi comentario aquí .

Largo y corto, es posible que deba descomprimir manualmente la caja en la ubicación correcta en el directorio .vagrant.d ... usando GNU tar en lugar de bsdtar hasta que se publique la próxima versión de Vagrant.

@DanHam Gracias por señalar eso, no estaba usando vagrant box add , ¡y esto hizo que mi compilación funcionara con Packer 1.1.3 !

Solo un poco más de información:
Usar Packer 1.2.2 de brew (y usar vagrant box add no funcionó), ni usar Packer construido con go 1.10.1 para Darwin (y usar vagrant box add ) ...

Voy a bloquear este problema porque ha estado cerrado durante _30 días_ ⏳. Esto ayuda a nuestros mantenedores a encontrar y concentrarse en los problemas activos.

Si ha encontrado un problema que parece similar a este, abra un nuevo problema y complete la plantilla de problemas para que podamos capturar todos los detalles necesarios para investigar más a fondo.