Ubuntu kernel updates: the SRU cycle explained

The short answer

Ubuntu kernel updates arrive as SRUs (stable release updates): tested kernel builds that Canonical publishes for a released version of Ubuntu. On 2026-09-23 Canonical announced a new kernel release schedule that publishes a kernel every week. A kernel only takes effect after a reboot. On a VPS, the real work is to notice when a new kernel is waiting and to reboot into it at a time you choose.

The install is the easy part, because unattended-upgrades already handles it. This guide covers how a kernel moves through the Ubuntu archive and what changed in September 2026. It then covers the operator side: how to see a pending reboot, how to schedule reboots, what Livepatch does between them, and how to stop old kernels from filling /boot.

What is a kernel SRU in Ubuntu?

An SRU is any update to a package in an Ubuntu release that is already out. Most packages go through SRU review one bug at a time. The kernel is different. The Ubuntu kernel team runs it on a fixed schedule called the kernel SRU cycle. Each cycle collects upstream stable fixes and security fixes. The team builds and tests every supported kernel, then releases them together.

The pockets a kernel passes through

The Ubuntu archive splits each release into pockets. A pocket is a separate channel of packages for the same release. For Ubuntu 24.04 LTS (long term support), codename noble, four pockets matter for the kernel:

• noble: the release pocket. It is frozen on release day and holds the kernel the release shipped with.
• noble-proposed: candidates. A new kernel build lands here first, before certification testing. A normal server does not have this pocket enabled.
• noble-updates: tested updates for everyone. A kernel moves here when its cycle finishes testing.
• noble-security: security fixes. A kernel build that carries security fixes is published here as well as in noble-updates, and almost every kernel cycle carries some.

The -security pocket is the one that matters for automatic updates. The default unattended-upgrades configuration installs from -security. When Ubuntu Pro is attached, it also installs from the ESM (expanded security maintenance) pockets. It does not install from -updates. Kernels still reach a default setup because they are published to -security too.

You can see which pocket offers your kernel:

apt-cache policy linux-image-generic

Use your own metapackage name in place of linux-image-generic. The next section shows how to find it. The output lists an Installed version, a Candidate version, and a version table. Each line in the table names the pocket that offers that version. The line marked with *** is the version you have. If the candidate is newer than the installed version, a kernel is waiting to be installed.

The metapackage your VPS tracks

A kernel package carries its ABI (application binary interface) number in its name, in the form linux-image-<version>-<abi>-<flavour>. When the ABI number changes, the new kernel is a new package with a new name. It is not an upgrade of the old package, so something has to pull it in.

That is the job of a metapackage. A metapackage is an empty package whose only content is a dependency on the current kernel. When the kernel team ships a new ABI, the metapackage gets a new version that depends on the new kernel package. apt upgrade then installs the new kernel next to the old one.

apt list --installed 'linux-image*' 2>/dev/null

Look for the entry with no version number in its name. That is the metapackage, and its name tells you the flavour: generic, virtual, kvm, a cloud name such as aws, or a name that ends in hwe-24.04. That last one means the server tracks the HWE (hardware enablement) kernel series, which moves to a newer upstream kernel during the life of the release. The GA (general availability) kernel stays on the version the release shipped with. The difference, and how to switch, is in HWE vs GA kernels on Ubuntu Server.

What changed in the Ubuntu kernel SRU cycle on 2026-09-23

On 23 September 2026 Canonical published Accelerating delivery of CVE fixes with a new Kernel release strategy. In its own words, Canonical is "outlining a transition from its current 4-week regular and 2-week security kernel Stable Release Update (SRU) cycles to a unified, rapid 2-week SRU cycle, published weekly."

Before this change there were two separate tracks. Regular kernel SRUs ran on a four-week cycle. Security kernels ran on a two-week cycle. The new model replaces both with one two-week cycle. The post explains how one two-week cycle produces a weekly release: "These recurring 2 week cycles cascade: each cycle begins the week after the previous one starts. Because of this overlap, kernel releases will take place weekly."

Each cycle has two phases, according to the post:

• Week 1: "A 1-week kernel preparation phase with builds and basic checks to confirm kernels boot and run with no obvious issues. By the end of this stage builds are published in -proposed".
• Week 2: "Extensive certification, distro integration, and regression testing. By the end of this stage all test artifacts are completed".

So a given kernel still spends about two weeks between build and release. What changes is that a new one finishes every week. The post also says that users "who are extremely sensitive to turnaround times can begin their own kernel acceptance tests using updates available in the -proposed pocket". Do that on a separate test machine. Do not enable -proposed on a production VPS, because it also offers candidate versions of every other package in the release.

