If you work as a system administrator, you’ve probably run into this situation before.
A security vulnerability is announced, a kernel fix becomes available, and suddenly you have another maintenance window to plan. You need to test the new kernel, check whether your applications are affected, schedule a reboot, and make sure everything comes back normally.
Now imagine having to make that decision more often.
Canonical is changing the way Ubuntu kernel updates are released. The new process will create a weekly kernel release cadence, while each individual kernel still goes through roughly a two-week SRU process.
Table of Contents
The Short Version
Ubuntu is moving from its current mix of:
- a four-week regular kernel SRU cycle
- a two-week security kernel SRU cycle
to a unified two-week SRU cycle.
Because a new cycle will start every week, multiple kernel releases will be at different stages at the same time.
One kernel can be going through certification testing while the next one is being prepared.
The result is a kernel release every week without reducing the overall testing process to seven days.
Why Is Ubuntu Changing the Kernel Schedule?
Kernel vulnerabilities are becoming harder to manage.
See also: Mastering the Linux Command Line — Your Complete Free Training Guide
Canonical points to two factors behind the growing number of CVEs: automated vulnerability discovery, including AI-assisted tools, and the Linux kernel community’s role as its own CVE Numbering Authority.
More vulnerabilities mean more patches.
But finding a vulnerability is only the beginning.
A kernel fix still needs to be integrated, built, tested, and checked for regressions before it can become a normal Ubuntu update.
That creates a familiar problem for Linux administrators:
The faster vulnerabilities are discovered, the faster fixes need to move through the release pipeline.
How the New Kernel Release Process Works
The new process is easier to understand if you think of it as overlapping two-week pipelines.
Week 1
Kernel update A → Preparation
Week 2
Kernel update A → Testing
Kernel update B → Preparation
Week 3
Kernel update A → Released
Kernel update B → Testing
Kernel update C → Preparation
Week 4
Kernel update B → Released
Kernel update C → Testing
Kernel update D → Preparation
The important part is that each kernel release still has a two-week process.
During the first week, Canonical prepares the kernel packages, integrates patches, builds the kernel, and performs initial checks.
The kernel candidate is then published in the -proposed repository.
During the second week, it goes through more extensive certification, integration, and regression testing.
After that, it can be released normally.
So the change is not:
Two weeks of testing
↓
One week of testing
It is:
Two-week cycles
+
Overlapping cycles
↓
Weekly releases
That distinction matters.
What Is the -proposed Repository For?
This is probably the most interesting part for administrators who need security fixes quickly.
Kernel candidates are published to Ubuntu’s -proposed pocket before the normal certification process is complete.
That gives organizations an opportunity to start their own acceptance testing earlier.
The normal path looks roughly like this:
CVE
↓
Kernel fix
↓
Build
↓
Testing
↓
Certification
↓
Ubuntu release
For organizations that need the fix sooner:
CVE
↓
Kernel fix
↓
Build
↓
-proposed
↓
Your own testing
↓
Decision
There is a trade-off here.
Using -proposed means getting access to the candidate earlier, but you are also taking on more of the testing responsibility yourself.
For a production server, that means you should have a clear testing and rollback process before using this approach.
What Does This Mean for Linux Administrators?
For desktop users, the practical difference may be small. You may simply see kernel updates more frequently.
For large server environments, however, the change is more noticeable.
More frequent kernel releases can mean more frequent decisions about:
- kernel compatibility
- application testing
- maintenance windows
- reboot scheduling
- monitoring
- rollback
And there is an important distinction between kernel availability and kernel deployment.
A new kernel being released every week does not mean every production server needs to run it immediately.
Many organizations will still want to test the kernel first and deploy it according to their own maintenance process.
Faster CVE Fixes Without Dropping Testing
Canonical’s goal is essentially to shorten the time between a security fix being prepared and a kernel containing that fix becoming available.
At the same time, Canonical says it will retain extensive certification and regression testing for the normal release process.
Canonical also says it aims to provide safe workarounds where possible while a kernel fix is being prepared. Where no workaround exists, it plans to provide hardening guidance instead.
That gives administrators several possible paths:
Wait for the normal release when stability and the standard Ubuntu testing process are the priority.
Test the -proposed kernel when getting a fix earlier is more important and you have the infrastructure to validate it yourself.
Use a mitigation or workaround when one is available while waiting for the proper kernel update.
