Kernel patching on Rocky and Ubuntu

Steps 1 to 8 run on rocky01 and need two reboots plus one more for the rollback drill, so keep the VirtualBox console window open. Steps 9 and 10 run on ubu01 and change nothing. The outputs were captured on a rocky01 still running 6.12.0-211.7.1.el10_2.0.1.x86_64 with 6.12.0-211.16.1.el10_2.0.1 waiting in the repository; your build numbers will be whatever dnf offers today, so follow the pattern rather than the digits.

If your rocky01 is already on the newest kernel (dnf says “Nothing to do” in step 4), install the previous build next to it so you have something to roll back to: dnf list --showduplicates kernel lists the builds the repository still has, and sudo dnf install kernel-VERSION adds one. Then carry on from step 5.

1Which kernel runs, which are installed?

Run this on rocky01:

uname -r
rpm -q kernel-core
ls /boot/vmlinuz-*

You should see something like this:

6.12.0-211.7.1.el10_2.0.1.x86_64
kernel-core-6.12.0-211.7.1.el10_2.0.1.x86_64
/boot/vmlinuz-0-rescue-8c1f2e7a4b9d4f6e9a2c3b1d5e7f9a0c
/boot/vmlinuz-6.12.0-211.7.1.el10_2.0.1.x86_64

One kernel installed and running, plus the rescue kernel that the installer made: a copy of the install-time kernel with a generic initramfs that has drivers for any hardware. The file name carries the machine ID, which is why it looks different on every server.

✅ Checkpoint: You know your running kernel and how many kernel-core packages are installed.

2Read GRUB’s list with grubby

Run this on rocky01:

sudo grubby --default-kernel
sudo grubby --default-index
sudo grubby --info=ALL | grep -E '^(index|kernel|title)'

You should see something like this:

/boot/vmlinuz-6.12.0-211.7.1.el10_2.0.1.x86_64
0
index=0
kernel="/boot/vmlinuz-6.12.0-211.7.1.el10_2.0.1.x86_64"
title="Rocky Linux (6.12.0-211.7.1.el10_2.0.1.x86_64) 10.2 (Red Quartz)"
index=1
kernel="/boot/vmlinuz-0-rescue-8c1f2e7a4b9d4f6e9a2c3b1d5e7f9a0c"
title="Rocky Linux (0-rescue-8c1f2e7a4b9d4f6e9a2c3b1d5e7f9a0c) 10.2 (Red Quartz)"

Each index is one BLS file in /boot/loader/entries/. Newer kernels sort first and the rescue entry last. Use --info=ALL without the grep when you need the kernel arguments and initramfs path of each entry too.

✅ Checkpoint: grubby shows the running kernel as index 0 and the default.

3Check the rules dnf follows

Run this on rocky01:

grep -E 'installonly|exclude' /etc/dnf/dnf.conf
grep -E '^[A-Z]' /etc/sysconfig/kernel

You should see something like this:

installonly_limit=3
UPDATEDEFAULT=yes
DEFAULTKERNEL=kernel-core

dnf keeps up to three kernel versions, every new kernel becomes the default, and there is no exclude= line, so kernels are not held back. If your company’s build adds exclude=kernel*, you’ll see it here, and dnf update will quietly skip kernels until someone adds --disableexcludes=main.

✅ Checkpoint: installonly_limit is 3 and UPDATEDEFAULT is yes.

4Check for a kernel update and install it

Run this on rocky01:

dnf check-update kernel; echo "exit code: $?"

You should see something like this:

Last metadata expiration check: 0:41:12 ago on Tue 27 Oct 2026 01:05:44 PM IST.

kernel.x86_64                     6.12.0-211.16.1.el10_2.0.1               baseos
exit code: 100

Exit code 100 means “updates available”, 0 means none and 1 means an error, which makes check-update handy in scripts and monitoring. Now install it:

sudo dnf update -y kernel

The end of the output should look something like this:

