Packer: Fehler beim Entfernen des Diskettencontrollers

@mealingr Ich denke, dies ist ein Timing-Problem ähnlich wie # 1193. Wir können es wahrscheinlich im Packer mit einem erneuten Versuch beheben.

Ich habe vergessen zu erwähnen, dass ich Version 0.8.0 ausgeführt habe. Ich habe gehört, dass dies möglicherweise in späteren Versionen behoben wird (möglicherweise, weil der Packer mehr Wiederholungsversuche ausführt, als Sie vorschlagen?).

Dies scheint in Version 0.8.1 behoben zu sein.

Ich bin gerade mit 0.8.1 auf denselben Fehler gestoßen. Es ist definitiv zeitweise. Ich habe ungefähr 10 Mal erfolgreich gebaut und dies ist das erste Mal, dass ich dies getroffen habe.

Ich habe dieses Problem zeitweise mit Version 0.8.2. Ich habe einen Windows Server 2012 R2 Bild 5 oder 6 Mal erstellt mit dieser Vorlage https://github.com/joefitzgerald/packer-windows/blob/master/windows_2012_r2.json (nur Modifikation I Satz ohne Kopf auf false haben) und habe den Fehler zweimal bekommen.

Ich verwende Windows 7 Pro als Host mit VirtualBox. Kann ich irgendetwas tun, um das Problem zu diagnostizieren?

Übrigens: Es wäre großartig, wenn es eine Möglichkeit gäbe, den Packer anzuweisen, die Artefakte nicht zu löschen, wenn ein Fehler auftritt. Wenn ich diesen Fehler sehe, ist es nach Stunden der Bilderstellung und dann muss ich wieder von vorne beginnen. Wenn das Bild erhalten bleiben könnte, könnte ich zumindest einige manuelle Bergungsarbeiten durchführen.

Ich habe Probleme mit dem Timing, die ähnlich zu sein scheinen, außer in meinem Fall besteht das Problem darin, die ISO-Installations-ISO zu trennen. Falls es zukünftigen Googlern hilft, ist hier die Fehlerausgabe, die ich gelegentlich sehe:

// [...snip...]
==> mybox-vbox: Connected to SSH!
==> mybox-vbox: Uploading VirtualBox version info (5.0.2)
==> mybox-vbox: Uploading VirtualBox guest additions ISO...
==> mybox-vbox: Provisioning with shell script: provisioners/shell/virtualbox-guest-additions-install.sh
// [...snip provisioner script output...]
==> mybox-vbox: Gracefully halting virtual machine...
    mybox-vbox: [sudo] password for vagrant:
==> mybox-vbox: Error detaching ISO: VBoxManage error: VBoxManage: error: Failed to get a console object from the direct session (VBOX_E_INVALID_OBJECT_STATE)
==> mybox-vbox: VBoxManage: error: Details: code VBOX_E_VM_ERROR (0x80bb0003), component MachineWrap, interface IMachine, callee nsISupports
==> mybox-vbox: VBoxManage: error: Context: "LockMachine(a->session, LockType_Shared)" at line 325 of file VBoxManageStorageController.cpp
==> mybox-vbox: Unregistering and deleting virtual machine...
==> mybox-vbox: Deleting output directory...

Build 'mybox-vbox' errored: Error detaching ISO: VBoxManage error: VBoxManage: error: Failed to get a console object from the direct session (VBOX_E_INVALID_OBJECT_STATE)
VBoxManage: error: Details: code VBOX_E_VM_ERROR (0x80bb0003), component MachineWrap, interface IMachine, callee nsISupports
VBoxManage: error: Context: "LockMachine(a->session, LockType_Shared)" at line 325 of file VBoxManageStorageController.cpp

Ich habe gerade Packer von 0.6.1 auf 0.8.5 und Virtualbox von 4.3.28 auf 5.0.2 aktualisiert. Derselbe Build funktionierte (mindestens einmal) unmittelbar zuvor und arbeitete bei einem nachfolgenden Versuch erneut mit dem aktualisierten Werkzeug. Die Geschwindigkeit, mit der die Operationen verarbeitet werden, scheint die Variable zu sein.

Ich auch auf Packer 0.8.6 und VirtualBox 5.0.4 unter Windows 8.1 x64 als Host-Computer, der Windows Server 2012 R2 als Gast bereitstellt.

gleicher Fehler auf Packer 0.8.6

Ein weiterer Datenpunkt, den Sie hier verlassen müssen. Ich begegne dies nur auf Windows-Hosts. Ich habe es noch nie auf meinem Ubuntu 14-Host gesehen. Als ich an dieser Win7-Vorlage arbeitete , stieß ich zu 100% auf

