After investigation based on your suggestion, I found out that there isn't
the temporary SSH key uploaded in the ~/.ssh/authorized_keys, hence it
makes sense why it's not connected. There is only my key, which is there
because I used it when creating the base image. Hence, it explains why
hello
not enough information i am afraid.
Can you share a copy of your files in a github repo for review?
Thanks
Alvaro.
On Mon, Oct 10, 2016 at 8:22 PM, Siva Abbannagari <
siva.abbannag...@gmail.com> wrote:
> I am trying to build an vmware appliance with packer.
>
> I have a base vmx file
On Mon, Oct 10, 2016 at 7:48 PM, Gonzo Fernandez
wrote:
> d-i partman-lvm/device_remove_lvm boolean true
> d-i partman-auto/choose_recipe select atomic
>
no sure whats different
but can you try once with this preseed?
Hello
On the github code there is a new post-processor called manifest:
https://github.com/mitchellh/packer/blob/d310de8cf5871354bd1d12996a87020803d373ea/website/source/docs/post-processors/manifest.html.md
is not yet on the build I think, so you should try to build from the source
with make dev
That sounds very reasonable. There should be some logs for cloudbase-init.
Review them an you will most likely get a step closer to solve this.
On 11 October 2016 at 17:30, wrote:
> After investigation based on your suggestion, I found out that there isn't
> the temporary
Ah, OK. I was using multiple virtualbox-iso builders, running a variety of
provisioners to customize the images with various packages and config
files, then sending them to a single amazon-import post-processor... which
then turned into multiple amazon-import post-processors because we now have
Hi Alvaro, I’ll give it a try with your preseed.cfg.
Something strange is happening here. I changed up the pre-seed file with this
one (notice the red text):
```
# Some inspiration:
# *
https://github.com/chrisroberts/vagrant-boxes/blob/master/definitions/precise-64/preseed.cfg
# *
Hello
As usual, you are free to use the tool in the best way that helps in your
workflow. :)
But generally speaking, the idea was to have something like this:
builder
virtualbox-iso
vmware-iso
provisioner
common_to_both
only: virtualbox-iso something_only_for_virtualbox (ie vbox
So I did some more research and it looks like I can import the .ova file that
gets created and you’re right, the OS does create root ( / ) of 38GB’s with the
rest being used in boot/swap.
I think I might have found what the issue was. It looks like my packer-cache
was pointing to an old VMDK
Then I would sugest you use Consul. Either you run one cluster per env or:
That your ami/image has a (cloud-)init script thats detects which
environment by inspecting the account/project/vpc/subnet to determine which
env the instance is launched in and makes that info available to all apps.
Which
hello
i did build the base one.
template say 40gb, it does create a LVM with / of 38gb, being 2gb used in
boot/swap
so, it did work for me.
packer 0.10.2
can we go back a bit on what you expect to have that is not working?
Thanks
Alvaro.
On Tue, Oct 11, 2016 at 8:23 PM, Gonzo Fernandez
hello
no that I am aware of.
The idea of having multiple builders is all of those will end with the
same machine, so should be 1 machine per template.
imagine you have virtualbox, vmware and aws.
by default those will run in parallel
so the options are, no-parallel, or --only aws
but not
For example, would it be possible to pass the AMI ID that's created by an
amazon-import post-processor to local shell post-processor? Something like
this:
{ "post-processors":
[
{
"type": "amazon-import",
...
},
{
"type": "shell-local",
"inline":
13 matches
Mail list logo