Installed:
  kernel-6.12.0-211.16.1.el10_2.0.1.x86_64
  kernel-core-6.12.0-211.16.1.el10_2.0.1.x86_64
  kernel-modules-6.12.0-211.16.1.el10_2.0.1.x86_64
  kernel-modules-core-6.12.0-211.16.1.el10_2.0.1.x86_64

Complete!

dnf listed the four packages under “Installing”, not “Upgrading”: the old kernel stays. Behind the “Running scriptlet” lines, kernel-install copied the kernel into /boot, dracut built its initramfs and grubby added the entry, which takes a minute on a small VM.

✅ Checkpoint: dnf finished with Complete! and listed kernel-core for the new version.

5Installed is not running

Run this on rocky01:

uname -r
sudo grubby --default-kernel
dnf needs-restarting -r; echo "exit code: $?"

You should see something like this:

6.12.0-211.7.1.el10_2.0.1.x86_64
/boot/vmlinuz-6.12.0-211.16.1.el10_2.0.1.x86_64
Core libraries or services have been updated since boot-up:
  * kernel

Reboot is required to fully utilize these updates.
More information: https://access.redhat.com/solutions/27943
exit code: 1

This is the state most patch reports miss: the new kernel is installed and set as default, but the old one is still running. needs-restarting returns 1, so a patch script or monitoring check can act on it. Plan the reboot now, through your change process.

✅ Checkpoint: uname -r still shows the old kernel, the default is the new one and needs-restarting exits with 1.

6Reboot and prove the new kernel runs

Run this on rocky01, log in again when it’s back, then run the rest:

sudo systemctl reboot

uname -r
dnf needs-restarting -r; echo "exit code: $?"
sudo grubby --info=ALL | grep -E '^(index|kernel)'

You should see something like this:

6.12.0-211.16.1.el10_2.0.1.x86_64
No core libraries or services have been updated since boot-up.
Reboot should not be necessary.
exit code: 0
index=0
kernel="/boot/vmlinuz-6.12.0-211.16.1.el10_2.0.1.x86_64"
index=1
kernel="/boot/vmlinuz-6.12.0-211.7.1.el10_2.0.1.x86_64"
index=2
kernel="/boot/vmlinuz-0-rescue-8c1f2e7a4b9d4f6e9a2c3b1d5e7f9a0c"

The new kernel runs, nothing else needs a reboot, and GRUB now has three entries: new, previous and rescue. Before you close the ticket at work, also check systemctl --failed and any kernel modules your applications need.

✅ Checkpoint: uname -r shows the new kernel and needs-restarting exits with 0.

7Boot the previous kernel on purpose

Practise the rollback while nothing is on fire. On rocky01:

sudo grubby --set-default /boot/vmlinuz-6.12.0-211.7.1.el10_2.0.1.x86_64
sudo systemctl reboot

grubby answers something like this before the reboot:

The default is /boot/loader/entries/8c1f2e7a4b9d4f6e9a2c3b1d5e7f9a0c-6.12.0-211.7.1.el10_2.0.1.x86_64.conf with index 1 and kernel /boot/vmlinuz-6.12.0-211.7.1.el10_2.0.1.x86_64

After the reboot, check and put the new kernel back as default:

uname -r
sudo grubby --set-default /boot/vmlinuz-6.12.0-211.16.1.el10_2.0.1.x86_64
sudo systemctl reboot

6.12.0-211.7.1.el10_2.0.1.x86_64
The default is /boot/loader/entries/8c1f2e7a4b9d4f6e9a2c3b1d5e7f9a0c-6.12.0-211.16.1.el10_2.0.1.x86_64.conf with index 0 and kernel /boot/vmlinuz-6.12.0-211.16.1.el10_2.0.1.x86_64

Always give grubby the kernel path, not an index: indexes move every time a kernel is added or removed. At the console you can do the same for one boot only by picking the older entry in the GRUB menu, which is the faster choice when a server won’t come up at all.

