Packer+aws recursive directory provisioner and too many links

[ra-dft]

debian 8.1 AMI

packer # ./packer version
Packer v0.10.2

amazon-ebs output will be in this color.

==> amazon-ebs: Prevalidating AMI Name...
==> amazon-ebs: Inspecting the source AMI...
==> amazon-ebs: Creating temporary keypair: *****************
==> amazon-ebs: Launching a source AWS instance...
amazon-ebs: Instance ID: i-56ded340
==> amazon-ebs: Waiting for instance (i-56ded340) to become ready...
==> amazon-ebs: Waiting for SSH to become available...
==> amazon-ebs: Connected to SSH!
==> amazon-ebs: Provisioning with shell script: /root/aws/packer/apiUserData
amazon-ebs: sudo: unable to resolve host pdsp-api1-aws
amazon-ebs: sudo: unable to resolve host pdsp-api1-aws
amazon-ebs: sudo: unable to resolve host pdsp-api1-aws
==> amazon-ebs: Uploading /opt/salt_files => /opt/salt_files
==> amazon-ebs: Terminating the source AWS instance...
==> amazon-ebs: No AMIs to cleanup
==> amazon-ebs: Deleting temporary keypair...
Build 'amazon-ebs' errored: EvalSymlinks: too many links

==> Some builds didn't complete successfully and had errors:
--> amazon-ebs: EvalSymlinks: too many links

==> Builds finished but no artifacts were created.

I'm not sure if this is related at all to similar issues experienced with docker+packer(issue 1628 from 2015?) or if I'm doing something wrong.

1628

[ra-dft]

Now what I'm not %100 certain is if it's failing on the recursive copy of /opt/salt_files or if it's failing on the next provisioner "salt-masterless" and copying the saltstack tree to the remote ami.

/opt/salt_files only has 13 symlinks.

[mwhooker]

If you can post a minimal packer file that reproduces it, we can try to diagnose this.

[ra-dft]

{
  "variables": {
    "region": "us-east-1",
    "ami_id": "****",
    "instance_type": "t2.micro",
    "build_number": "{{ env `BUILD_NUMBER` }}"
  },
  "builders": [
    {
      "type": "amazon-ebs",
      "region": "{{ user `region` }}",
      "source_ami": "{{ user `ami_id` }}",
      "instance_type": "{{ user `instance_type` }}",
      "ssh_username": "admin",
      "vpc_id": "***",
      "subnet_id": "****",
      "security_group_id": "****",
      "associate_public_ip_address": "1",
      "user_data_file": "{{ pwd }}/apiUserData",
      "ami_name": "api_base.amzn.{{ isotime \"20060102\" }}.{{ user `build_number` }}"
    }
  ],
  "provisioners": [
    {
      "type": "shell",
      "script": "{{ pwd }}/apiUserData"
    },
    {
      "type": "file",
      "source": "/opt/salt_files",
      "destination": "/opt/salt_files"
    },
    {
      "type": "salt-masterless",
      "local_state_tree": "/srv/salt_tree/salt/base"
    }
  ],
  "description": "Builds a base image for Amazon Linux",
  "min_packer_version": "0.10.1",
  "post-processors": null
}

[ra-dft]

I removed the salt-masterless provisioner from the template and I'm still running into the issue after the file provisioner runs.

[ra-dft]

I may have found my issue and it might not really be a bug. Looks like there are couple symlinks to directories outside of the /opt/salt_files the the problem. I've narrowed my file provisioner down to a more specific sub-tree of /opt/salt_files and seem to be winning here.

[mwhooker]

oh interesting. good catch. Safe to close this?

[ra-dft]

@mwhooker Sorry for the late reply but yes this was probably more pebcak than bug.

[mwhooker]

@ra-dft lol, don't worry about it. thanks for closing the loop!