Ich benutze Mac OS X 10.10.5

ah ok gut zu wissen. Ich habe noch nie einen Mac benutzt. Möglicherweise gibt es hier sogar ein Headless- oder ein GUI-Element, da meine Ubuntu-Box als Server ohne Desktop ausgeführt wird.

Ich habe auch das Problem mit Packer 0.8.6, VirtualBox 5.0.8 unter Windows 7 x64 als Host-Computer, der Windows Server 2008 R2 als Gast bereitstellt. Es passiert systematisch mit "headless": false aber niemals mit "headless": true .

Das Problem tritt immer noch bei "kopflos" auf: true bei 0.8.6

Das gleiche Problem tritt immer noch bei Packer 0.8.6 auf einem Windows 10 x64-Host auf, der Windows Server 2008 R2 als Gast mit "headless": "false" bereitstellt.

Das gleiche Problem ist mir passiert, Windows 7 x64-Host, der Windows Server 2012 R2 als Gast bereitstellt. Packer 0.8.6., Laufen make in Cygwin, Virtual Box 5.0.10. Ich würde dem Vorschlag von @mwrock folgen , die Artefakte bei einem Fehler nicht zu löschen.

Nur ein Update, das die hier gefundenen Änderungen

Ich habe das gleiche Problem beim Erstellen von Windows 7, während Linux Mint 17.2 (auch bekannt als Ubuntu 14.04LTS) ausgeführt wird. FWIW, ich verwende Vorlagen von @mwrock Hier ist mein Fehler:

==> virtualbox-iso: Gracefully halting virtual machine...
    virtualbox-iso: Removing floppy drive...
==> virtualbox-iso: Error removing floppy: VBoxManage error: VBoxManage: error: Failed to get a console object from the direct session (VBOX_E_INVALID_OBJECT_STATE)
==> virtualbox-iso: VBoxManage: error: Details: code VBOX_E_VM_ERROR (0x80bb0003), component MachineWrap, interface IMachine, callee nsISupports
==> virtualbox-iso: VBoxManage: error: Context: "LockMachine(a->session, LockType_Shared)" at line 326 of file VBoxManageStorageController.cpp
==> virtualbox-iso: Unregistering and deleting virtual machine...
==> virtualbox-iso: Deleting output directory...
Build 'virtualbox-iso' errored: Error removing floppy: VBoxManage error: VBoxManage: error: Failed to get a console object from the direct session (VBOX_E_INVALID_OBJECT_STATE)
VBoxManage: error: Details: code VBOX_E_VM_ERROR (0x80bb0003), component MachineWrap, interface IMachine, callee nsISupports
VBoxManage: error: Context: "LockMachine(a->session, LockType_Shared)" at line 326 of file VBoxManageStorageController.cpp

==> Some builds didn't complete successfully and had errors:
--> virtualbox-iso: Error removing floppy: VBoxManage error: VBoxManage: error: Failed to get a console object from the direct session (VBOX_E_INVALID_OBJECT_STATE)
VBoxManage: error: Details: code VBOX_E_VM_ERROR (0x80bb0003), component MachineWrap, interface IMachine, callee nsISupports
VBoxManage: error: Context: "LockMachine(a->session, LockType_Shared)" at line 326 of file VBoxManageStorageController.cpp

Ich habe genau das gleiche Problem wie OP beim Versuch, eine Win 7-VM von einem Win 7-Host zu erstellen.

Keine der hier oder in verknüpften Antworten vorgeschlagenen Problemumgehungen hilft. Hier ratlos.
Irgendwelche anderen Hinweise / Vorschläge?

Dieses Problem tritt von Zeit zu Zeit unter Windows 10 auf, wenn Windows-Boxen erstellt werden. Das Neustarten einer Packer-Task hilft.

virtualbox-iso: Removing floppy drive...
==> virtualbox-iso: Error removing floppy: VBoxManage error: VBoxManage.exe: error: Failed to get a console object from the direct session (VBOX_E_INVALID_OBJECT_STATE)
==> virtualbox-iso: VBoxManage.exe: error: Details: code VBOX_E_VM_ERROR (0x80bb0003), component MachineWrap, interface IMachine, callee IUnknown
==> virtualbox-iso: VBoxManage.exe: error: Context: "LockMachine(a->session, LockType_Shared)" at line 326 of file VBoxManageStorageController.cpp

