-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Recalling AMI Release v20230211 due to it breaking Kernel upgrades #1193
Comments
* Mark v20230211 as recalled v20230211 is being recalled due to an issue affecting Kernel upgrades. See #1193 for more details.
Will adding a kernel versionlock in the future mean that all kernel upgrades, including kernel-livepatching, will only work after the kernel versionlock is explicitly removed? |
That's correct. Our recommendation is still relying on our AMI releases to get the latest Kernel since that'll make sure that the Kernel version being used is the one that has passed our testing. But if there's a strong reason to upgrade the Kernel that the AMI ships with, then yes, you'll need to remove the version lock before the upgrade. |
https://github.com/awslabs/amazon-eks-ami/releases/tag/v20230217 fixes this issue. Resolving this as a result. |
Description
If you don't upgrade the Kernel in EKS Optimized AMIs, you can stop reading.
If you DO upgrade the Kernel that the EKS Optimized AMIs ship with, you should know that a recent bug caused Kernel upgrades to behave unexpectedly in the AMI Release v20230211.
The bug was introduced as a result of this change where we added a version lock to the Kernel. This was done to make sure that customers don't accidentally end up updating the Kernel version that the AMI ships with because our tests only validate the AMI with the Kernel that it ships with and updating it to a different version could cause issues/instabilities.
What went wrong in that change was that instead of locking only the Kernel which is shipped with the AMI by default, it version locks both
4.14
and5.4
Kernels (for the AMIs which have5.4
as default) as seen from the output in one of the affected AMIs:As a result of this, if you upgrade the Kernel, it can end up bringing it down to
4.14
. Effectively, something like the following:Workaround and mitigation
We are working on releasing a new set of AMIs which would fix this problem and are also recalling AMI Release v20230211.
If you need to work around this in the meanwhile, you can use
sudo yum versionlock delete kernel
as shown in the steps below:And then proceed with the Kernel upgrade.
The text was updated successfully, but these errors were encountered: