<p>упаковщик выдает 0 байт vmdk</p>

О, я могу воспроизвести проблему на macOS 10.13.3 и 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

Я попытался использовать более старую версию 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*

В чем может быть разница между Packer 1.1.3 и Packer 1.2.1?

Существенно ли отличается функция DirToBox в 1.2.1?

Извините, не очень хорошо с git, поэтому я не знаю, как вытащить этот код, как вы это сделали с

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

Git blame не показывает никаких изменений с момента packer 1.1.1 в packer / post-processor / vagrant / util.go.
Packer 1.1.3 скомпилирован с Go 1.9, Packer 1.2.1 скомпилирован с Go 1.10.

Это действительно похоже на проблему с Golang 1.10.

Я извлек файл packer / post-processor / vagrant / util.go в небольшой файл main.go, вызвав функцию DirToBox без packer.Ui.

После компиляции этого кода с помощью Golang 1.9 созданный tar-файл выглядит хорошо.
При компиляции этого кода с помощью Golang 1.10 файл tar показывает файл с нулевым байтом.

Проблема также возникает при уровне сжатия = 0, поэтому он не зависит от пакета pgzip.

Исходный код образца dirtobox.go , Dockerfile и build.sh скрипт для создания двоичного файла Дарвина можно найти в следующем содержании: https://gist.github.com/StefanScherer/c55fd0ae752687c806f8d5fb40cadc78

Я создал образец каталога in с большим файлом, скомпилировал двоичный файл 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 обратно на голанг: 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

Похоже, это происходит с файлами размером> 8 ГБ.

Пришло время открыть вопрос на

Отличная сортировка @StefanScherer

Сегодня я столкнулся с очень похожей проблемой с Vagrant - см. ЗДЕСЬ .

Короче говоря, утилита tar, встроенная в Vagrant 2.0.3 , испытывает проблемы с распаковкой архивов с большими файлами - при использовании bsdtar для извлечения файлов из коробочного tar-архива я получаю очень тонкий vmdk с нулевыми байтами! Коробки меньшего размера не вызывают никаких проблем.

Обратите внимание, что системный tar не имеет проблем с извлечением файлов из того же архива 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 - Вы уверены, что проблема не в используемой вами версии 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 Извините - только что посмотрел ЗДЕСЬ исходный выпуск.

Это та же проблема , как сообщалось здесь - не проблема Packer!

Спасибо @DanHam за
На macOS может быть проблема с bsdtar.
Проблема в Packer, похоже, связана с Golang 1.10. Очевидно, что он создает разные tar-файлы между Golang 1.9 и 1.10.

Я использовал другой двоичный файл Go с https://github.com/mholt/archiver/releases для извлечения файлов tar, созданных с помощью приведенного выше примера кода dirtobox, скомпилированного с Golang 1.9 и 1.10.

Архиватор может извлечь файл из tar-файла, созданного с помощью двоичного файла dirtobox Golang 1.9.
И архиватор просто написал пустой файл, извлекая tar-файл, созданный с помощью двоичного файла dirtobox Golang 1.10.

В этот тест не был включен двоичный файл tar / bsdtar.

Тест со встроенным bsdtar моего Vagrant 2.0.2 также может извлекать большие файлы

$ /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 А ... Хорошо. Думал, мы объяснили это! Удачи в отслеживании ошибки ...

Недавно у меня возникла проблема, но я не могу вернуться к Packer 1.1.3. Не думаю, что у вас есть другие идеи?