Gibt es eine Lösung dafür? Packer ist aus diesem Grund für mich zu 100% unbrauchbar. Ich habe versucht, die vbox-2012r2.json (oder eine beliebige Windows-VM) ab und zu zu erstellen, seit ich Packer im letzten Sommer entdeckt und das erste Mal etwa drei Tage lang versucht habe. Einige Monate später habe ich es erneut versucht und es gerade erst versucht wieder und es schlägt 100% der Zeit fehl. Es ist früher im Prozess mit einem anderen Fehler fehlgeschlagen, aber jetzt schlägt es mit diesem Fehler fehl, nachdem es das Gebäude durchlaufen hat und bereinigt wird.

Wenn es eine Problemumgehung gibt oder jemand anderes über einen gepatchten Build von Packer verfügt, der dies behebt, lassen Sie es mich bitte wissen, da ich Packer wirklich zum Erstellen meiner VMs verwenden möchte und ich nicht verstehe, wie andere es verwenden können, da es fehlschlägt 100% der Zeit für mich.

Am Ende habe ich ein Vorlagenbild erstellt und es von Hand syspreppen. Soviel zur Automatisierung ...

Ich weiß nicht genau warum, aber es scheint, dass das Setzen von shutdown_timeout auf 1h für mich funktioniert hat

@chocolatewheelchair Das ist ein toller Hinweis. Ein bisschen spekulieren, aber da dies nur bei Windows-Gästen passiert, kann es sein, dass Windows sehr langsam heruntergefahren wird und nicht innerhalb des Standardzeitlimits 5m Herunterfahren von

Es wäre fantastisch, wenn jemand, der dieses Problem bekommt, überprüfen kann, ob eine Erhöhung von shutdown_timeout um 1h zu sagen, dies löst?

Ich wäre sehr skeptisch, dass ein längeres shutdown_timeout dies wirklich beeinflusst, es sei denn, @chocolatewheelchair könnte bestätigen, dass dies dies über mehrere Versuche hinweg konsistent beeinflusst. Es sollte auch beachtet werden, dass es nicht auf Windows beschränkt ist, sowohl Mac- als auch Linux-Benutzer haben dies gemeldet. Das einzige, was ich gefunden habe, um dies konsequent zu beheben, ist kopflos (unabhängig vom Betriebssystem).

Ich habe ein shutdown_timeout = 15m. Und das Herunterfahren des Betriebssystems in 20 bis 30 Sekunden, maximal 1 m. Und das Problem tritt trotzdem in etwa 10% der Versuche auf. Das Frustrierendste ist, dass dieser Fehler am Ende des Gebäudes ausgelöst wird, sodass 3-4 Stunden Arbeit in Sekundenschnelle abgebrochen werden =)

@ rickard-von-essen @mwrock Ich habe es ungefähr ein halbes Dutzend Mal ausgeführt und es scheint zu funktionieren. Zugegeben, ein kleines Musterset.

@anuriq Du hast den frustrierendsten Teil erwähnt ... alles läuft gut, aber wenn du dies triffst, wird alles rückgängig gemacht, was bereits abgeschlossen ist.

@mwrock Es gibt nur Berichte über Probleme mit Windows-Gästen. Wenn Sie ein Problem mit einem anderen Gastbetriebssystem haben, fügen Sie hier Ihre Daten hinzu.

Hier gibt es nicht viel zu tun, der ursprüngliche Autor schlägt vor, dass dies in 0.8.1 festgelegt ist. Wenn dies jetzt jemand anderes sieht, schlage ich vor, shutdown_timeout auf etwas Großes ( 1h ) zu erhöhen und es erneut zu versuchen. Wenn Sie dies weiterhin reproduzieren können, fügen Sie bitte die folgenden Details hinzu: Host-Betriebssystem, Packer-Version, Gast-Betriebssystem, VirtualBox-Version, Auflistung Ihrer (minimierten) Vorlage und Skripte, die zum Builds erforderlich sind, sowie Auflistung Ihrer Protokolle, wenn Sie Packer mit env var PACKER_LOG=1 ausführen

richtig @ rickard-von-essen Ich bezog mich auf den Gastgeber. Entschuldigung für diese Verwirrung. Es ist definitiv nicht in 0.8.1 behoben

Und nur als Referenz: Meine Erfahrungen wurden mit Linux-Gastbetriebssystemen gemacht, nicht mit Windows.

@beporter Interessanterweise haben Sie eine Vorlage + Skripte für einen Linux-Build, in dem dies geschieht und den Sie

@ rickard-von-essen FWIW, keiner meiner Builds ist mit diesem speziellen Fehler mehr fehlgeschlagen, nachdem ich shutdown_timeout auf 1h geändert habe

