Why bother updating your Linux kernel?
Let’s begin with the fundamental question: why upgrade Linux kernel at all?
1. You gain access to the latest fixes and features
Keeping your kernel updated means benefiting from the newest features, improvements, and, most crucially, bug fixes contributed by the open-source community. And while today’s focus is the Linux kernel, the principle applies to the entire open-source software stack that makes up a Yocto-based distribution. The kernel is important, but it’s only one part of a web of dependencies.
Your system moves as fast as your slowest dependency. Updating keeps everything moving forward.
2. Security and vulnerability management
This is another big reason. If you walked the halls at Embedded World over the last 2 years, you couldn’t miss it. Security has become the core theme across the industry, especially with the European Cyber Resilience Act (CRA) now looming.
The CRA requires manufacturers to:
- Identify vulnerabilities,
- Track and classify them,
- Communicate about them,
- And fix them based on severity and risk.
A critical CVE cannot be treated like a minor one. To meet regulatory requirements and protect your customers, you need a system that is continuously updated and actively maintained – including Linux kernel upgrades.
3. Your application teams depend on up-to-date frameworks
Keeping your OS current also enables your application teams to work with modern frameworks, libraries, and toolchains. Outdated dependencies eventually block development. Upgrading your Linux kernel and base layers keeps the rest of your software stack healthy and functional.
Updating isn’t optional. It’s part of the lifecycle of any product built on open-source components.
Understanding Linux kernel and Yocto versioning
This is where teams often start feeling lost.
Active and inactive versions
Both the Linux kernel and Yocto use versions that can be in one of two states:
- Active (maintained)
- Inactive (end-of-life)
An active version continues to receive:
- Security patches,
- Bug fixes,
- Backports from newer versions.
An inactive version receives nothing. So, if a new vulnerability appears, you’re on your own.
Regular releases vs. LTS releases
Both projects follow a similar rhythm:
- Regular releases: short-lived, fast-moving, typically maintained for a few months.
- LTS (Long-Term Support) releases: maintained for years (Yocto: ~2 years, kernel: 2–6 years depending on the branch).
The crucial point is the overlap between maintained releases. This overlap is what gives industrial companies breathing room to migrate without rushing.
CIP: The “Super-LTS” option
The Civil Infrastructure Project (CIP), an initiative of the Linux Foundation, provides super long-term maintenance for some Linux kernel branches (typically for 10 years or more).
CIP is ideal for systems where:
- Long validation cycles make frequent updates impossible,
- Stability is more important than new features,
- Regulatory constraints demand predictable behavior,
- Updating the field population is expensive or complex.
Why teams choose CIP
- Long maintenance window.
- Minimal changes (low regression risk).
- Focused patching of high and critical vulnerabilities.
Where CIP becomes difficult
- Only a tiny ecosystem of components is included.
- Higher-level frameworks may become incompatible over time.
- Migrating after 10 years is a major undertaking: you may need to skip two or more kernel major versions at once.
CIP is powerful, but only if the rest of your software stack can tolerate a decade of minimal change.
Major vs. minor kernel updates
This distinction is essential to understand.
Minor updates
- Low risk and relatively easy to apply.
- Should be done regularly to stay secure.
Major updates
- May introduce breaking changes.
- Often require modifications to drivers, libraries, or application code.
- Represent a lot of engineering work.
- Become unavoidable when your current release reaches end-of-life.
Even with LTS, you cannot avoid major upgrades forever (unless you choose CIP and accept its trade-offs).
The maintenance supply chain
One of the most underestimated complexities is the multi-layer supply chain between mainline Linux and your product.
Here’s the typical chain:
- Linux mainline releases a version.
- Silicon vendors (NXP, TI, Renesas, etc.) adapt it into their BSP.
- SoM vendors (if applicable) customize that BSP for their modules.
- You, the product builder, integrate and adapt it to your device.
Each layer adds delays.
If each takes 1–2 months to update, the final release reaching you may be 6 months behind mainline, which directly delays your access to security fixes and modern features.
This is why some teams push toward mainline kernels when possible: you skip a large portion of this chain.
The 4 pillars of a good maintenance strategy
A sustainable kernel and OS maintenance strategy includes four main pillars.
1. Update regularly
Even if you don’t deploy every update to customers, keep your internal branches fresh.
Regular maintenance:
- Reduces merge conflicts,
- Maintains team expertise,
- Minimizes surprise regressions,
- Ensures fast reaction when a critical CVE appears.
Kamea platform can eventually help you with your update deployment.
2. Monitor vulnerabilities systematically
You need:
- CVE tracking,
- Impact analysis,
- Severity-based prioritization,
- A clear remediation workflow.
This is no longer optional for most industries. That’s why more and more solutions like CVEScan appears now on the market to simplify this vulnerability detection and lifecycle management.
3. Define your update deployment strategy early
Deployment frequency varies dramatically:
- Some customers deploy only major releases manually via USB sticks.
- Others push OTA updates weekly or even daily.
Your security requirements and business context define what makes sense.
4. Test everything
Every update, from a kernel patch to a recipe version bump, has the potential to break your system.
Automated testing (unit, integration, system, hardware-in-the-loop) is essential to keeping update cycles manageable and safe.
Frameworks like Pluma definitively help deploy automated suites of tests.
Best practices to upgrade Linux kernels
If you only take one thing from this article, take this list.
✔ Update frequently, not occasionally
Small updates are easier, safer, and cheaper than huge upgrades every two years.
✔ Prefer mainline kernels when possible
You reduce dependency on vendor roadmaps, delays, and custom BSP branches.
✔ Choose well-maintained packages and components
In Yocto, some recipes are extremely well supported; others are stagnant or poorly maintained. Choose wisely.
✔ Upstream your patches and backports
It reduces your long-term maintenance burden and aligns you with community evolution.
✔ Keep a dedicated meta-layer for your patches
Clear structure = fewer surprises.
✔ Start new projects on the latest Yocto LTS
Beginning on an outdated release guarantees more painful upgrades later.
✔ Favor hardware with mainline drivers
Driver maintenance is one of the biggest hidden costs.
Mainline-supported hardware massively reduces long-term risk.
✔ Budget for maintenance
Maintenance isn’t free, and it’s not optional.
Plan for it in your R&D budget from the start.
Conclusion
Maintaining and upgrading a Linux kernel in a Yocto-based system is not a one-off task, it’s an ongoing commitment. As regulatory pressures grow and security threats multiply, proactive maintenance becomes not just a competitive advantage but a legal requirement.
Whether you rely on mainline, vendor kernels, LTS, or CIP, your success depends on building a clear, consistent, and sustainable maintenance strategy early in the product’s lifecycle.
Regular updates, strong vulnerability monitoring, robust testing, and smart architectural choices will determine how stable, secure, and maintainable your embedded product will be over the years.
