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.
Kernel · Lesson 4
Kernel Installation
Learn how to install, boot, verify, and retain a distribution kernel with a tested fallback.
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.
What does uname -r display?
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.
Why is a supported kernel meta-package useful?
Preflight the Change
Before a kernel transaction:
- Confirm supported repositories, package signatures, release lifecycle, and the intended kernel flavor.
- Ensure
/bootor the EFI System Partition has enough space. - Preserve at least one known-good installed kernel and a selectable boot entry.
- Verify console, remote-management, rescue-media, encryption-recovery, and rollback access.
- 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.
Why must an initramfs-generation error block an assumed-success conclusion?
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.
When does a newly installed ordinary kernel package become the running kernel?
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.
Which kernel should remain installed during initial validation of a new one?
The Customize the GRUB2 Boot Menu lab provides a recovery-safe environment for understanding multiple entries.
Lesson complete
You finished Kernel Installation
You can now treat a kernel update as a boot-chain and compatibility change.
Distinguish the running release from installed images.
Track supported updates through the correct distribution package.
Preflight storage, initramfs, signatures, modules, and recovery access.
Boot and validate hardware and application behavior.
Retain a known-good fallback until the new kernel is proven.
Keep your learning progress
Create a free account to save this lesson and continue learning on any device.
Create a free account