Da ich kürzlich auf dieses Problem gestoßen bin, dachte ich, ich würde meine Beobachtungen hinzufügen.

Dies kam mir mehrmals vor mit:

• Packer v0.8.6
• Windows 7 Professional-Host

Das Gastbetriebssystem, auf dem es auftrat, war Debian Jessie, aber angesichts meiner Beobachtungen ist das wahrscheinlich nicht relevant.

Dieselbe Vorlage hatte ungefähr eine Stunde vor dem Auftreten des Fehlers funktioniert. Es ist dann mehrmals hintereinander mit demselben Fehler fehlgeschlagen. Andere auf Jessie basierende Vorlagen wurden im selben Zeitraum, in dem dieser Fehler auftrat, fehlerfrei erstellt. Andere Vorlagen, die auf CentOS 6, CentOS 7 und Ubuntu 14.04 basieren, wurden ebenfalls gleichzeitig fehlerfrei erstellt.

Die Fehler traten auf, während mehrere Packer-Builds gleichzeitig ausgeführt wurden. Ein nachfolgender Build, der dieselbe Vorlage verwendet, ohne dass andere Builds ausgeführt werden, führte dazu, dass der Build erfolgreich abgeschlossen wurde.

In meiner Vorlage wurde kein shutdown_timeout .

Ich vermute, dass es während des Herunterfahrens Situationen geben kann, in denen Virtualbox seine E / A-bezogenen Vorgänge nicht abgeschlossen hat, bevor Packer mit seinen Vorgängen fortfährt. Ich werde versuchen, dies mit mehreren gleichzeitig ausgeführten Packer-Builds zu testen. sowohl mit als auch ohne shutdown_timeout zu sehen, ob ich neu erstellen kann.

Unten ist die vollständige Fehlerausgabe:

==> virtualbox-iso: Gracefully halting virtual machine...
==> virtualbox-iso: Error detaching ISO: VBoxManage error: VBoxManage.exe: error: Failed to get a console object from the direct session (VBOX_E_INVALID_OBJECT_STATE)
==> virtualbox-iso: VBoxManage.exe: error: Details: code VBOX_E_VM_ERROR (0x80bb0003), component MachineWrap, interface IMachine, callee IUnknown
==> virtualbox-iso: VBoxManage.exe: error: Context: "LockMachine(a->session, LockType_Shared)" at line 326 of file VBoxManageStorageController.cpp
==> virtualbox-iso: Unregistering and deleting virtual machine...
==> virtualbox-iso: Deleting output directory...
Build 'virtualbox-iso' errored: Error detaching ISO: VBoxManage error: VBoxManage.exe: error: Failed to get a console object from the direct session (VBOX_E_INVALID_OBJECT_STATE)
VBoxManage.exe: error: Details: code VBOX_E_VM_ERROR (0x80bb0003), component MachineWrap, interface IMachine, callee IUnknown
VBoxManage.exe: error: Context: "LockMachine(a->session, LockType_Shared)" at line 326 of file VBoxManageStorageController.cpp

==> Some builds didn't complete successfully and had errors:
--> virtualbox-iso: Error detaching ISO: VBoxManage error: VBoxManage.exe: error: Failed to get a console object from the direct session (VBOX_E_INVALID_OBJECT_STATE)
VBoxManage.exe: error: Details: code VBOX_E_VM_ERROR (0x80bb0003), component MachineWrap, interface IMachine, callee IUnknown
VBoxManage.exe: error: Context: "LockMachine(a->session, LockType_Shared)" at line 326 of file VBoxManageStorageController.cpp

==> Builds finished but no artifacts were created.

Ein Update in Bezug auf meinen vorherigen Kommentar.

Meine obige Hypothese ist wahrscheinlich falsch.

Ich habe mehrere Stunden lang eine Reihe von gleichzeitigen Testbuilds ausgeführt. Der Fehler trat mit oder ohne shutdown_timeout auf, was sinnvoll ist, da ich vergessen hatte, dass dies standardmäßig bereits 5m .

Ich denke, in diesem Fall liegt das Problem nicht bei Packer, sondern nur beim Messenger. Daher kann aus Packer-Sicht nichts behoben werden, es sei denn, es gibt eine Möglichkeit, diesen VBox-Fehler ordnungsgemäß zu behandeln, z. B. abzufangen und erneut zu versuchen. Ich habe nicht geprüft, ob dies möglich wäre.

Ich habe mich auch nicht mit dem Virtualbox-Code befasst, um zu sehen, warum dieser Fehler ausgelöst wird, da er nur zeitweise auftritt.

