Ubuntu Will Start Shipping With the Latest Upstream Linux Kernel - Even Release Candidates

Here's a question from the blog OMG Ubuntu. "Ever get miffed reading about a major new Ubuntu release only to learn it doesn't come with the newest Linux kernel?

"Well, that'll soon be a thing of the past." Canonical's announced a big shift in kernel selection process for future Ubuntu release, an "aggressive kernel version commitment policy" pivot that means it will ship the latest upstream kernel code in development at the time of a new Ubuntu release.

Yes, even if that upstream kernel hasn't yet seen a formal stable release (and received the requisite newspaper-graphic-topped rundown on this blog). Which is a huge change. Currently, new Ubuntu releases include the most recent stable Linux kernel release at the time of the kernel freeze milestone in the Ubuntu development cycle.
Here's the official announcement by Canonical's Brett Grandbois. "Ubuntu will now ship the absolute latest available version of the upstream Linux kernel at the specified Ubuntu release freeze date, even if upstream is still in Release Candidate status..." It is actually expected that Late Releases will be the exception rather than the norm and in most releases these guidelines will not be necessary as the upstream kernel will release with enough time for the Ubuntu kernel to stabilize. However, adopting a more aggressive kernel version commitment policy does require us to be prepared for a possible Late Release situation and therefore informing the community on what they can expect.

No Thanks

[banbeans]

I need out of the box stability not cutting edge!

Re:

[korgitser]

Ubuntu never was that, it has always been more or less cutting edge. For one, it's based on Debian unstable. Now with even more cutting, i guess.

Re: No Thanks

[Roadmaster]

Ubuntu mirrors Debian testing, not unstable.

Financial auditors won't approve this

[will4]

Large companies need special approval from auditors to run pre-production alpha/beta/release candidates for financial systems and other critical systems.

Directly including them in your current release without marking that release as pre-prod/beta/RC is unhelpful.

Re:

[tlhIngan]

Large companies need special approval from auditors to run pre-production alpha/beta/release candidates for financial systems and other critical systems.

Directly including them in your current release without marking that release as pre-prod/beta/RC is unhelpful.

If this is the case, you shouldn't be running the latest bleeding edge releases. Even LTS releases - to run LTS 24.04 is still kind of silly - I would probably upgrade in 2025 so it's had time to settle out.

The main reason for the prerelease kernels

Re:

[arglebargle_xiv]

It's not even cutting edge, I don't know how many devices I have where any attempt to update them - and that's not on the LTS channel - just gives "The following packages have been held back" and no update. From extensive searching for how to fix this the consensus seems to be "keep on waiting"... at which point the signing keys for various things have expired and you have to engage in further hackery just to get other packages that aren't being held back to update.

My experience has been different.

[Brain-Fu]

You might be right. But Ubuntu has been solid as a rock for me.

By contrast, back when I used Fedora, upgrades were always an adventure. Minor upgrades broke random things and sometimes I could fix them and sometimes I just had to wait for the next minor upgrade. Major upgrades invariably turned my pc into a brick and required a full wipe and reinstall. I was using a Fedora "spin," but I wasn't tricking it out in any way.

Ubuntu upgrades have never once broken anything for me, including major upgrades.

I d

Re:

[Anonymous Coward]

If the operating system is hosed then your computer is not bricked. Bricked would mean we’re breaking out the SPI flash kit to load new bios.

Re:

[fahrbot-bot]

Ubuntu never was that, it has always been more or less cutting edge. For one, it's based on Debian unstable. Now with even more cutting, i guess.

Hopefully, always with less Edge. :-)

Re: No Thanks

[godrik]

I moved away from Ubuntu years ago because of shit like that.
I have been a Debian Stable user since 2009 and I have never looked back!
No thanks on experimental packages in my LTS!

Re:

[sg_oneill]

Debian has your back hombre. If you can do ubuntu, you already know how to do Debian, and its a fair bit more conservative about package tracking, opting more for stability over latest and greatest.

Re:

[slashdot_commentator]

Debian will never be Ubuntu "adjacent", because Ubuntu will make accessible non-open license software available for an Ubuntu distribution, which Debian never does. While I am thoroughly in disagreement with Ubuntu's change of policy for LTS kernels, I'm not going to deceive casual users into adopting Debian over Ubuntu, only to find its more work without satisfying their user requirements.

Re:

[sinkskinkshrieks]

Ubuntu doesn't really grok LTS. Abandon it and use CentOS/RHEL.

Geting miffed and latest kernel :o

[Mirnotoriety]

“Ever get miffed reading about a major new Ubuntu release only to learn it doesn't come with the newest Linux kernel?”

No, as a Linux user I can upgrade to the latest kernel all by myself.

How to Update Linux Kernel In Ubuntu [phoenixnap.com]

Re:

[noshellswill]

Download my own Linux kernel? As a casual linux lusr I upgrade only thru the UBUNTU update prompts. Fear to get a BSOD from strange software, kernel or otherwise. I don't need or want the latest-and-greatest, but need bullet-proof stability. Like most CLLs my command-line skills are marginal. The last time I ventured into that territory I DDed one hard-drive to a new one ... truly fear-inducing. Sadly, Canonical long ago dropped interest in us lusrs.

