How to request for LTS kernel?

I have been using Fedora for last 8 years. As much as I love Fedora for it’s userland stability, I equally hate it when every alternate kernel versions break my hardware. For example I’m tired of kernel updates breaking display, bluetooth, sound and more recently suspend/resume (Kernel 6.16.x). As I become older, I can see the point of Debian and other LTS distros. I don’t have time and energy to continue to research hours or weeks for workarounds. I just want my PC to work reliably on every morning for remaining of my life.

So before I jump to totally different distro and losing all the investment (time, energy, knowledge) I made with Fedora for past decade, how can I request the Fedora Project to offer LTS kernel in the official repos? I don’t have enough knowledge to even write an official proposal.

I know there are some COPR repos that offer LTS but I could not make any of them work. Some don’t work with Secure Boot.

Any help would be great. Thanks.

9 Likes

As reliable as kwizard is maintaining them, I indeed would not suggest to rely on them, as there is not a QA and massive testing as at our official kernel contained. So it can be questioned if the major idea of an LTS kernel is covered when relying on the informally created LTS builds.


This topic came up often over time. It would indeed be nice to have an official LTS kernel, but this is to some extent contrary to the Fedora Project, and it would need a lot of resources to maintain it reliably to the level of the normal official kernel: Therefore, this can only start if you are (or found someone) who maintains such a kernel over time in a dedicated SIG and start collaborating with others to integrate it into the wider community and in QA. A lot of people would need to support this, and be ready to contribute resources, if it shall be reliable to the “official” level.

After allocating the major tasks and forming a SIG, the next step would be to find out how this could be embedded in the wider community, into QA, and how far others are interested in collaborating in terms of responding if an issue rises → embed into Fedora QA & issue handling, maintenance, etc.

My experience is that it takes years in which something (e.g., Silverblue, KDE or so → a kernel is impactful, so I don’t compare it with another package but rather a variant; still limited comparability, I know) has to be reliably embedded and maintained and proven able to respond when necessary until it is put to the “officially Fedora” section.

I presume the major reason why support is limited is that the official answer about LTS is, in short, CentOS or AlmaLinux or Rocky Linux.

I understand the desire for a Fedora userspace with an LTS kernel, but I am not sure if it is realistic at the moment to get everything together that would be necessary for that: I don’t think the demand is big enough nor are the returns of (resource) investment for people providing it.

However, I put this to the Project Discussion category to give it the possibility for review and see if others from the project want to say something more detailed about the backgrounds or maybe even think it could become possible. My perception is indeed that the issues with using always the most recent kernels have increased over time (this perception is both subjective and based on a “selective” set of data from Discourse and such though). In any case we have to keep in mind that what comes up in Discourse is just a small amount of the users of Fedora, and there will be always someone who experiences an issue when something is updated → that’s code.

I presume in the above you are asking for an official LTS kernel, beyond someone informally creating copr builds, because of your elaboration of the goals you want to achieve. Also, it should be clear that the above strongly simplifies, but I wanted to give an incentive of the overall issue and relations

2 Likes

As a completely unofficial answer: Fedora won’t do it.

I too have had broken kernels recently, but the previous and following kernel always work again.

Simply reboot with the other kernel and don’t worry about it.

You could go CentOS etc, the price of this is missing out on a lot of great software.

1 Like

I think the correct name for the latter is:

I would very much welcome having the most recent Linux LTS kernel available in the official packages in Fedora. Not having an LTS kernel available is a major downside in case you get affected by a new kernel bug. Even rolling release distros like Arch offer one and for good reason.

One of my laptops was affected by a kernel bug, which let to a frozen system in some common use cases. It took a very long time to fix this bug. Thankfully this system ran Arch Linux during that time, which has provided an LTS kernel via their official repos, so switching to a working, still up-to-date kernel was easy. If this had not been the case, the options would have been pretty bad:

  • Stick to a working version and don’t update the kernel. Should never be an option for security reasons.
  • Update the kernel and live with the inconveniences. Not an option because some of my work wouldn’t have been possible for months
  • Compile the LTS kernel yourself. Not an option for most users.
  • Use a build of some random guy on the internet. Would you trust them with the most security critical part of your system? I wouldn’t.
  • Switch to a distro with a LTS kernel, which would have wasted a significant amount of time and probably wouldn’t switch back afterwards. That’s a good way to lose otherwise happy users.