Wenn dieser Fehler in Zukunft für mich problematisch wird, werde ich wahrscheinlich mehr Zeit damit verbringen, ihn zu untersuchen.

Dieser Fehler tritt immer noch auf, daher dachte ich, ich würde weitere Details hinzufügen.

Erstens scheint dies ein Problem mit VirtualBox zu sein. Packer ist hier nur der Bote.

Die gemeldeten Fehler befinden sich in dieser Datei: https://www.virtualbox.org/svn/vbox/trunk/src/VBox/Frontends/VBoxManage/VBoxManageStorageController.cpp

Mein Fehler war in Zeile 326. Andere haben Zeile 325 gemeldet. Der fragliche Codeblock lautet:

    // find the machine, lock it, get the mutable session machine
    CHECK_ERROR_RET(a->virtualBox, FindMachine(Bstr(a->argv[0]).raw(),
                                               machine.asOutParam()), RTEXITCODE_FAILURE);
    CHECK_ERROR_RET(machine, LockMachine(a->session, LockType_Shared), RTEXITCODE_FAILURE);
    SessionType_T st;
    CHECK_ERROR_RET(a->session, COMGETTER(Type)(&st), RTEXITCODE_FAILURE);
    a->session->COMGETTER(Machine)(machine.asOutParam());

L325 ist das erste CHECK_ERROR_RET dem es sich um einen Fehler beim Auffinden der Maschine handelt.
L325 ist das zweite CHECK_ERROR_RET dem es sich um einen Fehler beim Sperren der Maschine handelt.

Der ursprünglich gemeldete Fehler war auf L1011, wenn VirtualBox den Status eines Speichercontrollers erhält. Das stimmt mit dieser Fehlermeldung überein.

Für den letzten Fehler frage ich mich, ob es ein Parallelitätsproblem gibt, das dies verursacht, dh eine andere Go-Routine hat es gesperrt. Bitte beachten Sie, dass dies eine spekulative Frage ist.

Pfui. Schlagen Sie dies einfach noch

Nur ein weiterer Kommentar, um zu sagen, dass mir das auch passiert ist. Erstellen Sie Windows Server 2012 R2 unter Win 7 Professional.
Ich habe zu headless = true und shutdown_timeout = 60m gewechselt
und dann hat es funktioniert.

Ich sehe dieses Problem auch sporadisch. Ich versuche headless=true zu sehen, ob das hilft.

Host: Windows 2012 R2
VM: Windows 2012 R2
Packer 0.8.6
VirtualBox 5.0.8

FWIW, ich habe dieses Problem mit 100% iger Konsistenz unter Verwendung von mwrock / packer -templates @ eea6e05fa27b5089222de0194ba3fc444be1a117.

Mein Build läuft jedoch ohne Probleme ab, wenn ich headless=true setze. Die Erweiterung des Wertes von shutdown_timeout hatte für mich keinen positiven Effekt.

Für Wohlstand sind hier meine Build-Spezifikationen:

Host: Linux Mint 17.3 Rosa (x64)
VM: mwrock / packer- Vorlagen: Windows 2012R2
Packer: 0,10,0
VirtualBox: 5.0.8

Ich fürchte, ich muss mich der Party anschließen. Denken Sie nicht, dass shutdown_timeout hier eine Rolle spielt, da der Packer anscheinend zu früh denkt, dass das Herunterfahren bereits abgeschlossen ist.

Ja, unabhängig davon, wie lange das Timeout dauert. Sobald der Packer glaubt, dass der Gast heruntergefahren ist, beginnt er mit dem Entfernen. Nachdem ich mich viel mit diesem Fehler befasst habe, bin ich zuversichtlich, dass das Laufen ohne Kopf die Chancen dafür verringert, aber keine Garantie darstellt.

@mwrock Ist es möglich, dieses Headless auszuführen, um die VM zu generieren, und dann Headless auf false zu setzen?

Sie können jederzeit eine Vorlagenvariable verwenden, die den Standardwert auf true setzt und im CLI-Erstellungsbefehl auf false überschreibt.

Ich bin auf dieses Problem gestoßen und habe shutdown_timeout auf 1h . Problem für mich gelöst. Dieses Problem trat garantiert bei mir auf. Hoffentlich wird das Problem dadurch behoben, und ich sehe es nicht wieder. Es ist wirklich frustrierend, ein paar Stunden damit zu verbringen, ein Bild zu erstellen und alle Artefakte zerstören zu lassen.

Paar Notizen;
Packer v0.8.6
virtualbox v5.1.4r110228

Hatte gerade auch das Problem.

Gleiche Frustration.

