Kernel Installation

Distributions package kernels together with modules, initramfs integration, boot-loader updates, signatures, and support policy. Use that managed workflow unless you are deliberately developing or testing a custom kernel and can recover the machine.

Running and Installed Kernels

Show the release of the kernel currently running:

$ uname -r
6.8.0-00-generic

This does not list every installed kernel and does not change immediately when a newer package is installed. The system must boot the new image before uname -r reports it. Query installed packages and boot entries with the distribution's own tools.

Prefer the Distribution Tracking Package

Install or retain the distribution's supported kernel tracking or meta-package so future security updates continue to arrive. Package names depend on release, architecture, hardware class, and kernel flavor. For example, Ubuntu commonly offers linux-generic, but cloud, low-latency, HWE, OEM, real-time, and architecture-specific systems use other packages.

Do not turn a version string from uname -r directly into an apt install operand and assume it is valid. Consult the current distribution documentation and inspect candidates with the package manager before installation.

Preflight the Change

Before a kernel transaction:

1. Confirm supported repositories, package signatures, release lifecycle, and the intended kernel flavor.
2. Ensure /boot or the EFI System Partition has enough space.
3. Preserve at least one known-good installed kernel and a selectable boot entry.
4. Verify console, remote-management, rescue-media, encryption-recovery, and rollback access.
5. Check out-of-tree modules, storage and network drivers, Secure Boot signing, hibernation, and virtualization compatibility.

The package transaction should generate a matching initramfs and update boot entries through distribution hooks. Read every error; a package marked installed is not sufficient if initramfs or loader generation failed.

Boot and Validate

Schedule a controlled reboot with stakeholders and active workloads accounted for. Ensure the console can select the older entry if the default fails. After boot:

$ uname -r
$ journalctl -k -b
$ systemctl --failed

Use equivalent tools on non-systemd systems. Validate storage, filesystems, networking, graphics, input, security modules, external modules, containers, virtual machines, and application health. A login prompt alone is not complete validation.

Removing Older Kernels

Use the package manager's supported cleanup workflow only after the new kernel has passed validation. Never remove the currently running kernel, the only known-good fallback, or packages required by the active tracking package. Review the exact proposed removal and resulting boot entries.

Manual deletion from /boot leaves package and loader state inconsistent. If space is already exhausted, create a recovery plan before changing files rather than deleting arbitrary images.

The Customize the GRUB2 Boot Menu lab provides a recovery-safe environment for understanding multiple entries.

Summary

You can now treat a kernel update as a boot-chain and compatibility change.

1. Distinguish the running release from installed images.
2. Track supported updates through the correct distribution package.
3. Preflight storage, initramfs, signatures, modules, and recovery access.
4. Boot and validate hardware and application behavior.
5. Retain a known-good fallback until the new kernel is proven.