On Sat, Jul 14, 2018 at 3:11 PM, Henry Finucane <h.finucane at gmail.com> wrote: > On Sat, Jul 14, 2018 at 5:22 AM Nico Kadel-Garcia <nkadel at gmail.com> wrote: >> See above. Also, the base CentOS 7 3.10.0 kernel is becoming a bit >> dated: it's 5 years old now. If you have time: can you set up a >> smaller instance, do kernel updates on top of a CentOs 7 AMI, and see >> if *that* AMI is compatible with the new instances? Might make for an >> interesting test and get you a working AMI. > > I did this with CentOS 6 at some point, and it's worth noting that > you'll have to build your own AMI from scratch, you can't just update > the existing AMI- the base AMI's lack of support "taints" derived > ones. There Are Ways(tm). One of my favorite is to link a LiveDVD image to the VM built from the messed up or out of date OS image, mount the storage for the messy host, and do the updates on a chroot cage to *that*. In this case, there instances of the same class, just different sizes, that are apparently tested and approved. I'd stage a build to one of the approved instance types and do the updates *there*, then take a snapshot. > I used packer's chroot builder, it was pretty reasonable and you can > find examples online to help you get started. Heh. I wrote tools that did something like this for hardware testing, creating a base tarball image much like "mock" does and applying it to new hadware configurations from DHCP and kickstart, and even one that could be downloaded and run to upgrade from a local tarball. That was in... 2000, and was used on roughly 20,000 systems that year for an OS update. It's still faster than most virtualization "disk image" based clones from a golden image.