Packer: 0.10.1
Host: Linux Mint 17.3
Gast: Windows 2012R2.

Ich habe auch dieses Problem, und es scheint regelmäßig aufzutreten.

Packer v0.10.1
Host: Windows 10 Professional
Gast: Windows 2012R2

Ich werde versuchen, kopflos zu laufen

Gerade erfolgreich abgeschlossen, indem auf kopflose ...

Versuchte den shutdown_timeout Trick, keine Würfel.

Beim Versuch, die Nano-Box von @mwrock unter Windows 10 Pro, Packer v0.10.1, VirtualBox 5.1.6 zu erstellen, wird dieselbe Version ausgeführt.

Unter Windows, bei dem Windows Server-Images erstellt wurden, trat dieses Problem ein halbes Dutzend Mal auf, ohne dass @mwrock- Packer-Vorlagen zum

Scheint den Trick gemacht zu haben, da ich noch nie so weit gekommen bin.

Bisher habe ich nur negative Beweise, aber die Pull-Anfrage, die ich gerade erstellt habe, scheint zu helfen. Ich habe modifizierte @ mwrock- Vorlagen erstellt. Ich habe den Fehler letzte Woche immer wieder gesehen, und seit ich das Update an diesem Wochenende erstellt und meinen geänderten Code ausgeführt habe, habe ich den Fehler nicht gesehen. Bisher nur unter OSX getestet. Ich werde Ubuntu ausprobieren, wenn es die Zeit erlaubt.

Ich bin auf dasselbe Problem gestoßen, und dies tritt nur für den VirtualBox-Builder auf, während mit Qemu alles einwandfrei funktioniert. Ich bin auf einem NixOS Linux-Host, der Windows 8 erstellt, und wenn headless = false ist , kann Packer den Floppy-Controller nicht 100% der Fälle entfernen, während durch Drehen von headless = true der Floppy-Controller erfolgreich entfernt wird und alles ordnungsgemäß funktioniert. Das ist wirklich ärgerlich und wir sollten es so schnell wie möglich lösen.

Verwenden von VirtualBox 5.1.6 .

Bitte testen Sie # 3952

Hallo zusammen

Ich habe noch etwas hinzuzufügen, von dem ich hoffe, dass es Ihnen allen hilft: o)

Gestern habe ich mein VirtualBox-Image ungefähr drei- oder viermal erfolgreich neu erstellt und dann einige Dinge optimiert, um dann das Problem "Fehler beim Entfernen der Diskette" zu beheben. Ich habe alle meine letzten Änderungen rückgängig gemacht, aber nichts hat geholfen. Ich habe sogar VirtualBox, Packer und Chocolatey deinstalliert, um sie dann alle neu zu installieren, aber der nächste Build ist immer noch fehlgeschlagen.

Heute Morgen wurde mir klar, dass das einzige andere, was ich von einem funktionierenden Build in diesen fehlerhaften Zustand geändert hatte, ... die Menge an Speicher war, die Packer dem VM-Image zugewiesen hatte!

Ich hatte gut mit 2048 MB (2 GB) gearbeitet, aber beschlossen, es auf 6144 MB (6 GB) zu erhöhen, um zu sehen, ob die Dinge schneller / besser funktionierten. Heute Morgen habe ich es wieder auf 2 GB reduziert und ... der Build funktioniert jetzt wie zuvor!

Es wäre interessant zu sehen, ob einer von euch eine ähnliche Änderung vornehmen und daraus ein positives Ergebnis erzielen kann.

Hoffe, das hilft, dem Problem auf den Grund zu gehen (es sei denn, es ist tatsächlich VirtualBox und sowieso nicht Packer :))

Andy

Dies ist definitiv ein VirtualBox-Problem, siehe https://www.virtualbox.org/ticket/16063

Vielen Dank, dass Sie den Upstream überprüft haben. Nach dem Lesen der VirtualBox-Tickets klingt es nach einem erneuten Versuch, den https://github.com/mitchellh/packer/pull/3952#issuecomment -251197612 vorgeschlagen hat, um dies zu beheben. Wenn ich an diesem Wochenende genug Zeit herausholen kann, werde ich sehen, ob ich es bauen kann.

Treffen Sie dies heute dreimal mit Packer 0.12.0 unter macOS 10.11 (El Cap) und VirtualBox 5.1.10 mit einem Win 2012 R2-Servergast. Der vierte Versuch hat funktioniert.

@bsberry hast du versucht, die post_shutdown_delay erhöhen? Wenn ja, öffnen Sie bitte eine neue Ausgabe