(Проблема задокументирована в https://github.com/Parallels/vagrant-parallels/issues/319, поскольку я думал, что это проблема плагина!)

Итак, расследуем еще немного;
Я вернулся к Packer 1.1.2 в OSX 10.12, и мне удалось создать стабильный Box, который я мог бы использовать.
Тестирование с Packer 1.1.2 на OSX 10.13 по какой-то причине не удается? Жесткий диск говорит, что это 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

Так что определенно похоже, что это где-то проблема с упаковщиком ... как вы отлаживаете это, поскольку мне действительно нужно заставить бродягу работать на этих машинах!

К вашему сведению. Есть сегодня новый упаковщик и голанг от homebrew для Sierra. И новый упаковщик для High Sierra.

@basictheprogram Спасибо за обновление!

Я обновил их до последней версии Packer, доступной на Homebrew (1.2.2).

• Сьерра отлично работает
• High Sierra по-прежнему не может подключить жесткий диск

Я не уверен, что еще может вызывать эту проблему, кроме разницы в ОС?

Что странно, так это то, что запуск $ tar .box показывает, что для обеих операционных систем размер жесткого диска равен 0 ... но выполнение vagrant up отлично подходит для Sierra. (Они оба работают под 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

На Sierra установлен апгрейд пакера иду.

$ sw_vers
Название продукта: Mac OS X
Версия продукта: 10.12.6
Версия сборки: 16G1212

версия $ go
go версия go1.10 darwin / amd64

На High Sierra не устанавливался апгрейд пакера go

$ sw_vers
Название продукта: Mac OS X
Версия продукта: 10.13.3
Версия сборки: 17D102

$ которые идут

$ ls -l / usr / local / bin / go *
ls: / usr / local / bin / go *: нет такого файла или каталога

Я вручную установил go, и теперь у меня все работает.

Мне нужно подтвердить все это на других установках.

Бинарный файл Packer 1.2.2 для macOS (https://releases.hashicorp.com/packer/1.2.2/packer_1.2.2_darwin_amd64.zip) скомпилирован с Golang 1.8.1. Я полагаю, это должно снова работать

Homebrew Packer 1.2.2 скомпилирован с Golang 1.10
Чувак, зачем им компилировать двоичные файлы, если двоичные файлы уже развернуты HashiCorp?

Отличное расследование, ребята. Мне кажется, что это ошибка в Homebrew, а не в Packer - вы все согласны? Должен ли я закрыть этот тикет?

Думаю, ошибка в Golang, а упаковщик скомпилирован с глючным Golang. Hashicorp должен скомпилировать свой упаковщик с Golang 1.10.

Похоже, что бинарный файл с ошибками принадлежит Homebrew, а бинарный файл HashiCorp работает?

Кто-то должен протестировать бинарный файл HashiCorp 1.2.2. Могу завтра протестировать.

Я собираюсь перекомпилировать и перевыпустить HashiCorp 1.2.2. бинарный на golang 1.10 сейчас. У нас должно быть это на последнем голанге.

Хм, но тогда наверняка сломается как 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

Я только что протестировал скомпилированный двоичный файл Packer 1.2.2 @SwampDragons версии 1.8, опубликованный выше:
Сьерра: бродячая коробка не работает (найти жесткий диск)
High Sierra: бродячая коробка снова вышла из строя (та же проблема)

Тестирование Packer 1.2.2 по умолчанию, скомпилированного с 1.10:
Сьерра: бродячая коробка не работает (найти жесткий диск)
High Sierra: бродячая коробка снова вышла из строя (та же проблема)

Размер файла .pvm составляет 16 ГБ, который он пытается сжать, а размер выходного поля - 9 ГБ ...
Я начинаю думать, что теперь это как-то связано с моей системой.

Может ли кто-нибудь подтвердить, что 1.2.2 работает, и если да, то какие настройки?

(Странное примечание; я сказал ранее, что он работал над Sierra с Brew's Packer, теперь он не работает ...)

@SwampDragons, как и ожидалось:

• Packer 1.2.2, скомпилированный с Golang 1.8, создает файлы ящиков, которые отлично работают с tar macOS (bsdtar 2.8.3 - libarchive 2.8.3).
• Packer 1.2.2, скомпилированный с Golang 1.10, создает файлы ящиков, которые tar macOS не может извлечь (0-байтовые файлы)
• Оба сгенерированных файла box отлично работают с GNU tar (я пробовал только версию для Linux в контейнере с 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 Я использовал go 1.10 (установленный через MacPorts) для компиляции двоичных файлов Packer. Как указано выше, я могу создавать большие коробки без проблем ...

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

Распаковка коробки (с использованием GNU tar) из моей сборки Windows 2016 дает мне:

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

Я вижу исправление для архива / zip в 1.10.1. Я пробовал использовать урезанный образец кода, но проблема все еще существует. Это также происходит с двоичным файлом Linux Golang. Tar macOS (bsdtar) не может правильно прочитать размер файла.

Я создал https://github.com/golang/go/issues/24599

Вот пакер, созданный с помощью go 1.10.1 для darwin. Буду признателен за любую помощь в тестировании, если это решит проблему.

packer-1.2.2-go-1.10.1.zip

Спасибо @StefanScherer за сообщение об ошибке в восходящем направлении. В нем масса полезной информации

Что ты можешь сделать?
Go1.10 дает пользователю более точный контроль над форматом вывода. Вы можете увидеть tar.Header.Format в tar.FormatGNU, чтобы обойти ошибку libarchive.

Похоже, так и должно быть. Если кто-то хочет отправить PR, пожалуйста, сделайте это, иначе мы добавим обходной путь для следующего выпуска точки. Компиляция упаковщика со старой версией go на данный момент должна быть жизнеспособным решением.

Сделаю после некоторых тестов.

Боюсь, я все еще получаю ту же ошибку с Packer, созданным с go 1.10.1 для Darwin, который предоставил @mwhooker ... .box сгенерированный в конце, содержит пустой жесткий диск, предположительно для размера коробки 12 ГБ

$ 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 завершается с ошибкой жесткого диска)

Я также все еще получаю ошибку ( vagrant up жесткого диска), используя Packer 1.1.3 , поэтому я не уверен, что это что-то с моей системой?
Хотя кажется, что жесткий диск здесь инициализирован?

$ 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

Пробовали пакер от варево?

@basictheprogram Да, я пробовал последнюю

@SurferL Вы используете vagrant box add... ? Я почти уверен, что встроенная версия tar в Vagrants вызовет эти проблемы независимо от исправления, внесенного в Packer. Смотрите мой комментарий здесь .

Короче говоря, вам может потребоваться вручную распаковать коробку в нужное место в каталоге .vagrant.d ..., используя GNU tar, а не bsdtar, до тех пор, пока не будет выпущена следующая версия Vagrant.

@DanHam Спасибо, что указали на это - я не использовал vagrant box add , и это заставило мою сборку работать с Packer 1.1.3 !

Еще немного информации:
Использование Packer 1.2.2 из brew (и использование vagrant box add не помогло), а также использование Packer, созданного с помощью go 1.10.1 для Дарвина (и использование vagrant box add ) ...

Я собираюсь заблокировать этот выпуск, потому что он был закрыт _30 дней_ ⏳. Это помогает нашим специалистам по сопровождению находить активные проблемы и сосредоточиться на них.

Если вы обнаружили проблему, похожую на эту, откройте новую проблему и заполните шаблон проблемы, чтобы мы могли зафиксировать все сведения, необходимые для дальнейшего расследования.