✅ Checkpoint: rocky01 booted the previous kernel once and is back on the new one, with grubby --default-kernel showing the new path.

8Remove a kernel safely, and the one dnf won’t remove

See what removing the old kernel would do, without doing it:

sudo dnf remove --assumeno kernel-core-6.12.0-211.7.1.el10_2.0.1

You should see something like this:

Dependencies resolved.
================================================================================
 Package                  Arch     Version                     Repository  Size
================================================================================
Removing:
 kernel-core              x86_64   6.12.0-211.7.1.el10_2.0.1   @anaconda   69 M
Removing dependent packages:
 kernel                   x86_64   6.12.0-211.7.1.el10_2.0.1   @anaconda    0
 kernel-modules           x86_64   6.12.0-211.7.1.el10_2.0.1   @anaconda   37 M
 kernel-modules-core      x86_64   6.12.0-211.7.1.el10_2.0.1   @anaconda   33 M

Transaction Summary
================================================================================
Remove  4 Packages

Freed space: 139 M
Operation aborted.

Removing kernel-core takes its three companion packages with it, and dnf’s scriptlets also delete the files in /boot and the BLS entry, which is why you never remove kernels with rm. --assumeno showed the plan and answered no. Now try the running kernel:

sudo dnf remove kernel-core-$(uname -r)

You’ll get something like this:

Error:
 Problem: The operation would result in removing the following protected packages: kernel-core

dnf protects the running kernel, so even a careless command can’t leave a server without the kernel it is using. Keep both kernels: the old one is your rollback until the new one has run cleanly for a while, and installonly_limit will remove it for you later.

✅ Checkpoint: You saw the four packages a kernel removal touches, and dnf refused to remove the running kernel.

9The Ubuntu side: kernels and the reboot flag

Run this on ubu01:

uname -r
dpkg -l 'linux-image*' | grep '^ii'
ls /var/run/reboot-required 2>/dev/null || echo "no reboot needed"
sudo needrestart -b -r l

You should see something like this:

7.0.0-15-generic
ii  linux-image-7.0.0-15-generic          7.0.0-15.15  amd64        Signed kernel image generic
ii  linux-image-generic                   7.0.0-15.15  amd64        Generic Linux kernel image
no reboot needed
NEEDRESTART-VER: 3.8
NEEDRESTART-KCUR: 7.0.0-15-generic
NEEDRESTART-KEXP: 7.0.0-15-generic
NEEDRESTART-KSTA: 1

When apt installs a new kernel, its scripts create /var/run/reboot-required (and list the packages in reboot-required.pkgs), and needrestart reports KSTA 3 for “newer kernel installed, not running”. KSTA 1, as here, means the running kernel is the newest one installed. Monitoring tools read either of these.

✅ Checkpoint: ubu01 runs the only installed kernel image and needs no reboot.

10Who installs kernels on Ubuntu while you sleep

Run this on ubu01:

cat /etc/apt/apt.conf.d/20auto-upgrades
grep 'Automatic-Reboot' /etc/apt/apt.conf.d/50unattended-upgrades
apt-mark showhold
apt-cache policy linux-generic | head -n 3

You should see something like this:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
//Unattended-Upgrade::Automatic-Reboot "false";
//Unattended-Upgrade::Automatic-Reboot-WithUsers "true";
//Unattended-Upgrade::Automatic-Reboot-Time "02:00";
linux-generic:
  Installed: 7.0.0-15.15
  Candidate: 7.0.0-15.15

unattended-upgrades runs every day and installs security updates, and kernel fixes arrive as security updates, so an Ubuntu server can collect new kernels on its own. The reboot lines are commented out, so it never reboots by itself. No packages are held, and the GA kernel metapackage linux-generic is installed (Lesson 36 covers holds and unattended-upgrades in full).

✅ Checkpoint: unattended-upgrades is on, automatic reboot is off, and no kernel packages are held.