AWS reports CentOS 7 -> packer-generated AMI "Other Linux"

Packer
1

If we consider the official “CentOS 7” AMI as the first generation AMI, I’m able to create a 2nd generation AMI for internal use using the 1st gen as the source AMI. It works great. The biggest reason we needed to rebuild the 1st gen and not just use it straight is to reconfigure the underlying disk to break apart the file systems (/tmp, /var, etc) and set up LVM. For this, I used the packer “amazon-ebssurrogate” type. Again, works great. Been using it for over a year, no problems AFACIT.

I’m trying to use this second gen AMI to create a third generation, this time using the simpler “amazon-ebs” type. All I want to do is build on the work of the 2nd gen image to build an AMI with Vault pre-installed. Seems pretty straight forward. I cannot for the life of me get Amazon to recognize that this third gen AMI is also “CentOS 7”. It will only say “Other Linux” for the platform when looking at the resulting AMI.

I’ve been through a bunch of weird issues with it, but I’ve at least got it to where I can launch and ssh into instances from this 3rd gen AMI. I have no idea, however, what’s going on with this “Other Linux” label. I don’t know if Packer is feeding that to AWS, or it’s something that AWS tries to detect and can’t. I also don’t know what else this “Other Linux” (rather than the proper “CentOS 7”) might be affecting w/r/t instances launched from this AMI.

I’m very perplexed, and can’t figure out what I’m doing wrong. I made a gist of the 2nd and 3rd gen Packer templates here: https://gist.github.com/rjhornsby/d81ebac283daa847543c0ae821968cb4

A bit of explanation – Why go from 2nd to 3rd gen instead of 1st gen directly to what I’m calling here the 3rd gen with Vault installed? Because of the underlying filesystem changes that happen during the transition to the 2nd gen, it seems much easier to end Packer at that point. This is our sort of general purpose image we use for everything. By not trying to combine 2nd and 3rd generations into one step, it avoids trying to reboot in the middle of the Packer run, or chroot to get chef-client installed, run chef-client to get vault set up etc.

2

Just a quick follow up. After running into related issues trying to build a CentOS 8 AMI, I reached out to Amazon. Their suggestion, after the obligatory “we don’t support CentOS 8 but…” was to create an EC2 snapshot and then import that as an AMI. This bypasses several of the AWS VMImport checks and functions. Figuring out how was time-consuming, but after that this works really well.

Basically, you

  • get Packer to create an OVA
  • extract the OVF file from inside the OVA and upload it to S3
  • Use aws ec2 import-snapshot... against the file in S3
  • Use aws ec2 register-image against the snapshot

The downside is that you’re responsible (during the OVA building phase) for making sure the AMI has everything it needs (ie Xen, ENA, nvme drivers, cloud-init, etc). Some instance types like c5 require extra things (ie nvme driver) not needed by t2 types, but you won’t discover that until your t2 works great, but your c5 is mysteriously hosed.