Linux 7.2 reaches end of life: plan a controlled kernel transition

Updated: 9 November 2026. Kernel.org marks Linux 7.2.15, dated 1 November, as EOL and lists Linux 7.3.3, dated 6 November, as stable. This calls for an inventory check, not a blanket instruction to install a new kernel on every Linux machine. Package origin and support for the actual system matter. [1]

What end of life actually means

This guide is for experienced Linux users and administrators. The end of the upstream 7.2 branch does not, by itself, establish whether a distribution package still receives security fixes. Vendors may backport changes and use their own support periods. An older version family therefore does not prove an unpatched vulnerability; a newer family does not prove that a particular bug is fixed either. Release candidates are not a general production recommendation. [2]

Preparation: establish recovery first

Arrange a maintenance window, a verified data backup and a recovery route you can actually access. Remote machines need particular attention to an independent console: an open SSH connection will not survive a reboot. Record encryption/unlock procedures, boot selection and required storage, network and graphics drivers without copying keys into a work log. A snapshot on the same disk is not a separate backup.

Five steps for a controlled transition

  1. Collect the inventory without making changes. uname -r identifies the running kernel; cat /etc/os-release identifies the distribution. Also identify the installed kernel package and its repository in the package manager. Inside a container, uname -r refers to the host kernel: responsibility belongs with the host operator, not the container image.
  2. Match the correct support policy. Check vendor notices for the exact distribution, release, architecture and kernel variant. Ubuntu, for example, lists its own product and kernel coverage. [4] If the system remains supported and its package receives fixes, do not abandon the vendor channel solely because of upstream EOL. A self-built 7.2 kernel instead requires a maintained successor and a test plan you own.
  3. Prepare compatibility checks and a fallback boot. Check free space in the boot area and guidance on extra modules, DKMS, Secure Boot and initramfs. Keep the known-working kernel and matching modules; do not leave learning how to select it until an emergency. Do not disable protection just to boot an unknown package. Stop if recovery access is unresolved.
  4. Update through the documented system route. Use the supported package/image channel or the custom build process intended for this installation, not unrelated one-liners. Kernel documentation explains that building and installing your own kernel involves distribution-specific steps. [3] Check installation and module failures before the planned reboot. This article performs no system changes for you.
  5. Verify the running result after reboot. Compare uname -r with the intended installed package. Test storage, networking, graphics, important services and laptop suspend/resume where relevant. On a server, test a new external connection. An installed package or a successful boot alone is not sufficient.

Verify success and recover from problems

If a regression occurs, use the prepared boot/recovery route to return to the known kernel, record package versions and symptoms, and involve the vendor. The old kernel is a limited continuity measure, not a permanent solution on an unmaintained branch. Plan routine cleanup only after stable acceptance; do not follow blanket deletion instructions.

Limits and sources

This is an editorial procedure, not a kernel, hardware or attack test we conducted. It specifies no universal target version, claims no particular CVE fix and guarantees no device compatibility. Current vendor guidance remains authoritative. This noncommercial guide contains no affiliate links.