Danke für die schnelle Antwort. Aus der Diskussion im anderen Thread ging nicht hervor, dass Sie selbst unter 0.12.0 einen Parameter anpassen müssen, damit er funktioniert. Fügt post_shutdown_delay zu zukünftigen VirtualBox-Packer-Builds von Windows-Gästen hinzu.

Der Standardwert ist 30s, der möglicherweise erhöht werden muss

Klingt so, als wäre es die Mühe wert, die Idee eines erneuten Versuchs zu überdenken.
Ich werde sehen, ob ich das bis Ende des Jahres einbauen kann.

Am Mittwoch, 30. November 2016, um 13:19 Uhr, Matthew Hooker [email protected]
schrieb:

Der Standardwert ist 30s, der möglicherweise erhöht werden muss

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/mitchellh/packer/issues/2401#issuecomment-263967537 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AAE4_ri6iSgiuKdj4aPX6jJ0DSdzUTPPks5rDcw5gaJpZM4FTWsV
.

- -

Am besten, Mike

Blog http://mikestankavich.com
LinkedIn http://linkedin.com/in/mikestankavich
Facebook http://facebook.com/mike.stankavich
Twitter http://twitter.com/#!/mikestankavich
* Skype * MikeStankavich

Wenn Sie dies erneut treffen, diesmal auf dem Windows Server 2016-Host und dem Win10-Gast.

      "post_shutdown_delay": "180s",
      "shutdown_timeout": "1h",

im Builder virtualbox-iso hilft das nicht.

Ich sehe auch dieses Problem. Dies ist mit Packer 0.12.1 und VirtualBox 5.1.12 unter Arch Linux möglich.

==> virtualbox-iso: Gracefully halting virtual machine...
    virtualbox-iso: Removing floppy drive...
==> virtualbox-iso: Error removing floppy controller: VBoxManage error: VBoxManage: error: The machine 'packer-virtualbox-iso-1484873439' is already locked for a session (or being unlocked)
==> virtualbox-iso: VBoxManage: error: Details: code VBOX_E_INVALID_OBJECT_STATE (0x80bb0007), component MachineWrap, interface IMachine, callee nsISupports
==> virtualbox-iso: VBoxManage: error: Context: "LockMachine(a->session, LockType_Write)" at line 1038 of file VBoxManageStorageController.cpp
==> virtualbox-iso: Unregistering and deleting virtual machine...
==> virtualbox-iso: Deleting output directory...
Build 'virtualbox-iso' errored: Error removing floppy controller: VBoxManage error: VBoxManage: error: The machine 'packer-virtualbox-iso-1484873439' is already locked for a session (or being unlocked)
VBoxManage: error: Details: code VBOX_E_INVALID_OBJECT_STATE (0x80bb0007), component MachineWrap, interface IMachine, callee nsISupports
VBoxManage: error: Context: "LockMachine(a->session, LockType_Write)" at line 1038 of file VBoxManageStorageController.cpp

==> Some builds didn't complete successfully and had errors:
--> virtualbox-iso: Error removing floppy controller: VBoxManage error: VBoxManage: error: The machine 'packer-virtualbox-iso-1484873439' is already locked for a session (or being unlocked)
VBoxManage: error: Details: code VBOX_E_INVALID_OBJECT_STATE (0x80bb0007), component MachineWrap, interface IMachine, callee nsISupports
VBoxManage: error: Context: "LockMachine(a->session, LockType_Write)" at line 1038 of file VBoxManageStorageController.cpp

==> Builds finished but no artifacts were created.

Ich habe eine neue Ausgabe geöffnet, um diese Fehler zu verfolgen. Siehe # 4432

Hat hier jemand genau einen Fehler behoben?

Ich verwende OSX 10.12.3
dude1 $ packer -v
0.12.2

Dude $ Packer Build -force -nur Virtualbox-ISO Eval-Win7x64-Enterprise-Cygwin.json

Oracle VM VirtualBox Manager 5.1.14

Ich bin heute auf dasselbe Problem gestoßen, und dieses Problem ist immer noch ein Top-Ergebnis. Aus meinen Tests geht hervor, dass die Verzögerung nicht die magische Lösung ist, auf die die Leute gehofft hatten, aber mit -var 'headless=true' funktioniert sie zuverlässiger.

Unten finden Sie eine Zusammenfassung meiner Debugging-Schritte beim Versuch, den fehlgeschlagenen Build einer Windows / Win10x86-Enterprise- und Windows / Win2012r2-Standardbox von Boxcutter / Windows zu debuggen

• Ubuntu 16.10
• VirtualBox 5.1.16
• Packer 0.12.2

