Packer v1.3.5
Arch Linux
Debug log output from PACKER_LOG=1 packer build template.json
.
https://gist.github.com/dkrm0/f7846d927854bff04def545d716bbe05
The _simplest example template and scripts_ needed to reproduce the bug.
Included in the gist.
What's odd is that, if I run vagrant package
on its own, it managed to build the box successfully.
Thanks for opening this. I don't have any bright ideas this second, but I see a couple things worth noting in your logs:
2019/03/28 18:50:18 packer: 2019/03/28 18:50:18 Calling Vagrant CLI: []string{"package", "--output", "/home/dkrm/dev/packer-demo/builder-vagrant/box/package.box"}
2019/03/28 18:50:33 packer: 2019/03/28 18:50:33 [vagrant driver] stdout: ==> default: Packaging domain...
2019/03/28 18:50:33 packer: ==> default: Image has backing image, copying image and rebasing ...
2019/03/28 18:50:33 packer: 2019/03/28 18:50:33 [vagrant driver] stderr: qemu-img: Could not open '/home/dkrm/vms/libvirt/box_default.img': Failed to get shared "write" lock
2019/03/28 18:50:33 packer: Is another process using the image [/home/dkrm/vms/libvirt/box_default.img]?
2019/03/28 18:50:33 packer: Total bytes written: 227020800 (217MiB, 32MiB/s)
2019/03/28 18:50:33 packer: /usr/lib/ruby/2.6.0/fileutils.rb:529:in `rename': No such file or directory @ rb_file_s_rename - (/home/dkrm/dev/packer-demo/builder-vagrant/_tmp_package//home/dkrm/dev/packer-demo/builder-vagrant/box/package.box, ..//home/dkrm/dev/packer-demo/builder-vagrant/box/package.box) (Errno::ENOENT)
2019/03/28 18:50:33 packer:
Worth noting the // in the filename and the fact that it looks like a base path has been concatenated to another absolute path. Also that there's an issue earlier up with a lockfile.
I'll try to get a repro case going tomorrow or next week.
Just updating -- I can reproduce and I'm looking into the source of this bug.
Found it. This is due to an upstream bug with the vagrant libvirt provider-- https://github.com/vagrant-libvirt/vagrant-libvirt/issues/765
I've written a workaround that changes Packer's working directory to the output dir so we don't have to pass it, which I'll revert once the upstream bug is resolved.
The PR for the workaround is linked above; once builds pass, you can find a binary of that branch from our circle ci build here
Thank you, it works perfectly. :)
Btw, also thank you for this video. That's what brought me to discover this feature.
I'm going to lock this issue because it has been closed for _30 days_ โณ. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Most helpful comment
Thank you, it works perfectly. :)
Btw, also thank you for this video. That's what brought me to discover this feature.