<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 أي تغييرات منذ 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 إلى 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

يبدو أنه يحدث مع الملفات التي يزيد حجمها عن 8 جيجابايت.

حان الوقت لفتح قضية في جولانج ؟

ممتازStefanScherer

واجهت مشكلة مشابهة جدًا مع Vagrant اليوم - انظر هنا .

طويل وقصير الأداة المساعدة tar المضمنة في Vagrant 2.0.3 تواجه مشكلات في تفريغ ملفات الأرشيف ذات الملفات الكبيرة - عند استخدام bsdtar لاستخراج الملفات من أرشيف box 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...

basictheprogramStefanScherer عذرا - مجرد النظر في القضية الأصلية HERE .

هذه هي نفس المشكلة التي تم الإبلاغ عنها هنا - وليست مشكلة باكر!

شكرًا @ DanHam على
قد تكون هناك مشكلة في bsdtar على macOS.
يبدو أن المشكلة في 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

تضمين التغريدة ظننت أننا قد شرحنا ذلك! حظًا سعيدًا في تعقب الخطأ ...

لقد واجهت المشكلة مؤخرًا ، لكنني غير قادر على إحراز أي تقدم مع العودة إلى Packer 1.1.3. لا أفترض أن لديك أي أفكار أخرى؟

(المشكلة موثقة في https://github.com/Parallels/vagrant-parallels/issues/319 ، حيث اعتقدت أنها مشكلة مكون إضافي!)

حتى تحقيق المزيد ؛
عدت إلى Packer 1.1.2 على OSX 10.12 ، وتمكنت من إنتاج صندوق ثابت يمكنني استخدامه.
الاختبار مع 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

لذلك يبدو بالتأكيد أنها مشكلة باكر في مكان ما ... كيف يمكنك تصحيح هذا الأمر ، حيث أحتاج حقًا إلى العمل المتشرد مع هذه الأجهزة!

لعلمك. هناك باكر وجولانج جديدان من البيرة المحلية اليوم لسييرا. وباكر جديد هاي سييرا.

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
انتقل الإصدار 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. ثنائي على جولانج 1.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

لقد اختبرت للتو الإصدار الثنائي 1.8 المترجم لـ Packer
سييرا: فشل الصندوق المتشرد (للعثور على القرص الصلب)
هاي سييرا: صندوق المتشرد فشل مرة أخرى (نفس المشكلة)

اختبار الافتراضي Packer 1.2.2 المترجمة مع 1.10:
سييرا: فشل الصندوق المتشرد (للعثور على القرص الصلب)
هاي سييرا: صندوق المتشرد فشل مرة أخرى (نفس المشكلة)

حجم الملف .pvm 16 جيجا بايت يحاول ضغطه ، وصندوق الإخراج 9 جيجا بايت ...
بدأت أعتقد أن الأمر يتعلق بنظامي الآن.

هل يمكن لأي شخص أن يؤكد أن 1.2.2 تعمل ، وإذا كان الأمر كذلك ، فما هو الإعداد؟

(ملاحظة غريبة ؛ لقد قلت سابقًا إنني عملت على Sierra مع Brew's Packer ، إنها لا تعمل الآن ...)

SwampDragons كما هو متوقع:

• ينشئ Packer 1.2.2 المترجمة مع Golang 1.8 ملفات صندوق تعمل بشكل جيد مع macOS tar (bsdtar 2.8.3 - libarchive 2.8.3).
• يقوم Packer 1.2.2 المترجمة مع Golang 1.10 بإنشاء ملفات مربعة لا يستطيع macOS استخلاصها (ملفات 0 بايت)
• كلا الملفين اللذين تم إنشاؤهما يعملان بشكل جيد مع 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 التي كنت

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

هذا هو السبب في أنني كنت مقتنعًا جدًا (في البداية) بأننا كنا نشهد هذه المشكلة بدلاً من مشكلة مع باكر. ومع ذلك ، يبدو أن العمل الذي قام به StefanScherer يشير إلى أن المشكلة تكمن في مكان آخر ...

تحرير: شاهدت للتو تعليق

ربما تم إصلاح ذلك في https://golang.org/doc/devel/release.html#go1.10.minor

يمكنني رؤية إصلاح للأرشيف / zip في 1.10.1. لقد حاولت باستخدام نموذج رمز تم تجريده ، ولكن لا تزال هناك مشكلة. يحدث أيضًا مع نظام Linux Golang الثنائي. لا يستطيع macOS tar (bsdtar) قراءة حجم الملف بشكل صحيح.

لقد أنشأت https://github.com/golang/go/issues/24599

هنا باكر مبني بجو 1.10.1 لداروين. نقدر أي مساعدة في اختبار ما إذا كان هذا يحل المشكلة.

باكر -1.2.2-go-1.10.1.zip

شكرًا StefanScherer على حفظ الخطأ المنبع. هناك الكثير من المعلومات المفيدة فيه

ما الذي تستطيع القيام به؟
يمنح Go1.10 المستخدم تحكمًا أفضل في تنسيق الإخراج. يمكنك رؤية tar.Header.Format to 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 نعم ، لقد جربت الإصدار 1.2.2 الأحدث ، بالإضافة إلى الرجوع إلى 1.1.3 مع Brew لكن كلاهما لم يعمل مع نفس المشكلات المذكورة أعلاه

SurferL هل تستخدم vagrant box add... ؟ أنا متأكد تمامًا من أن إصدار Vagrants المضمّن من tar سيتسبب في حدوث هذه المشكلات بغض النظر عن الإصلاح الذي تم إدخاله إلى Packer. انظر تعليقي هنا .

طويلًا وقصيرًا ، قد تحتاج إلى فك ضغط المربع يدويًا في المكان الصحيح في الدليل .vagrant.d ... باستخدام GNU tar بدلاً من bsdtar حتى يتم إصدار الإصدار التالي من Vagrant.

DanHam نشكرك على الإشارة إلى ذلك - لم أكن أستخدم vagrant box add ، وهذا جعل عملي البناء مع Packer 1.1.3 !

فقط بعض المعلومات الإضافية:
استخدام Packer 1.2.2 من الشراب (واستخدام vagrant box add لم ينجح) ، ولا استخدام Packer المبني مع go 1.10.1 لداروين (وباستخدام vagrant box add ) ...

سأقوم بإغلاق هذه المشكلة لأنه تم إغلاقه لمدة _30 يومًا_ ⏳. يساعد هذا المشرفين لدينا في العثور على المشكلات النشطة والتركيز عليها.

إذا وجدت مشكلة تبدو مشابهة لهذا ، فالرجاء فتح مشكلة جديدة وإكمال نموذج المشكلة حتى نتمكن من الحصول على جميع التفاصيل اللازمة لإجراء مزيد من التحقيق.