Most Fedora users want reasonably up-to-date software, which non of these options would provide. The most recent LTS kernel would still be an upgrade over older vendor kernels according to Vendor Kernels, Bugs and Stability:

A vendor kernel is an insecure kernel. A late cycle stabilized vendor kernel is doubly so.

1 Like

True! Typo :face_with_peeking_eye: I also forgot the space in between the words :zipper_mouth_face: corrected, thanks :slight_smile:

1 Like

Even rolling release distros like Arch offer one and for good reason.

@powerhouse Agreed. Debian offers multiple kernels in official repos. NixOS offers both LTS and latest versions. They do it for a reason. A computer that does not work is no good for anyone, no matter how polished UI is.

I too have had broken kernels recently, but the previous and following kernel always work again.

@theprogram No, not in my experience. I had to override the kernel for 6 months in Silverblue. Some problems exists for years. I will never recommend Fedora for a family member or non tech savvy. It WILL break in one of the updates for sure.

I presume the major reason why support is limited is that the official answer about LTS is, in short, CentOS or AlmaLinux or Rocky Linux.

@py0xc3 These distros are targeted for those who don’t want any change except security updates. They do not support seamless major version upgrade and misses so many packages in my experience. For my usecase, I want latest container technologies like Podman and latest libraries. Those enterprise distros do not offer what Fedora offers.

As bad as my opinion sounds, Fedora won’t be successful for desktop usage (I mean for non tech savvy users) without offering solutions to fix kernel regressions which are very common. I want Fedora to be successful since it’s where innovation is happening, but not at the expense of broken computer.

2 Likes

I did a quick LLM check and asked ChatGPT to categorize the kinds of bugs reported on https://discussion.fedoraproject.org/ website. I’m sure it’s questionable, biased and not accurate. But even a rough number can provide some insights.

Bug Category Estimated Percentage
Kernel Bugs 25%
Regressions 20%
Performance Issues 15%
Hardware Compatibility Issues 10%
User Interface Bugs 10%
Application Bugs 10%
Installation Issues 5%
Network Issues 3%
Security Vulnerabilities 2%
1 Like

Maybe I’m on the wrong path.

But for this, we have the selection option during boot to use the previous working kernel. That’s as simple (or not simple) as the Windows recovery instructions. And those are considered very suitable for non-technical users.

And besides the number of questions: How often did we have a non-booting kernel after an update over the last 12 months? With Server, I remember 1 time (on an aarch64 SBC in special configuration).

That’s only a good solution, if the bug is fixed within a short period of time, otherwise you end up running an outdated vulnerable kernel. The problem is that there are bugs introduced with each kernel release which can take a long time to fix. For these, switching to an LTS kernel would be a much better solution.

2 Likes

I usually use openSUSE Tumbleweed, had 6.16 for a while, and haven’t noticed a kernel-side issue on 8th-gen Intel or X470 Ryzen for years (had AC 9560 wifi for years but had AX210 for a couple weeks no problem too).


I don’t entirely think Fedora’s fast-moving model benefits from a slow-moving LTS kernel, but I know Arch was behind openSUSE on some updates with kernel/GNOME due to reports of instability, implying they don’t deploy updates until tested. Is Fedora shipping latest kernels without real-world testing prior/using users as the testing?

Just to mention that this is not a real Fedora Issue, it is more likely that the kernel for it selves has issues and missing devs which are fixing it before release a new version.

If you look on kernel org, you can see that the Kernel comes as a tarball and has patches and even inc.patches (incremental patches) This way when patches not are included in a higher kernel version we get regressions which cause this hick ups of working kernels, which where ok in lower versions.

There was an example this week, where even users from Arch linux posted same issues we had. This shows that it is missing code patches being included on kernel org. Might be that the way as it is done for the moment needs some adjustments?

