HWE or GA kernel on your Ubuntu server?

Does the point release put a new kernel on my Ubuntu server?

No. On an Ubuntu server the choice between the HWE kernel and the GA kernel is a package you install, and a point release does not install it for you. The word "enablement" is doing two different jobs in the release notes, which is where the confusion starts. Hardware enablement (HWE) is the newer kernel track. Upgrade enablement is the separate moment when the upgrade path from one LTS to the next opens. A server that is already running, and already on GA, stays on GA through every point release of its LTS.

What the GA and HWE kernel tracks are

GA (general availability) is the kernel an Ubuntu LTS ships on release day. It keeps that upstream kernel version for the release's standard support window. Security fixes and bug fixes are backported into it, so the last number in uname -r moves every few weeks. The upstream version at the front of the string does not move.

HWE (hardware enablement) is the other track. Canonical backports the kernel from each later interim release into the LTS, so the enablement kernel steps up to a newer upstream version about every six months. Canonical calls this the rolling update model. Desktop images install the enablement kernel by default. Server and cloud images install GA by default, and the enablement stack is an opt-in package.

The trade is short. GA gives you a kernel version that does not move for years. HWE gives you newer drivers and newer kernel features, and asks for a version bump plus a reboot roughly every six months.

Which kernel track am I on right now?

uname -r never contains the word hwe. Both tracks print a version ending in -generic, so the running kernel name alone does not answer the question. The installed meta-package answers it.

uname -r
grep VERSION_ID /etc/os-release
apt-cache policy linux-generic linux-generic-hwe-24.04

Replace 24.04 with the number VERSION_ID prints on your own machine. apt-cache policy prints an Installed: line for each package you name. Installed: (none) for the -hwe- package plus a version for linux-generic means you are on GA. The reverse means you are on the enablement track. If both carry a version, both kernels are on disk, and GRUB boots the newest one, which is the enablement one.

Some provider images install linux-image-virtual rather than linux-generic. That is a smaller module set built for virtual machines, and it has its own enablement variant. Do not guess the name. Ask the machine which kernel packages someone chose, then ask the archive what enablement packages exist for your release.

apt-mark showmanual | grep '^linux-'
apt-cache search linux-image | grep hwe
apt-cache depends linux-image-generic-hwe-24.04
dpkg -l 'linux-image-*' | grep '^ii'
ls /boot/vmlinuz-*

apt-cache depends shows which kernel image the enablement meta-package points at today. ls /boot/vmlinuz-* shows what is actually installed and bootable, which is often more than you expect.

What each point release does to each track

On the GA track, a point release changes nothing on a running server. A point release is a refreshed install image plus the updates apt has already been handing you. It decides what a newly built machine gets, not what an existing one runs. What an Ubuntu point release actually changes covers the rest of it.

On the enablement track, the point release is when the meta-package moves. linux-image-generic-hwe-24.04 changes its dependency to a newer kernel image, and your next ordinary update run installs that image. The apt manual page is explicit about why a plain update run is enough: "New packages will be installed if required to satisfy dependencies, but existing packages will never be removed." So apt upgrade pulls in the new kernel. It only becomes the running kernel at the next reboot.

Whether an unattended job does this for you depends on your own configuration. Read /etc/apt/apt.conf.d/50unattended-upgrades and look at the Allowed-Origins block. The shipped default takes the security pocket only, so an enablement bump from the updates pocket is not applied automatically unless someone widened that list. Check the file rather than assuming either way.

The support windows follow from the same mechanism. The GA kernel is supported for the LTS release's standard window with no action from you. Each enablement kernel is supported until the next enablement kernel replaces it, so HWE is a supported track only while you keep taking every step. Falling two steps behind on that track leaves you running a kernel that no longer gets fixes, and apt will not say anything about it.

Do not take exact dates from any blog post, including this one. Canonical publishes an end date for every kernel version on the Ubuntu kernel lifecycle page, and the release and support dates on the Ubuntu release cycle page. Compare those pages against what uname -r and grep VERSION_ID /etc/os-release print on your server. That pair of facts is the only thing that describes your machine.

Why the enablement kernel rarely helps a VPS

HWE exists for hardware. A laptop or a physical server with a NIC (network interface card), a storage controller, or a GPU newer than the LTS kernel does not work properly until a newer kernel arrives. The enablement kernel is the fix for that, and on real hardware it is often the difference between a working machine and a dead one.

A rented VPS does not have that problem, because it does not see that hardware. A guest sees a small and deliberately old set of virtual devices. Check yours.

sudo apt install -y pciutils
lspci -nnk

lspci -nnk prints each device with the kernel driver bound to it underneath. On most VPS instances the list is short: virtio_net for the network, and virtio_blk or virtio_scsi for the disks. Those drivers have been in the mainline kernel for many years. The virtual device is a stable interface on purpose, because the guest has to keep working when the provider moves it onto different physical hardware. So the reason people install the enablement kernel mostly does not exist on a rented server.

The cost still exists. Every enablement step is a new kernel binary with its own reboot, on top of the reboots you already take for security kernels. On a single VPS with nothing to fail over to, a reboot is downtime you have to schedule and watch. Live kernel patching can remove some of the security reboots, but it cannot remove the reboot for a version bump, because that is a different kernel rather than a patched one.