Beschlossen, einen der oben genannten Vorschläge zu versuchen, der sich auf den headless -Modus bezieht und einen post_shutdown_delay .

Win2012: Timeout-Test: -var "post_shutdown_delay=30s zu Makefile -var "post_shutdown_delay=30s hinzugefügt - fehlgeschlagen - Diskette kann vor dem Aufblasen nicht entfernt werden.

Win 10: Headless-Test: HEADLESS=true make virtualbox/eval-win10x86-enterprise - fehlgeschlagen - Entfernen Sie das Diskettenlaufwerk und sprengen Sie dann den Export der virtuellen Maschine.

Diese Explosion führte zu mehr Suche und ich fand einen Ubuntu-Benutzer, der Probleme beim Exportieren mit betrügerischen Virtualbox-Prozessen meldete .

Fahren Sie alle meine Virtualbox-Inhalte herunter und überprüfen Sie, ob noch Prozesse vorhanden sind: ps -Aef | grep virtualbox - es gab also getötete und kehrte zum Win2012-Combo-Test zurück: kopflos mit 30s Verzögerung

Win2012: Headless-Test: HEADLESS=true make virtualbox/eval-win2012r2-standard - funktioniert - Der Headless-Modus verursachte meinen ersten erfolgreichen Packer-Build einer Windows-VM.

Nachdem ich diese Arbeit erledigt hatte, entschied ich mich, Win 10 ohne besondere Verzögerung und im Anzeigemodus zu versuchen, dem Standard-Setup, das ich ursprünglich versucht hatte, aber mit einem Vorüberprüfungsschritt wurden keine unerwünschten Virtualbox-Prozesse ausgeführt, bevor der Build gestartet wurde.

Win 10: Standardtest mit sauberer Umgebung: make virtualbox/eval-win10x86-enterprise - fehlgeschlagen

Also rollte ich zurück und machte wieder Win 10

Gewinn 10: kopflos und ohne Verzögerung: HEADLESS=true make virtualbox/eval-win10x86-enterprise - funktioniert .

Während des Debuggens stieß ich auf einen großartigen Blog-Beitrag mit Best Practices für Packer und Windows von @matthodge, der es so zusammenfasste: _ "Wenn Sie den VirtualBox-Builder verwenden, verwenden Sie viel weniger Fehler im Headless-Modus." _

Abschließender Folgetest nach Aufforderung von m zu verlängern:

Win 10: Standardmodus mit -var "post_shutdown_delay=2m" : make virtualbox/eval-win10x86-enterprise - funktioniert

@dayne danke für die Info, das ist interessant. Ich frage mich, ob Sie noch einmal testen wollten, ob es funktionieren würde, etwas wie post_shutdown_delay=2m und mit headless = false zu laufen. Ich werde es auch mit den Boxcutter-Boxen versuchen und sehen, ob ich reproduzieren kann. Ich arbeite diese Woche daran und verfolge hier # 4432

@mwhooker - Ich bin zurückgegangen und habe das headless=true mit einem post_shutdown_delay=2m ausprobiert und es hat funktioniert. Eine längere Verzögerung als 30 Sekunden hat es geschafft. Vielen Dank, dass ich das überprüft habe - eine längere Verzögerung ist eine praktikable Option für eine Installation unter Linux, wie es scheint.

Ich wollte nur bestätigen, dass dieses Problem weiterhin mit packer 1.4.6 , vagrant 2.2.6 und virtualbox 6.0-r14

Ich kann reproduziert werden, indem ich headless:false ausschalte. Das Hinzufügen von post_shutdown_delay:2m behebt das Problem, während der Headless-Modus noch deaktiviert ist.

Die Verwendung von headless:true behebt die Probleme auch ohne zusätzliche Parameter.

Der Build-Host ist ein 32 GB, i7, nvme SSD-Host, daher ist diesbezüglich nichts zu langsam.

Dies ist ein ziemlich altes Problem. Wenn Sie mit etwas mit ähnlichen Symptomen konfrontiert sind, besteht eine gute Chance, dass es neu ist. Können Sie bitte eine neue Ausgabe mit vollständigen Schritten zur Reproduktion öffnen?

Ich werde dieses Problem sperren, da es seit 30 Tagen geschlossen ist. Dies hilft unseren Betreuern, die aktiven Themen zu finden und sich darauf zu konzentrieren.

Wenn Sie ein ähnliches Problem gefunden haben, öffnen Sie bitte ein neues Problem und vervollständigen Sie die Problemvorlage, damit wir alle Details erfassen können, die zur weiteren Untersuchung erforderlich sind.