So, you might test the LTS from copr again

Adding just my two cents here regarding the copr LTS. I’ve just removed both the corp repo and the package for that today, as it’s somewhat “unfriendly” with the Fedora’s officially provided akmod Nvidia drivers (akmod-nvidia)

What I mean by that is, kmod never got installed for the 6.12 LTS (made sure installing kernel-devel for LTS version), and not even manually triggering sudo akmods --rebuild --force --kernels 6.12.44-200.fc42.x86_64 generated the kernel modules against the LTS variant.

But as a footnote, maybe with non-Nvidia systems (AMD or intel), LTS from copr might be a working option.

Just added this here, for any fellow Nvidia users out there.

2 Likes

There is a (rather extensive) QA system for the kernel (for all packages, but the kernel, and some other critical path packages are special), but it can not test all possible scenarios (too much variability in the community).

All updates go through the Fedora updates system (bodhi), which allows one to test and provide comments and up/down votes before moving to stable. Major version upgrades (6.x → 6.(x+1)) go through additional kernel test days. Minor updates (6.x.1 → 6.x.2) typically only go through bodhi. In most cases (security fixes excepted), the timeframe for a kernel minor update is a few weeks for testing before stable.

However, that does require those who care about kernel updates to actually test, and the testing is only as good as the user community cares to test (as Fedora is about the community participating in the process).

5 Likes

FWIW, Fedora does not provide those, rpmfusion does (Fedora just makes it (reasonably) easy for individuals to choose to enable the 3rd party repo which is supported by the 3rd party). If you have issues with that 3rd party repo, you should open tickets with them for assistance. As I understand it, the nvidia akmod package from rpmfusion has a long history of needing tweaks for various building/packaging issues that have been encountered. Your copr kernel may have encountered one of the edge cases that need to be addressed.

One problem on any distro is that some bugs are hardware dependent. These are difficult to test without access to the hardware. It might take quite some time until upstream fixes these, especially on seldomly used hardware.

1 Like

Ok but what about with this latest IPv4 bug, where people’s internet connection (incl. me) behave unstable, and constantly made websites unreachable due to packet loss? I mean, that’s a pretty basic stuff to test against at the first place. For example, before I dug deeper here on forums, I pinged a remote server I own and noticed a lot of packet losses, and that was something made me to start curating on forum whether it’s on my end or not. So, if a single ping could trigger my 6th sense, I think implementing this practice to QA might be a good idea, to further isolate these kind of minor issues in the future.

Thanks for the clarification. Yeah, I usually do report these kind of bugs when I have enough capacity.

1 Like

Is there a specific recent example?

I see newer AMD GPU issues, but have to imagine someone has access to newer hardware for both users to report the issues on newer kernels, and the devs making the changes.

Particularly it sounds like recent hardware with the recent issues should have changes vetted more-thoroughly before they’re deployed to users (give a distro kernel maintainer a recent dual-graphics AMD laptop); or stuff like AMD or wifi AX-specific kernel-side changes applied separately from the main kernel update if the upstream changes sound like they’d cause issue (anything PSR), or louder test-day calls when upstream changes like that happen so more users can be encouraged to test it.

1 Like

The bug is real (every kernel, including LTS versions has bugs), but it’s impact clearly varies.

Did you test during the bodhi testing period and report the regression?

The QA testing does include some basic networking functionality (and it presumably passed that basic testing), but I see no reason your contribution to extend and enhance the testing would not be reviewed.

Someone did report a networking issue during the test period. The initial report is a little vague

It seems USB Ethernet or related not working properly. Works with 6.15.10.

…but the same user followed up by raising a more detailed RHBZ ticket.

As far as this particular regression is concerned, it had already been logged in kernel Bugzilla as a regression about a week before the kernel was pushed to stable in Fedora.

Ideally that kernel bug report would have served as a signal that we should hold off on pushing 6.16.3 to stable (or to patch it and push the patched version). After all, 6.16.1 and 6.16.2 never got to stable Fedora, so presumably those were considered not ready for prime time - it’s not like there’s a policy requirement to push every kernel version to stable.

2 Likes