Canonical gives the reason as CVE (common vulnerabilities and exposures) volume. The post says the increase "is fueled by artificial intelligence", because language models and AI agents now find bugs much faster. It also points out that the upstream kernel community became its own CVE Numbering Authority and now assigns CVE identifiers to thousands of kernel bugs.

What the announcement does not say

The post does not say which kernel flavours or which Ubuntu releases the new cycle covers. It does not give a date when the new cycle takes effect. This guide does not guess at any of those. The Ubuntu kernel team posts its SRU cycle schedules on Ubuntu Discourse. Search there for the kernel SRU cycle threads to find the current dates and the kernels each cycle includes.

What is safe to plan for: if your kernel is in a weekly cycle, a new kernel can be installed on your VPS every week, and each one asks for a reboot.

What a weekly kernel means on one VPS

Installing a new kernel does not change the kernel that is running. The new files go into /boot, and the old kernel keeps running until the next reboot. Until then, the fixes in the new package protect nothing. A server that installs a kernel every week but reboots once a quarter runs a kernel that is up to three months old.

How to tell if a reboot is pending

Start by comparing the running kernel with the installed ones:

uname -r
ls /boot/vmlinuz-*

uname -r prints the running kernel. If the newest vmlinuz-* file in /boot has a higher version than uname -r, a newer kernel is installed and waiting.

Ubuntu also keeps a flag file for this:

cat /var/run/reboot-required
cat /var/run/reboot-required.pkgs

A package that needs a reboot creates /var/run/reboot-required when it is installed, and adds its name to reboot-required.pkgs. A new kernel always does this. If both files are missing, cat reports No such file or directory, which means no package has asked for a reboot since the last boot. The files live under /run, a memory-backed file system, so a reboot clears them. The same file drives the *** System restart required *** line in the login message.

needrestart checks the kernel directly. It ships with Ubuntu Server. Minimal and some cloud images may need sudo apt install needrestart first.

sudo needrestart -k -b

-k checks only the kernel, and -b prints machine-readable lines instead of an interactive screen. Look at two lines: NEEDRESTART-KCUR is the running kernel, and NEEDRESTART-KEXP is the kernel needrestart expects you to be running. If they differ, a reboot is pending. The NEEDRESTART-KSTA line is a status code. The meaning of each code is in man needrestart.

Set a reboot window with unattended-upgrades

unattended-upgrades can reboot the server for you after it installs a package that asks for a reboot. Put your settings in a separate file instead of editing the package file 50unattended-upgrades. That file is a configuration file owned by the package, so editing it causes a prompt on a later upgrade. apt reads the files in /etc/apt/apt.conf.d/ in name order, and a later value for the same option wins. A file named 52... therefore overrides 50....

sudo tee /etc/apt/apt.conf.d/52unattended-upgrades-local >/dev/null <<'EOF'
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:30";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
EOF
apt-config dump | grep -i 'Unattended-Upgrade::Automatic-Reboot'
apt-config dump | grep -i 'Remove-Unused-Kernel'

The two apt-config dump lines should print your four values. If a line still shows an old value, another file later in the name order sets it again.

What each option does:

• Automatic-Reboot "true" makes unattended-upgrades reboot when /var/run/reboot-required exists at the end of its run.
• Automatic-Reboot-WithUsers "true" reboots even when a user is logged in. Set it on a server. If it is false, one forgotten SSH session blocks every automatic reboot.
• Automatic-Reboot-Time "03:30" schedules the reboot for that clock time instead of rebooting the moment the upgrade finishes. The time is the server's local time, so check the time zone with timedatectl.
• Remove-Unused-Kernel-Packages "true" removes kernels that are no longer needed. It is already the default on current Ubuntu releases. Setting it here makes the choice visible.

The upgrade itself runs from a systemd timer. systemctl list-timers apt-daily-upgrade.timer shows when it runs next. If the upgrade runs in the morning and your reboot time is 03:30, the reboot happens at 03:30 the next night. When a reboot is scheduled, shutdown --show prints the time.

To check what unattended-upgrades would do without changing anything:

sudo unattended-upgrade --dry-run --debug

Look for the list of allowed origins near the top. It should include the -security pocket. Then look for the packages it would upgrade.

Two cautions. First, an automatic reboot means a minute or two of downtime at that time in every week a kernel lands. Choose a time when that is acceptable. Second, a reboot into a new kernel can fail. Before you turn this on, make sure you can reach your provider's web console, and read what to do when a VPS will not boot after a kernel update. If one kernel version is known to be bad for your workload, you can pin which kernel boots on the VPS while you wait for the next one.

If a weekly reboot is too often for your service, leave Automatic-Reboot off and reboot by hand on a fixed day. The full set of unattended-upgrades options, including email reports, is in the unattended-upgrades guide for Ubuntu.

What Livepatch covers between reboots

