Question about Cloud SIG kernel update schedule for Rocky 8.10

[Effaceurs]

Hi Rocky Team,

I’m running Rocky Linux 8.10 on GCP. I noticed that BaseOS repos ship newer kernels (4.18.0-553.85.1.el8_10 from November), but the Cloud SIG repo still shows 4.18.0-553.51.1.el8_10.cloud.0.1 from June.

Cloud images also ship with BaseOS kernel updates excluded:

/etc/yum.repos.d/Rocky-BaseOS.repo: exclude=kernel*

I found a similar request here, so I am aware of a context.

Cloud-kernel not up to date in sig repo

Hi, Both Rocky 8 and 9 cloud-kernel sig repos have not been updated since Sept '24, leaving numerous systems vulnerable. Do we know who can fix this repo to ensure its up to date and secure? Index of /pub/sig/8/cloud/x86_64/cloud-kernel/Packages/k/ Index of /pub/sig/9/cloud/x86_64/cloud-kernel/Packages/k/ When using cloud-kernel sig repo, the default behaviour is to exclude=kernel* on the base repo. So people running dnf updates will get other updates and think they are secure, however as c…

Saying that, could you please comment on:

1. the update / release cycle for Cloud SIG kernels
2. If newer Cloud SIG kernels are expected soon, especially for security parity with BaseOS?
3. Is it generally safe to remove an exclude and upgrade the kernel from BaseOS in cloud environment?

Thanks upfront!

[iwalker]

I can’t comment on points 1 and 2, @neil would have to chime in on that. For point 3 though, going by what Neil wrote previously:

The good news is that most of the changes in the SIG/Cloud kernel have been upstreamed into the CentOS Stream (and thus Rocky) kernels, but that obviously doesn’t help or matter when the recommended config–as you note–disables getting kernels from elsewhere.

If that is the case, and changes from cloud sig have now been incorporated into the default Rocky kernels, then that would suggest it’s safe to remove the exclude and use the normal Rocky kernels.

I don’t know enough about the cloud sig kernels to know what they were trying to achieve - eg: if they were cut down kernels built for the cloud where a lot of kernel modules aren’t needed, etc. Again, that would be something that Neil would have to chime in on.