When you should move to the enablement kernel

Four cases where the answer is genuinely yes.

• The hypervisor offers a device your kernel cannot drive. The symptom is concrete: an interface missing from ip -brief link, or a disk missing from lsblk, with the device present in lspci -nnk and no Kernel driver in use: line under it.
• Software you run documents a minimum kernel version higher than yours. Container runtimes, databases and eBPF tooling do this. Compare the vendor's stated minimum against uname -r and trust the vendor.
• You hit a bug that is fixed upstream after the GA version and not backported. Confirm the fix is actually in the enablement version before you switch, or you take the reboots and keep the bug.
• You need a filesystem or networking feature that landed after the GA version, and that feature is the reason the server exists.

If none of those describes your server, GA is the right answer, and leaving it alone is a decision rather than neglect.

How to switch, and what to check after the reboot

Check free space first. If /boot is a small separate partition, adding a second kernel line can fill it, and apt then stops half configured with No space left on device.

df -h /boot
sudo apt update
sudo apt install --install-recommends linux-generic-hwe-24.04
ls /boot/vmlinuz-*
sudo reboot

When the box comes back, confirm what changed and what did not.

uname -r
ip -brief link
lsblk
journalctl -k -b 0 -p err --no-pager

uname -r should print a higher upstream version than before. The network and disk listings should look exactly as they did, because the same virtual devices are still there. A missing interface here is the one failure that matters, since it usually means the box is reachable only from the provider console. journalctl -k -b 0 -p err prints this boot's kernel messages at error level, which on a healthy VPS is empty or close to it. Reading the kernel log on a VPS explains what the noisy lines mean. Do not delete the old kernel the same day. It is your way back.

How to go back if the new kernel misbehaves

The old kernel is still installed and still in the GRUB menu. Open your provider's console, reboot, and pick the previous kernel under "Advanced options for Ubuntu". Doing that once proves the old kernel still boots. Making the choice stick across reboots is a separate job, covered in pinning which kernel your VPS boots. If the machine never comes back and the console shows a GRUB prompt or a kernel panic instead, a VPS that will not boot after a kernel update walks the recovery path.

Once you are booted on a kernel that works, move the packages back.

sudo apt install linux-generic
sudo apt remove linux-generic-hwe-24.04 linux-image-generic-hwe-24.04 linux-headers-generic-hwe-24.04
sudo reboot

Removing the meta-packages stops the next enablement step from arriving. It does not remove the kernel image already installed, so nothing changes under a running system. After the reboot, confirm uname -r shows the GA version again, then run sudo apt autoremove --purge to clear the images you no longer boot. Ubuntu's kernel hook keeps the running kernel out of that list. Clearing old kernels out of /boot covers the harder case, where /boot filled up before you got here.

One last thing worth knowing: the track question resolves itself at the next LTS. Moving to the next LTS gives you its GA kernel, which is newer than the GA kernel you run today, and it restarts the support window. If point releases are on your mind because you are planning that move, upgrading 24.04 to 26.04 is the procedure. Staying on GA until then is a normal, defensible choice for a rented server.

FAQ

Does a point release change the kernel on a server I already installed?

Not on the GA track. A point release is mainly a refreshed install image, so it decides what a newly built machine gets. An existing server keeps whatever track its installed meta-package names. If a linux-...-hwe-... package is installed, then yes: the point release is when that package points at a newer kernel image, and your next apt upgrade installs it. The new kernel starts running at the next reboot, not at the moment apt finishes.

How do I tell whether I am running the HWE or the GA kernel?

Run apt-cache policy linux-generic linux-generic-hwe-24.04, with your own release number in place of 24.04. The package with a real version on its Installed: line is the track you are on. Do not try to read it from uname -r, because the running kernel name ends in -generic on both tracks and never contains hwe. If neither package is installed, run apt-mark showmanual | grep '^linux-', since some provider images use the linux-image-virtual family instead.

Is the HWE kernel less stable than the GA kernel?

Each enablement kernel is a supported Ubuntu kernel, so this is not a question of quality. It is a question of change. The GA kernel holds one upstream version for years, so the behaviour you tested against stays put. The enablement kernel moves to a newer upstream version about every six months, and each of those steps is a chance for a driver default or a sysctl to change under your workload. On a server you rarely touch, fewer moving parts is worth more than newer drivers.

Should my VPS use the HWE kernel?

Usually no. A virtual machine sees a fixed set of virtual devices, mostly virtio, whose drivers have been in the kernel for years, so the hardware support the enablement track exists to deliver buys a VPS nothing. The extra reboots are still real. Switch for a specific reason: a device the current kernel cannot drive, or a documented minimum kernel version for software you have to run.

What happens if I install the enablement kernel and never reboot?

The new kernel image is written into /boot and added to the GRUB menu, and your server keeps running the old one. uname -r is the truth about what is running, not the package list. Ubuntu creates /var/run/reboot-required when an installed package needs a restart to take effect, so ls -l /var/run/reboot-required tells you a reboot is pending. Until that reboot happens you carry the disk usage of the new kernel and get none of its fixes.