How to make EC2 user-data work on freshly built AMI, made with Packer

Julian Simpson picture Julian Simpson · Aug 26, 2014 · Viewed 8.2k times · Source

I can build AMI images just fine. But they've stopped working with EC2 User Data:

There is user data:

$ cat /tmp/user_data.sh
#!/bin/bash

touch /tmp/i_have_user_data /root/i_have_user_data

And I can launch a plain Ubuntu image:

aws ec2 run-instances --instance-type m3.medium --image-id ami-eed10e86 --user-data file:///tmp/user_data.sh

And it works:

ubuntu@ip-10-165-90-180:~$ ls /tmp/i_have_user_data

/tmp/i_have_user_data

But if I build an AMI based on that one, with Packer:

"builders": [
    {
        "type": "amazon-ebs",
        "region": "us-east-1",
        "source_ami": "ami-eed10e86",
        "instance_type": "m3.large",
        "ssh_username": "ubuntu",
        "tags": {
            "OS_Version": "Ubuntu",
            "Release": "LTS"
        }
    }
],

... and run that the very same way as before, there's nothing in /tmp. However, it's clear that there is user data if you run ec2metadata:

ramdisk-id: unavailable
reserveration-id: unavailable
security-groups: default
user-data: #!/bin/bash

touch /tmp/i_have_user_data /root/i_have_user_data

I'm pretty sure it's a state issue and that removing a statefile is going to make it all magically work. Or, there's a trick to make the cloud-final upstart script work, which might be what's broken. Anyway, I haven't found that yet.

Update:

I made it work by turning the user-data script into a boothook:

#cloud-boothook
#!/bin/sh
echo "RUNNING USER DATA SCRIPT"

Still looking for an explanation for why they stopped working. Cloud Init's docs are getting better, but there's still a way to go.

Answer

Ken Brittain picture Ken Brittain · Aug 18, 2015

Packer creates your image then takes a snapshot before making the AMI. This is your first boot. At this point you would need to boot the instance, which according to Ubuntu, would clean the /tmp directory.

I would try putting the file elsewhere and see if it persists.

The #cloud-boothook runs every time, given the docs that state you responsible for disabling it.