The parent issue RHELC-1672 has the label that triggered autocreation of this subtask to track the relative story point estimation for the integration test part of the issue.

The parent issue description at the time of creation of this issue was:
When there is a newer kernel available in RHEL than the latest from the original vendor, albeit handled and installed by the main transaction, it does not get set as a default kernel to boot into.
Instead, we try to install an older version of kernel and report a conflict of kernel versions.
The conversion finishes successfully in the end, but leaves the system running on a kernel version without the latest security updates.

There is a fallback for the kernel version conflict, where we try to update the older version installed prior, but this eventually fails to do anything, since the latest kernel version is already installed by the main transaction.

This can be generally reproduced/seen in the short period of time, when RHEL kernel package has not yet been rebuilt by the other vendors.
Or when trying a minor version bump.

The issue seems to be here , where we only capture the first match from the yum install kernel call.
Additionally, it seems like we don't consider the scenario of the newer kernel version installed during the main transaction at all.

Reproducer:

1. Get AlmaLinux 8.8 machine
2. Set the releasever=8.9 in /usr/share/convert2rhel/configs/almalinux-8-x86_64.cfg
3. run the full conversion

Attached log files show conversion from CentOS 8.5 to 8.10.
The cos85-to-rhel810_convert2rhel.log demonstrates the current implementation
cos85-to-rhel810-fix_convert2rhel.log shows a potential fix to the issue.
 

Acceptance criteria

• Set the latest RHEL kernel available in the respective minor version as the default to boot to