<p>packer produit 0 octet vmdk</p>

Oh, je peux reproduire le problème sur macOS 10.13.3 et 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

J'ai réessayé avec une ancienne version de Packer 1.1.3, toujours macOS 10.13.3 et APFS, VirtualBox 5.2.8 et le fichier boîte semble bien aprè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*

Quelle pourrait être la différence entre Packer 1.1.3 et Packer 1.2.1?

La fonction DirToBox est-elle significativement différente dans la version 1.2.1?

Désolé, pas très bon avec git, donc je ne sais pas comment extraire ce code comme vous l'avez fait avec

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

Un blâme git ne montre aucun changement depuis packer 1.1.1 dans packer / post-processor / vagrant / util.go.
Packer 1.1.3 est compilé avec Go 1.9, Packer 1.2.1 est compilé avec Go 1.10.

Cela ressemble vraiment à un problème avec Golang 1.10.

J'ai extrait le fichier packer / post-processor / vagrant / util.go dans un petit main.go appelant la fonction DirToBox sans packer.Ui.

En compilant ce code avec Golang 1.9, le fichier tar créé semble bon.
En compilant ce code avec Golang 1.10, le fichier tar affiche un fichier de zéro octet.

Le problème se produit également avec le niveau de compression = 0, il est donc indépendant du package pgzip.

L'exemple de source dirtobox.go , les scripts Dockerfile et build.sh pour construire le binaire Darwin peuvent être trouvés dans ce gist: https://gist.github.com/StefanScherer/c55fd0ae752687c806f8d5fb40cadc78

J'ai créé un exemple in répertoire dirtobox pour Darwin et exécuté le test

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

Changement du Dockerfile en golang: 1.9

FROM golang:1.9

WORKDIR /go/src/app
COPY . .

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

et exécuter à nouveau ./build.sh et ./dirtobox produit à nouveau un fichier tar correct:

$ 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

Cela semble se produire avec des fichiers> 8 Go.

Il est temps d'ouvrir un problème chez Golang ?

Excellent triage @StefanScherer

J'ai rencontré un problème très similaire avec Vagrant aujourd'hui - voir ICI .

Long et court, l'utilitaire tar intégré à Vagrant 2.0.3 a des problèmes pour décompresser les archives avec des fichiers volumineux - lorsque vous utilisez bsdtar pour extraire les fichiers de l'archive box tar, je me retrouve avec un vmdk très mince de zéro octet! Les boîtes plus petites ne posent aucun problème.

Notez que le système tar n'a aucun problème pour extraire les fichiers de la même archive 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 - Êtes-vous sûr que ce n'est pas la version tar que vous utilisez qui cause les problèmes?

@StefanScherer Juste pour référence:

$ 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 Désolé - je viens de regarder le problème original ICI .

Ce problème est le même comme cela a été rapporté ICI - pas un problème Packer!

Merci @DanHam pour le heads-up.
Il peut y avoir un problème avec bsdtar sous macOS.
Le problème dans Packer semble être avec Golang 1.10. Il crée évidemment différents fichiers tar entre Golang 1.9 et 1.10.

J'ai utilisé un autre binaire Go de https://github.com/mholt/archiver/releases pour extraire les fichiers tar créés avec l'exemple de code dirtobox ci-dessus compilé avec Golang 1.9 et 1.10.

L'archiveur peut extraire le fichier du fichier tar créé avec le binaire dirtobox Golang 1.9.
Et l'archiveur vient d'écrire un fichier vide en extrayant le fichier tar créé avec le binaire dirtobox Golang 1.10.

Aucun binaire tar / bsdtar n'a été inclus dans ce test.

Un test avec le bsdtar intégré de mon Vagrant 2.0.2 peut également extraire de gros fichiers

$ /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. Je pensais que nous avions expliqué celui-là! Bonne chance pour retrouver le bogue ...

J'ai eu le problème récemment, mais je suis incapable de faire des progrès avec le retour à Packer 1.1.3. Je suppose que vous n'avez pas d'autres idées?

(Le problème est documenté dans https://github.com/Parallels/vagrant-parallels/issues/319, car je pensais que c'était un problème de plugin!)

Donc enquêter un peu plus;
Je suis revenu à Packer 1.1.2 sur OSX 10.12, et cela a réussi à produire une Box stable que je pourrais utiliser.
Tester avec Packer 1.1.2 sur OSX 10.13 et qui échoue pour une raison quelconque? Le disque dur indique que c'est 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

On dirait donc que c'est un problème de packer quelque part ... comment faire pour déboguer cela, car j'ai vraiment besoin de faire fonctionner vagrant pour ces machines!

POUR VOTRE INFORMATION. Il y a un nouveau packer et golang de l'homebrew aujourd'hui pour Sierra. Et nouveau packer pour High Sierra.

@basictheprogram Merci pour la mise à jour!

Je les ai mis à jour avec le dernier Packer disponible sur Homebrew (1.2.2)

• Sierra fonctionne bien
• High Sierra ne parvient toujours pas à connecter le disque dur

Je ne suis pas sûr de ce qui pourrait causer ce problème en dehors de la différence de système d'exploitation?

Ce qui est étrange, c'est que l'exécution de $ tar .box montre que pour les deux OS, le disque dur a une taille de 0 ... mais faire vagrant up fonctionne bien pour le Sierra. (Ils exécutent tous les deux 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

Haute 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

Sur le packer de mise à niveau Sierra installé, allez.

$ sw_vers
Nom du produit: Mac OS X
Version du produit: 10.12.6
Version de construction: 16G1212

$ go version
aller à la version go1.10 darwin / amd64

Sur High Sierra, le packer de mise à niveau n'a pas installé aller

$ sw_vers
Nom du produit: Mac OS X
Version du produit: 10.13.3
BuildVersion: 17D102

$ qui vont

$ ls -l / usr / local / bin / go *
ls: / usr / local / bin / go *: aucun fichier ou répertoire de ce type

J'ai installé go manuellement et les choses fonctionnent pour moi maintenant.

J'ai besoin de confirmer tout cela sur d'autres installations.

Le binaire Packer 1.2.2 pour macOS (https://releases.hashicorp.com/packer/1.2.2/packer_1.2.2_darwin_amd64.zip) est compilé avec Golang 1.8.1. Je suppose que cela devrait fonctionner à nouveau.

Homebrew Packer 1.2.2 est compilé avec Golang 1.10
Mec, pourquoi doivent-ils compiler des binaires alors que les binaires sont déjà déployés par HashiCorp?

Super enquête, les amis. Il me semble que c'est un bogue dans Homebrew plutôt qu'un bogue dans Packer - seriez-vous tous d'accord? Dois-je fermer ce ticket?

Je pense que le bug est dans Golang et que le packer est compilé avec un buggy Golang. Hashicorp devrait compiler son packer avec Golang 1.10.

On dirait que le binaire buggy est celui de Homebrew et que le binaire HashiCorp fonctionne?

Quelqu'un devrait tester le binaire HashiCorp 1.2.2. Peut le tester demain.

Je vais recompiler et rééditer le HashiCorp 1.2.2. binaire sur golang 1.10 maintenant. Nous devrions avoir cela sur le dernier golang.

Hm, mais alors il sera probablement cassé en tant que 1.2.1.

Voici le binaire compilé par golang-1.8, pour les personnes qui ont besoin d'une solution de contournement:
packer_1.2.2_darwin_amd64.zip . Le publier compilé avec la version 1.8 était un accident, et ce n'est pas parce qu'il corrige ce bogue qu'il n'en introduit pas d'autres.

@basictheprogram Mes systèmes avaient déjà installé go lorsque j'ai fait la vérification:

$ 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

Je viens de tester le binaire compilé 1.8 de Packer 1.2.2 @SwampDragons posté ci-dessus:
Sierra: la boîte vagabonde échoue (pour trouver le disque dur)
High Sierra: la boîte vagabonde a de nouveau échoué (même problème)

Test du packer 1.2.2 par défaut compilé avec 1.10:
Sierra: la boîte vagabonde échoue (pour trouver le disque dur)
High Sierra: la boîte vagabonde a de nouveau échoué (même problème)

Le fichier .pvm fait 16 Go qu'il essaie de compresser et la boîte de sortie fait 9 Go ...
Je commence à penser que cela a quelque chose à voir avec mon système maintenant.

Quelqu'un peut-il confirmer que la version 1.2.2 fonctionne, et si oui, quelle configuration?

(Note étrange; j'ai dit plus tôt que je l'avais travaillé sur Sierra avec Brew's Packer, cela ne fonctionne plus maintenant ...)

@SwampDragons comme prévu:

• Packer 1.2.2 compilé avec Golang 1.8 crée des fichiers box qui fonctionnent correctement avec le tar macOS (bsdtar 2.8.3 - libarchive 2.8.3).
• Packer 1.2.2 compilé avec Golang 1.10 crée des fichiers boîte que macOS tar ne peut pas extraire (fichiers de 0 octet)
• Les deux fichiers box générés fonctionnent bien avec GNU tar (j'ai seulement essayé une version Linux dans un conteneur avec 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 J'utilise go 1.10 (installé via MacPorts) pour compiler mes binaires Packer. Comme indiqué ci-dessus, je peux créer de grandes boîtes sans problème ...

@SurferL Ma configuration:

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

Déballer la boîte (en utilisant GNU tar) de ma version Windows 2016 me donne:

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

C'est pourquoi j'étais si convaincu (au début) que nous voyions ce problème plutôt qu'un problème avec Packer. Cependant, le travail effectué par @StefanScherer semble suggérer que le problème est ailleurs ...

EDIT: Je viens de voir le commentaire de @StefanScherer ci-dessus ... donc cela pourrait être le même problème, mais avec des informations supplémentaires fournies par Stefan?

Cela a peut-être été corrigé dans https://golang.org/doc/devel/release.html#go1.10.minor

Je peux voir un correctif pour archive / zip dans 1.10.1. J'ai essayé avec un exemple de code dépouillé, mais il y a toujours le problème. Cela se produit également avec un binaire Linux Golang. Le tar macOS (bsdtar) ne peut pas lire correctement la taille du fichier.

J'ai créé https://github.com/golang/go/issues/24599

Voici packer construit avec go 1.10.1 pour darwin. J'apprécierais toute aide pour tester si cela résout le problème.

packer-1.2.2-go-1.10.1.zip

Merci @StefanScherer pour avoir déposé le bogue en amont. Il contient une tonne d'informations utiles

Que pouvez-vous faire?
Go1.10 donne à l'utilisateur un contrôle plus fin sur le format de sortie. Vous pouvez voir tar.Header.Format vers tar.FormatGNU pour contourner le bogue libarchive.

Ça devrait être ça. Si quelqu'un souhaite soumettre un PR, veuillez le faire, sinon nous ajouterons la solution de contournement pour la prochaine version intermédiaire. Compiler Packer avec une ancienne version de go devrait être une solution de contournement viable pour le moment.

Fera après quelques tests.

Peur que je reçois toujours la même erreur avec Packer construit avec go 1.10.1 pour Darwin que @mwhooker a fourni ... le .box généré à la fin contient un disque dur vide supposé pour une taille de boîte de 12 Go

$ 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

(et l'exécution de vagrant up échoue avec l'erreur de disque dur)

J'obtiens également toujours l'erreur ( vagrant up disque dur) en utilisant Packer 1.1.3 , donc je ne suis pas sûr si c'est quelque chose avec mon système?
Même si le disque dur semble être initialisé ici?

$ 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

Avez-vous essayé packer de brew?

@basictheprogram Ouais, j'ai essayé la dernière version 1.2.2, ainsi que je suis revenu à la version 1.1.3 avec Brew mais ils ne fonctionnaient pas tous les deux avec les mêmes problèmes ci-dessus

@SurferL Utilisez -vous vagrant box add... ? Je suis à peu près sûr que la version intégrée de tar de Vagrants causera ces problèmes, quel que soit le correctif apporté à Packer. Voir mon commentaire ici .

Long et court, vous devrez peut-être décompresser manuellement la boîte au bon endroit dans le répertoire .vagrant.d ... en utilisant GNU tar plutôt que bsdtar jusqu'à ce que la prochaine version de Vagrant soit publiée.

@DanHam Merci d'avoir signalé cela - je n'utilisais pas vagrant box add , et cela a permis à ma compilation de fonctionner avec Packer 1.1.3 !

Juste quelques informations supplémentaires:
Utiliser Packer 1.2.2 de brew (et utiliser vagrant box add n'a pas fonctionné), ni utiliser Packer construit avec go 1.10.1 pour Darwin (et utiliser vagrant box add ) ...

Je vais verrouiller ce problème car il est fermé depuis _30 jours_ ⏳. Cela aide nos responsables à trouver et à se concentrer sur les problèmes actifs.

Si vous avez trouvé un problème qui semble similaire à celui-ci, veuillez ouvrir un nouveau problème et compléter le modèle de problème afin que nous puissions capturer tous les détails nécessaires pour approfondir l'enquête.