Looks like the Rockylinux AMI 9.2 doesn’t support the new EC2 instance type “inf2” (aka AWS Inferentia2). They support inf1 so I’m guessing inf2 just wasn’t an existing type when the Rockylinux AMI was published? Or is there a blocker to getting Rockylinux running on these new types?
Now for some confusion I got while gathering details to post this…
What’s the difference between these two, besides the obvious:
this is the “Verified Provider” one in the AWS Marketplace when you search for Rockylinux 9.2
Hi! Thanks for the post and for joining the community here.
Nope, just tech debt, basically. We have to manually add each instance type when they’re added, at this time. It’s something we’re going to be addressing as part of our rework of the Peridot build system to support publishing and managing releases to clouds.
For the inf2 images, I’ve submitted requests for our x86_64 images to enable this type. You should be able to launch them from the Console in a day or so, based on past experience.
I can provide some clarity here as well.
The Base images are standard partitioning, and the LVM ones are LVM (i.e., “the obvious” that you mentioned). They have the same layout, just with the LVM variant using a volume group on the last partition, so it is a bit more flexible if one wanted to add another PV, or do whatever they want without messing with the partition table on the root disk.
As for the image ID differences–this is related to the previous bit about the Marketplace. Whenever we upload and publish images, there are two sets of images for every one that we upload: the Rocky-Owned images, and the Marketplace-Owned image. The ‘Verified Provider’ image you see when searching is the latter (Marketplace-Owned) image.
The way this works is that we build, upload, and test the images, and then promote them. For the Rocky-Owned images, this is a matter of using our image propagation script to copy the AMI from us-east-1 to all the other regions around the world. This allows users to search for images using the ec2/describe-images call with our owner id: 792107900819.
While this is happening, we also take these same source AMIs, and submit a request to the AWS Marketplace Management Portal for each image, providing the source image ID, as well as an IAM role AWS can assume to copy the image. From here, AWS owns the process, and controls the rest. They perform some of their own tests and validations, and along with the metadata we provide about what instance types it should be available on, etc, goes through its own publication process to, essentially, copy the image to every region as we do with our propagation script. This is why the ami ID is missing there, as it comes from the Marketplace, not from the Rocky AMI account.