Packer: Packer crash when registering AMI: unexpected EOF / panic makeslice: cap out of range

[mlitvin]

packer 1.0.2 (run from the official docker image),

building using amazon-ebssurrogate,
the build itself seems to succeed but it errors when attempting to register AMI:

==> amazon-ebssurrogate: Registering the AMI...
2017/06/23 10:13:01 ui: ==> amazon-ebssurrogate: Registering the AMI...
2017/06/23 10:13:01 ui: ==> amazon-ebssurrogate: Terminating the source AWS instance...
==> amazon-ebssurrogate: Terminating the source AWS instance...
2017/06/23 10:13:02 packer: 2017/06/23 10:13:02 Waiting for state to become: terminated
2017/06/23 10:13:02 packer: 2017/06/23 10:13:02 Using 2s as polling delay (change with AWS_POLL_DELAY_SECONDS)
2017/06/23 10:13:02 packer: 2017/06/23 10:13:02 Allowing 300s to complete (change with AWS_TIMEOUT_SECONDS)
2017/06/23 10:13:08 ui: ==> amazon-ebssurrogate: Deleting temporary security group...
==> amazon-ebssurrogate: Deleting temporary security group...
2017/06/23 10:13:08 ui: ==> amazon-ebssurrogate: Deleting temporary keypair...
==> amazon-ebssurrogate: Deleting temporary keypair...
2017/06/23 10:13:08 packer: Build 'amazon-ebssurrogate' errored: unexpected EOF

==> Some builds didn't complete successfully and had errors:
--> amazon-ebssurrogate: unexpected EOF

