iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Short answer: Ubuntu kernel support follows the lifecycle of your Ubuntu release and the kernel track you installed. Standard kernel updates arrive through tested Stable Release Updates (SRUs), usually preserving compatibility through backported fixes. A normal kernel update takes effect after a reboot. Livepatch can apply many important security fixes without an immediate restart, but only for listed release, architecture, kernel-version and flavor combinations, and only for a limited period.
Choosing between the conservative GA kernel and the newer HWE stack is mainly a hardware decision. GA is generally safer for mature hardware and long-lived workloads; HWE is intended for newer hardware and graphics support. Before changing tracks, identify your release and architecture, check the lifecycle and HWE status, keep a known-good kernel installed, and schedule a reboot with time to test drivers and applications.
What “kernel support” means in Ubuntu
Ubuntu fixes a release rather than continuously changing its user space
Ubuntu is a fixed-release Linux distribution. During a release’s supported life, security updates normally arrive as patches backported to the kernel series shipped for that release. The purpose is to correct vulnerabilities and important defects without needlessly introducing unrelated functionality or breaking established interfaces. This policy is described in the Ubuntu Security Documentation.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
That does not mean every kernel receives updates forever. The relevant dates depend on the Ubuntu release, whether you use the default GA line or HWE, and whether coverage is standard security maintenance, Expanded Security Maintenance (ESM), or a legacy period. Canonical’s kernel lifecycle table lists those dates by release and track. Check that table for the exact version running on a production machine instead of assuming that an LTS label alone guarantees a particular kernel’s coverage.
#1 Best Overall
Stable Release Updates are the normal delivery channel
Kernel Stable Release Updates combine upstream stable fixes, CVE security corrections, selected bug fixes and hardware-enablement work. The documented cadence is a regular four-week cycle, with an additional two-week cycle used for urgent CVEs and critical fixes. A fix can be backported or cherry-picked into the stable Ubuntu series when waiting for a newer upstream line would leave users exposed or when the change is needed for supported hardware.
Updates therefore reflect a risk-based policy: critical failures and security issues come first, followed by simple low-risk corrections and hardware enablement that meet SRU criteria. The package version may change even when the kernel’s major upstream version does not, because the important change can be a targeted patch integrated into the existing release series.
Find the release, architecture and kernel track you are actually running
Support decisions are impossible to make reliably from a desktop label or a kernel number alone. Record the operating-system release, CPU architecture, kernel flavor and whether the installation is on GA or HWE.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problems- Print the running kernel: run
uname -r. The output identifies the kernel version and commonly includes a flavor suffix such as a generic or low-latency build. - Print the Ubuntu release: run
. /etc/os-release && echo "$PRETTY_NAME". This avoids confusing the release name with the kernel’s upstream version. - Print the architecture: run
dpkg --print-architecture. Architecture is part of Livepatch eligibility and affects which packages are available. - Check HWE status: run
hwe-support-status --verbose. The command reports whether the installed HWE stack remains supported and indicates when a transition is required. - Inspect installed kernel packages: use your package manager’s installed-package view and note both the image and its matching headers. A machine can have several kernels installed;
uname -rshows only the one used for the current boot.
Write these results down before an upgrade or a track change. A kernel that looks “newer” is not automatically supported for your release, and a HWE status warning should be resolved before relying on the machine for production work.
Rank #2
GA versus HWE: which kernel track fits your machine?
GA (General Availability) is the default, conservative kernel line for an Ubuntu release. HWE (Hardware Enablement) supplies newer kernels and graphics components on LTS releases so that newer computers can be supported without moving the whole operating system to a new Ubuntu release. HWE follows a rolling model: when the next supported HWE stack is published, users on that track are expected to move to it.
| Decision factor | GA kernel | HWE kernel |
|---|---|---|
| Primary purpose | Stable baseline for the release | Newer hardware and graphics enablement on an LTS release |
| Support behavior | Follows the release’s GA lifecycle | Rolling stack; move to the next supported HWE stack when required |
| Hardware age | Usually suitable for mature, already-supported hardware | Useful when the machine or GPU was released after the original LTS kernel |
| Kernel ABI and DKMS exposure | More conservative change rate generally reduces integration work | New kernels can require DKMS and out-of-tree modules to be rebuilt and validated |
| Graphics stack | Older, release-aligned stack | Newer kernel and graphics components when the release offers them |
| Operational choice | Preferred for long-lived, tightly controlled workloads when current hardware works | Preferred when newer hardware support is necessary and the driver stack is compatible |
Choose GA when stability is the priority
GA is usually the sensible choice for servers, appliances and workstations whose hardware already works correctly and whose applications depend on third-party kernel modules. Its slower-moving baseline makes regression testing and DKMS maintenance easier. “Conservative” does not mean unpatched: the GA line still receives applicable SRUs and security fixes during its lifecycle.
Choose HWE when the hardware requires it
HWE is appropriate when a newer laptop, GPU, storage controller or other device is not fully supported by the original LTS kernel. Confirm that the exact release and flavor are listed as supported, then test the complete graphics, networking, storage and virtualization stack after each HWE transition.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Treat edge HWE variants as development technology
Ubuntu documents edge variants as development mode. They may lack components, DKMS support or the maturity expected in production and can contain bugs that have not been resolved in the normal HWE path. Do not use an edge variant merely to obtain the newest number; first establish that the regular supported stack cannot meet the hardware requirement.
How a normal kernel update works
Kernel packages are delivered through Ubuntu’s normal repositories and update process. The download and installation can happen while the current kernel is running, but the running kernel remains in memory until a reboot. Updating packages therefore is not the same as booting the new kernel.
- Prepare a maintenance window. Make sure you have console or remote recovery access, current backups, and time to test the machine after reboot. Check that at least one older, known-good kernel remains installed.
- Refresh package metadata: run
sudo apt update. - Install the release’s updates: run
sudo apt full-upgradeand review the transaction. Do not remove the only known-good kernel or accept an unsupported track simply to clear a package prompt. - Check module results. If the system uses DKMS or other out-of-tree modules, verify that the module build completed for the new kernel. A successful package transaction does not prove that every external driver built successfully.
- Reboot deliberately: run
sudo rebootduring the planned window. On a physical or virtual machine with a boot menu, keep the previous kernel available as a fallback. - Verify the boot: run
uname -ragain and test network interfaces, graphics, storage mounts, virtualization, DKMS-dependent devices and critical applications.
On systems with multiple kernels, the boot loader’s advanced-options menu provides a rollback path. If the new kernel causes a regression, boot the previous known-good entry, collect the failure details, and keep that kernel installed while you investigate. Remove an older kernel only after the replacement has passed your checks and another fallback remains.
Do kernel updates require a reboot?
For a conventional update, yes. The new kernel is a boot-time component, so a reboot is required before its fixes and hardware support are active. You can continue using the old running kernel briefly after package installation, but that does not provide the new kernel’s security state.
Canonical Livepatch changes the timing for many important kernel security fixes. It can patch selected functions in the running kernel, reducing the need for an immediate restart. Livepatch is not a universal substitute for kernel upgrades: it does not cover every change, every vulnerability or every kernel configuration.
Rank #4
| Situation | What happens | What you still need to do |
|---|---|---|
| Normal kernel package update | New image is installed on disk; the old image keeps running | Reboot into the new image and test the machine |
| Livepatch-covered security fix | A supported fix is applied to the running kernel without an immediate reboot | Continue normal kernel upgrades and reboot within the documented window |
| Unsupported release, architecture, version or flavor | Livepatch coverage is not promised | Use the normal update and reboot procedure |
Livepatch has a finite support window
Livepatch documentation states that patches are created for a kernel for approximately 9–13 months from that kernel’s release date. The exact combination of Ubuntu release, architecture, kernel version and flavor must be listed as supported. The machine must be upgraded and restarted within that interval to continue receiving Livepatch patches; leaving a system on an old kernel indefinitely is not a supported strategy.
Livepatch is commonly associated with Ubuntu Pro, an optional service. Whether it is appropriate depends on your maintenance policy, supported combinations and the value of avoiding an immediate reboot. It reduces reboot pressure, not the need for lifecycle management, testing or eventual restarts.
Can a kernel update break hardware or drivers?
It can. SRU testing and compatibility goals reduce risk, but a kernel changes the code that talks to storage, graphics, networking, virtualization and external modules. Hardware regressions, an incomplete DKMS build or a module that depends on an older kernel interface can leave a device unavailable even when the kernel package installed successfully.
Before installing
- Confirm the Ubuntu release, architecture, flavor and GA/HWE status.
- Read the lifecycle status and resolve any HWE transition warning reported by
hwe-support-status --verbose. - List critical devices and services: root and data storage, network links, graphics, encryption, virtualization, and modules built outside the Ubuntu kernel packages.
- Ensure at least one known-good kernel is installed and that you can reach the machine’s console or boot menu if remote access fails.
- Schedule the reboot when an operator can verify the result rather than treating it as an unattended package-only change.
After reboot
- Confirm the expected version with
uname -r. - Check that all expected interfaces, disks and mounts appear.
- Verify graphics acceleration or display output where applicable.
- Confirm DKMS and other external modules are loaded and that virtualization workloads start normally.
- Exercise the applications that depend on the changed hardware before closing the maintenance window.
Troubleshoot the common failure cases
The HWE status command reports an unsupported or expiring stack
Do not install an arbitrary newer kernel. Compare the installed release and flavor with the supported lifecycle table, then move to the next supported HWE stack or return to the release’s supported GA line according to your hardware needs. Test the selected track before deploying it broadly.
Best Value
A DKMS module fails during the update
Keep the previous kernel available and inspect the module build result before rebooting into production use. If the module is essential, boot the known-good kernel, correct the module/package compatibility problem, and retry the build for the target kernel. A kernel that boots without a required storage, network or graphics module is not a successful upgrade.
The new kernel boots but a device or application regresses
Select the previous kernel from the boot loader’s advanced options and confirm whether the symptom disappears. Record the kernel versions, affected hardware and module status, then use the supported package line while the regression is investigated. Do not delete the fallback kernel until the newer one is demonstrably stable.
Livepatch stops applying fixes
Recheck the release, architecture, kernel version and flavor against the listed Livepatch combinations, and check the kernel’s age. A kernel outside the 9–13-month patch-creation window, or one that is not in a supported combination, requires a normal kernel upgrade and reboot rather than continued reliance on Livepatch.
Free tools Windows power users keep installed
One-click scans. No signup required.
How Ubuntu kernel patches reach your machine
Most fixes originate in upstream Linux. Ubuntu’s kernel teams review, test and integrate them into the release’s supported series. Where timing or compatibility requires it, a specific change may be backported or cherry-picked rather than waiting for a wholesale upstream version change. SRU criteria then determine whether the correction is safe and relevant for post-release users.
This provenance explains why an Ubuntu kernel can contain a security correction without matching the newest upstream version number. It also explains the practical advice to use the packages built for your Ubuntu release: those packages carry the release-specific integration, testing and support assumptions that an unrelated mainline or edge build does not.
A practical decision checklist
- Need newer hardware or graphics support? Select a supported HWE stack, not an edge variant, and plan for its rolling transitions.
- Hardware already works and uptime is predictable? Stay on GA unless a documented requirement points elsewhere.
- Installing a regular kernel update? Schedule and perform the reboot; package installation alone does not activate it.
- Trying to avoid an immediate restart? Use Livepatch only when the exact combination is supported, and still complete normal upgrades and the required restart within its support window.
- Operating a production fleet? Keep a tested fallback kernel, stage updates, and validate DKMS, storage, graphics, networking, virtualization and applications after reboot.
The safest Ubuntu kernel policy is therefore neither “always stay old” nor “always take the newest kernel.” Match GA or HWE to the hardware, follow the lifecycle for the exact track, apply SRU updates from the release repositories, and treat every reboot as a small but real compatibility test.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
