alexblyth.net

Tag: kernel

  • Exadata, Ksplice, Kernel Versions, and Why uname -a Does Not Always Tell the Whole Story

    Exadata, Ksplice, Kernel Versions, and Why uname -a Does Not Always Tell the Whole Story

    One question I hear pretty often is this: after applying Ksplice updates, why does the kernel version still look unchanged?

    The answer is that Ksplice is updating the kernel’s behavior, not swapping out the installed kernel package right away. That distinction matters, because it explains why tools like imageinfo and uname -a can appear to tell a different story from what is actually running.

    Why imageinfo shows two kernel versions

    Here is a simplified example of what you might see:

    Kernel Version:           5.15.0-300.163.18.7.el8uek.x86_64 #2 SMP Fri Nov 15 03:14:11 PST 2024 x86_64
    Uptrack kernel version:    5.15.0-306.177.4.1.el8uek.x86_64 #2 SMP Sat Mar 22 03:27:18 PDT 2025 x86_64
    Image kernel version:      5.15.0-300.163.18.7.el8uek

    Or from the command line:

    $ uname -a
    Linux dbserver01 5.15.0-300.163.18.7.el8uek.x86_64 #2 SMP Fri Nov 15 03:14:11 PST 2024 x86_64

    At first glance, it can look like nothing changed after applying Ksplice updates. That is usually where the confusion starts.

    If you look at imageinfo, you will usually see two kernel-related values:

    • Kernel Version
    • Uptrack kernel version

    They are related, but they are not the same thing.

    Kernel Version

    This is the kernel package that is installed on disk. It is also the version reported by uname -a.

    So if someone applies Ksplice updates and then checks uname -a, they may not see the kernel version change. That is expected.

    Uptrack kernel version

    In contrast, the Uptrack kernel version reflects the effective running kernel after Ksplice updates have been applied.

    For example:

    Uptrack kernel version: 5.15.0-306.177.4.1.el8uek.x86_64 #2 SMP Sat Mar 22 03:27:18 PDT 2025 x86_64

    That means the running kernel has already been updated in memory to behave like the newer target kernel, even if the installed kernel package version has not yet changed.

    This is the version the system is effectively running after Ksplice has applied its updates.

    My simple mental model is this: Ksplice is like applying a set of very targeted hot fixes to the running kernel so that it behaves like the newer target version.

    So even if the installed kernel package has not been replaced yet, the running kernel can already be operating as if it were at the updated level.

    What happens during an Exadata upgrade?

    A related question is whether upgrading DB nodes from one release to another also updates the kernel and fixes the related CVEs.

    The answer is yes.

    However, the path depends on how you do the upgrade.

    With Exadata Live Update

    If you use Live Update in modes like full, allcvss, or highcvss, Ksplice is used to apply the needed fixes without a reboot. That means the running kernel is brought into line with the kernel that ships in the newer release.

    After a reboot, the system installs and boots that updated kernel directly.

    With a regular rolling upgrade

    If you update DB servers the regular way, the new kernel is installed and booted as part of the upgrade process.

    The main point

    Whether you use Live Update or a traditional rolling upgrade, the end result is the same: you land on the kernel level that ships with the newer release, and the associated security fixes are in place.

    The only thing that can be confusing is the timing. With Ksplice, the running kernel can be patched immediately, even before the system reboots into the newer installed kernel.