Livepatch applies fixes to the running kernel in memory, with no reboot. It is part of Ubuntu Pro. As of October 2026, Ubuntu Pro is free for personal use on a small number of machines. Ubuntu Pro on a server covers the terms and what else it turns on.

sudo pro enable livepatch
sudo canonical-livepatch status --verbose

The status output tells you whether your running kernel is supported, and lists the fixes that are applied. If the kernel is not supported, Livepatch applies nothing to it.

What Livepatch covers: fixes for high and critical kernel CVEs, where a fix can be applied safely to a live kernel. What it does not cover:

• Every other change in an SRU. Bug fixes and lower-severity fixes still need a reboot into the new kernel.
• The installed package. Livepatch does not change uname -r, and it does not remove /var/run/reboot-required.
• Old kernels without limit. Each kernel receives live patches only for a limited time. After that, the status output tells you to move to a newer kernel.
• Kernels it does not support. A custom kernel, or a container VPS that shares the provider's kernel, gets nothing.

So Livepatch lets you reboot on your schedule instead of on the day a serious CVE is published. It does not remove the need to reboot. How the patching works, and how to read the status in detail, is in live kernel patching on a VPS.

Keep /boot clear of old kernels

Each kernel adds a vmlinuz file and an initrd.img file to /boot, and the initrd is the large one. Weekly kernels mean more of them, and some VPS images put /boot on a small separate partition.

df -h /boot
dpkg --list 'linux-image-[0-9]*' | grep '^ii'
sudo apt autoremove --purge

If df shows the same file system as /, there is no separate /boot partition and space is rarely a problem. The dpkg line lists each installed kernel. apt autoremove --purge removes the kernels apt no longer needs.

apt never removes the running kernel, and it keeps the newest installed kernels as a fallback. This creates a trap on a server that is never rebooted. The old running kernel stays protected while new kernels keep arriving, so autoremove frees less space each week. Reboot first, then run autoremove.

When /boot is full, the next kernel install fails while it builds its initrd. Look for No space left on device followed by a line like update-initramfs: failed for /boot/initrd.img-<version> with 1., and then E: Sub-process /usr/bin/dpkg returned an error code (1). The fix, step by step, is in how to clean up old kernels on Ubuntu.

A weekly kernel routine for one VPS

1. Leave unattended-upgrades on, so each new kernel from -security is installed within a day of release.
2. Choose how reboots happen: an Automatic-Reboot-Time window, or a fixed day when you reboot by hand.
3. After each reboot, check that uname -r matches the newest vmlinuz-* in /boot, and that systemctl --failed lists no failed units.
4. Run sudo apt autoremove --purge and check df -h /boot.
5. Between reboots, check canonical-livepatch status if you use Livepatch.

To check whether the kernel you are running is exposed to a specific CVE, see how to check your server for known CVEs.

When the kernel is not yours: container VPS

Some VPS plans are containers, not virtual machines. Run systemd-detect-virt. If it prints lxc or openvz, your server shares the provider's kernel. uname -r then reports the host kernel, and the linux-image packages inside the container do not change the kernel that runs. Updating and rebooting the kernel is the provider's job, and so is Livepatch. On a KVM VPS, where systemd-detect-virt prints kvm, everything in this guide applies.

FAQ

How often does Ubuntu release kernel updates now?

Canonical announced on 23 September 2026 that it is replacing its four-week regular kernel SRU cycle and its two-week security cycle with one two-week cycle. The cycles overlap, and each one starts one week after the previous one, so a kernel is published every week. The announcement does not say which releases or kernel flavours are covered, or when the change starts. Check the kernel SRU cycle threads on discourse.ubuntu.com for the current schedule.

Does unattended-upgrades install new Ubuntu kernels automatically?

Yes, with the default configuration. unattended-upgrades installs from the -security pocket, and kernel builds that carry security fixes are published there as well as in -updates. It does not reboot by default, so the new kernel waits in /boot until you reboot. Set Unattended-Upgrade::Automatic-Reboot "true" and Unattended-Upgrade::Automatic-Reboot-Time to have it reboot at a fixed time.

Do I still need to reboot if Livepatch is enabled?

Yes. Livepatch applies fixes for high and critical kernel CVEs to the running kernel. It does not apply the other fixes in a kernel SRU, and it does not change the installed kernel version. Each kernel also gets live patches only for a limited time. Livepatch lets you choose when to reboot. It does not replace the reboot.

Why does a kernel update fail with "No space left on device"?

The /boot partition is full, so the new initrd cannot be written and update-initramfs fails. This happens most on servers that install kernels often but rarely reboot, because apt never removes the running kernel. Reboot into the newest kernel, run sudo apt autoremove --purge, and check df -h /boot before the next kernel arrives.