UEK defaults over RHCK and an unregistered Ksplice channel

Recovery. Do not remove kernel-uek packages while the system is running UEK; that can delete the running kernel and modules and make the next reboot unbootable. First confirm the RHCK entry exists with grubby --info=ALL or awk -F\' '/^menuentry/ {print NR-1, $2}' /boot/grub2/grub.cfg, and verify its initramfs is present. Set it as the default with grub2-set-default <title-or-index>, confirm with grub2-editenv list and grubby --default-kernel, then reboot in the change window. If the system must come up faster and you have console access, select the RHCK entry at the GRUB menu, but still make the default persistent. After boot, verify uname -r is the certified 4.18.0-477 kernel, then rebuild the DKMS module with dkms status and dkms autoinstall, and confirm it loads with modinfo and lsmod. Only after the app is stable should you decide whether to keep or remove the UEK packages; keeping them but not defaulting to them preserves a rollback path. Check /boot free space before any kernel operation.

Prevention. GRUB_DEFAULT=saved is not a kernel pin; it boots whatever entry is recorded in grubenv, and kernel package scriptlets can update that entry. Excluding kernel-uek* in /etc/dnf/dnf.conf or in the UEK repo file prevents new UEK kernels from arriving while still allowing RHCK kernel updates; dnf versionlock add 'kernel-uek*' achieves a similar result but can be less visible to the next administrator and must be maintained. Disabling the entire UEK repo is broader than necessary and may block other UEK-provided packages; prefer an exclude unless the standard forbids UEK entirely. For the boot entry, either keep GRUB_DEFAULT=saved and add a post-update check that runs grub2-set-default for the certified RHCK title, or set GRUB_DEFAULT to a fixed title or index; the fixed index is fragile because entries reorder when kernels are added or removed. The robust process is: exclude UEK, install RHCK updates, set the saved entry to the new RHCK kernel, verify grubby --default-kernel, and reboot in a window. Keep at least one previous RHCK kernel and monitor /boot with installonly_limit=3.

Ksplice gap and constraints. Ksplice is not updating because the Ksplice channel or repo is not enabled, so the client cannot see updates; uptrack-show on the old RHCK was reporting the last state it knew, not current patches. With ULN and Premier support, enable the Ksplice channel for the system (the ol8_ksplice repo on yum.oracle.com or the corresponding ULN channel), install or update the ksplice userspace package, then run uptrack-upgrade -y and confirm with uptrack-show. Ksplice patches the running kernel in memory, so it does not fix the RHCK/UEK boot problem and does not patch user-space packages such as glibc or PHP; those still need dnf update --security and may require a reboot. It also cannot cover every kernel change, and a newly booted kernel may need a fresh uptrack-upgrade before it is at the same patch level. For a 90-day audit window, combine Ksplice for supported kernel CVEs with user-space errata, document the effective kernel and patch list, and do not treat Ksplice as a substitute for a certified kernel. If the vendor requires RHCK, keep RHCK as the running and default kernel; Ksplice patching UEK would keep a broken platform patched.