When launching a VM instance from a pre-created AMI (based off official freebsd ami image), it's not possible to pass EC2 User-data to the VM for further configuration. This is not something one expects to see on AWS since it contradicts the behaviour of virtually all other AMIs we tried (Ubuntu, Amazon Linux, Debian to name a few).
The proposed solution is to either remove the KEYWORD: firstboot from ec2_configinit script, or make this behaviour configurable.
How are you creating your AMI? If it has the /firstboot sentinel file, configinit will run.
I'm using Packer (https://www.packer.io/docs/builders/amazon-ebs.html).
The way it works is Packer launches an AWS AMI of choice (an official FreeBDS11/FreeBSD12 AMI in my case), runs through scripts to install things, shuts down the VM, takes a snapshot and creates a new AMI. This resulting AMI does not have /firstboot as I presume rc removes it.
Indeed, I can touch the file as a part of my AMI configuration, however I would also need to track any firstboot_* rc.conf entries going forward and disable those - e.g. I don't want packages to be auto-updated on subsequent runs.
When compared to cloud-init as on other AWS-supported operating systems where it's possible to explicitely tell it to accept user-data on every boot, FreeBSD AMI behaviour looks less nice. I mean, I can just sed the KEYWORD out as a part of provisioning, but that feels like a hack rather than a good long-term solution.
Sounds like a bug in Packer.
A better way to create customized FreeBSD images is using the AMI Builder AMI or using "make ec2ami" from /usr/src/release.
I don't think it's a bug in the tool, since it doesnt touch /etc/rc in any way, and rc rightfully removes /firstboot after machine has been launched the first time.
Creating an image from AMI Builder AMI or the source tree is, of course, an option, but that would be just too much effort for a rather simple modification (basically pkg install foo bar) for a base official AMI image in my specific case.
To sum up, it would be very nice to have a configurable way to run ec2_configinit without being tied to firstboot.