==> Builds finished but no artifacts were created.
panic: runtime error: makeslice: cap out of range
2017/06/23 10:13:08 packer:
2017/06/23 10:13:08 packer: goroutine 30 [running]:
2017/06/23 10:13:08 packer: github.com/hashicorp/packer/builder/amazon/ebssurrogate.(*StepRegisterAMI).Run(0xc420249d50, 0x22b0740, 0xc4202b48a0, 0x0)
2017/06/23 10:13:08 packer:     /Users/mwhooker/go/src/github.com/hashicorp/packer/builder/amazon/ebssurrogate/step_register_ami.go:28 +0x1ea
2017/06/23 10:13:08 packer: github.com/hashicorp/packer/vendor/github.com/mitchellh/multistep.(*BasicRunner).Run(0xc4202b0880, 0x22b0740, 0xc4202b48a0)
2017/06/23 10:13:08 packer:     /Users/mwhooker/go/src/github.com/hashicorp/packer/vendor/github.com/mitchellh/multistep/basic_runner.go:70 +0x1e2
2017/06/23 10:13:08 packer: github.com/hashicorp/packer/builder/amazon/ebssurrogate.(*Builder).Run(0xc42025c000, 0x22b3420, 0xc4202b2560, 0x22ab3c0, 0xc4202ac4d0, 0x22b1e80, 0xc420066260, 0xc4202b40c0, 0x0, 0xc420016d20, ...)
2017/06/23 10:13:08 packer:     /Users/mwhooker/go/src/github.com/hashicorp/packer/builder/amazon/ebssurrogate/builder.go:236 +0x1611
2017/06/23 10:13:08 packer: github.com/hashicorp/packer/packer/rpc.(*BuilderServer).Run(0xc42000b140, 0x1, 0xc4202ac430, 0x0, 0x0)
2017/06/23 10:13:08 packer:     /Users/mwhooker/go/src/github.com/hashicorp/packer/packer/rpc/builder.go:93 +0x1ea
2017/06/23 10:13:08 packer: reflect.Value.call(0xc420016d20, 0xc42000c0f0, 0x13, 0x18de246, 0x4, 0xc4202a5f20, 0x3, 0x3, 0xc4202dbce0, 0x0, ...)
2017/06/23 10:13:08 packer:     /usr/local/Cellar/go/1.8.3/libexec/src/reflect/value.go:434 +0x91f
2017/06/23 10:13:08 packer: reflect.Value.Call(0xc420016d20, 0xc42000c0f0, 0x13, 0xc42031ef20, 0x3, 0x3, 0xc42031ef60, 0x70ecf3, 0x154dd80)
2017/06/23 10:13:08 packer:     /usr/local/Cellar/go/1.8.3/libexec/src/reflect/value.go:302 +0xa4
2017/06/23 10:13:08 packer: net/rpc.(*service).call(0xc420018800, 0xc4200187c0, 0xc420012980, 0xc420128800, 0xc42000b860, 0x15575c0, 0xc4202ac42c, 0x18a, 0x1523860, 0xc4202ac430, ...)
2017/06/23 10:13:08 packer:     /usr/local/Cellar/go/1.8.3/libexec/src/net/rpc/server.go:387 +0x144
2017/06/23 10:13:08 packer: created by net/rpc.(*Server).ServeCodec
2017/06/23 10:13:08 packer:     /usr/local/Cellar/go/1.8.3/libexec/src/net/rpc/server.go:481 +0x404```

Full log and template/script can be found in https://gist.github.com/mlitvin/653fdcbf89e3b09c1560f3cacab9fc30

[mwhooker]

Thanks for the report. Does this work with any prior versions of packer?

[mlitvin2]

It happens also with v1.0.1. It doesn't happen with v1.0.0 (where it seems that it tries to register the wrong snap short and fails)

2017/06/24 07:48:21 ui: ==> amazon-ebssurrogate: Creating snapshot of EBS Volume vol-0087822cd2f6a4df4...
==> amazon-ebssurrogate: Creating snapshot of EBS Volume vol-0087822cd2f6a4df4...
2017/06/24 07:48:21 ui:     amazon-ebssurrogate: Snapshot ID: snap-030eca704de0f27e8
    amazon-ebssurrogate: Snapshot ID: snap-030eca704de0f27e8
2017/06/24 07:48:21 packer: 2017/06/24 07:48:21 Waiting for state to become: completed
2017/06/24 07:48:21 packer: 2017/06/24 07:48:21 Using 2s as polling delay (change with AWS_POLL_DELAY_SECONDS)
2017/06/24 07:48:21 packer: 2017/06/24 07:48:21 Allowing 300s to complete (change with AWS_TIMEOUT_SECONDS)
2017/06/24 07:49:42 ui: ==> amazon-ebssurrogate: Registering the AMI...
==> amazon-ebssurrogate: Registering the AMI...
2017/06/24 07:49:42 ui error: ==> amazon-ebssurrogate: Error registering AMI: InvalidParameterValue: Invalid value 'snap-0c4a519de2042999b' for snapshotId. Snapshot does not belong to XXXX

Note that the snapshot it take is different from the one that gives an error (but remember this is 1.0.0)

[athak]

This just bit us too. It seems to work with 0.12.3. Has anybody identified any workarounds?

[SwampDragons]

@athak I think you should be able work around it by adding the root device to "ami_block_device_mappings" in your template. e.g. if your root device is

"ami_root_device": { "source_device_name": "/dev/xvdg", "device_name": "/dev/xvda", "delete_on_termination": true, "volume_type": "gp2" },

You can add

"ami_block_device_mappings": [{ "device_name": "/dev/xvda", "delete_on_termination": true, "volume_type": "gp2" }]

[athak]

@SwampDragons thanks for the tip. Regrettably it fails with:

Build 'amazon-ebssurrogate' errored: Error registering AMI: InvalidBlockDeviceMapping: /dev/xvda is being assigned to multiple times.
        status code: 400, request id: 4cae8c0c-7fbf-42dc-8e69-19a3fe57a6e3

We'll use 0.12.3 for this build for now until the fix is merged.

[SwampDragons]

I think this should be resolved in https://github.com/hashicorp/packer/pull/5059 -- @mlitvin are you able to build with that patch and tell me whether it solves your issue?

[mlitvin]

Yes, it solve my issue. Thanks

[hashibot[bot]]

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.