Re:

[markdavis]

>" No, as a Linux user I can upgrade to the latest kernel all by myself."

^This, sorta.

Perhaps a better approach would be to ship with a stable/vetted kernel *AND* make an option for bleeding edge kernel that can be loaded, instead.

Canonical seems to want to succeed in the EL (enterprise linux) area. Throwing in release-candidate kernels on critical production machines is completely antithetical to that space.

Re:

[slashdot_commentator]

Canonical seems to want to succeed in the EL (enterprise linux) area. Throwing in release-candidate kernels on critical production machines is completely antithetical to that space.

Yes and no. Companies that pay Canonical for technical support don't really care that the bleeding edge kernel is not thoroughly tested. What they do care is that whatever version of Ubuntu they deploy in production works as flawlessly and as uncompromised as possible. If the "blessed" kernel version definitely has an intolerable deficiency, they're going to require Canonical to provide the fix as quickly as possible, even if its "bleeding edge". Service is what companies are paying Canonical for.

I am m

Bad idea

[jd]

Canonical lack the QA team needed to ensure quality releases, and lack the kernel developers to fix issues fast. This will hurt Ubuntu's image amongst users and image is nine-tenths of the law.

The reason I put strong warnings on the FOLK distribution patches was because those were cutting-edge and included drivers and features from a wide range of sources and I simply didn't have the resources to prove the result would be of acceptable quality. I do not regret that, although it limited the userbase. Better to have people avidly interested in experimental ideas look at experimental ideas, because they know the risks. Average users do not.

Canonical thinks it can out-do those in charge of the staging and releasing of kernels. That is an arrogance that the userbase will respond to, on first disaster. And there will be disasters.

Re:

[slashdot_commentator]

Canonical lack the QA team needed to ensure quality releases, and lack the kernel developers to fix issues fast.

On what basis do you make your evaluation? Canonical should be hiring enough QA personnel to manage the requirements of their paying customers. If they can't hire enough QA to manage the myriad of Ubuntu released application issues to their paying customers satisfaction, then that is the unavoidable situation that both paying customers and Canonical have to live with.

This will hurt Ubuntu's image amongst users and image is nine-tenths of the law.

Not with production companies contractually obligated to provide a level of service. Image cannot dictate reality because it is not reality

Is Ubuntu going to get Crowdstriked?

[xack]

Since Ubuntu gets used in many enterprise and embedded devices it seems that it will take one buggy release candidate to cause mass crashes in production machines. Looks like all those who had already migrated from IBMs Linux distros need to migrate again. Reminder that Windows 11 gets away with being shitty due to buggy Linux distros.

Re:

[Dragonslicer]

Highly doubtful. If you're using Ubuntu in a production environment (and have any clue what you're doing), you only using LTS versions. Upgrades from one LTS version to the next LTS version generally aren't enabled until about 4 months after the newer LTS version is released. So if there are any bugs with the kernel on release day, they'll be fixed long before you're upgrading your production environments.

Re:

[slashdot_commentator]

So if there are any bugs with the kernel on release day, they'll be fixed long before you're upgrading your production environments.

You do realize that if management wants production to support a feature dependent on non-stable software components, production is going to do as management directs them? (Of course, this (hopefully) wouldn't happen at a major bank (let alone securities trading company)...)

Only a resource starved, non-tech small company is going to wait until the *.1 LTS version (while hopefully evaluating the new LTS in the meantime). An actual tech company that provides services will probably more aggressively try to me

Re:

[Kernel Kurtz]

Looks like all those who had already migrated from IBMs Linux distros need to migrate again.

Just switch to Rocky or Alma and be done with it the first time.

No?

[Pinky's Brain]

"means it will ship the latest upstream kernel code in development at the time of a new Ubuntu release."

"An upstream kernel that has a merge window 5 opened after Feature Freeze 2 is considered to be too unstable and its eventual release too far in the future to adopt in the pending Ubuntu release. Put another way, an upstream kernel not in active development by Feature Freeze will not be considered for an Ubuntu release."

One is not like the other.

Fucking bad idea

[Tough Love]

Do not ship with pre-release kernels by default!

Do make pre-release kernels easily installable by default. Tattoo that on your butt. Thxbai.

Sounds like they're doing this with LTS too

[93 Escort Wagon]

This just seems like a really poorly-thought-out plan that runs completely orthogonal to the reason LTS releases exist in the first place.

What's the over/under on the number of weeks before Canonical announces it's trimming staffing levels? Because, on the face of it, this sounds like a move intended to lower the amount of person-hours Canonical has to spend prepping releases.

Two months?

[bill_mcgonigle]

Do we ever have a merge/release date more than two months out?

I think people here think the article means Ubuntu will always follow the bleeding edge but what it actually means is that within 1-2 months of a new Ubuntu release everybody will be on -release but with the latest that was in development when the Ubuntu release happened.

TFS could have been much more clear.

We need more unit tests, more CI, and fewer actual releases, in the long run.

I remember having to wait for my monthly Infomagic CD subscription to arrive. Huge releases made sense then.

Hmm...

[chrish]

Are they going to be packaged as Snaps?