1y ago

Do new patches that are incorporated in the "stable tree" of older kernel versions make it back into the distros?

Hi! This is a bit of a newbie question, so please bear with me.

I purchased a laptop that has a specific hardware issue under Linux (the keyboard does not function). A patch fixing the issue was approved for 6.8 and incorporated in the "stable tree" of older kernels: 5.4, 5.10, 5.15, 6.6, 6.7, etc.

My question is: Do distros ship with an updated kernel that incorporates all the patches? Or does the user need to update after installation for the patches to be applied? I imagine that it may perhaps vary from distro to distro, but I honestly don't know.

The question is relevant for me because, potentially, I would have to install the actual distro and update, rather than just try out a live version.

You're viewing a single thread.

14 comments

The distros usually take care of that, often they add or backport additional patches too but the patches in the stable upstream kernel your distro kernel is based on are incorporated as well (unless there is specific reason to revert them because the patch is known to cause more issues than it fixes). Obviously only as long as the distro is fully supported, after that it might depend on the exact LTS policy or if it is completely out of support you should get a new version of the distro.
- This is an excellent answer. My eli5 addition is this:
  It depends on your distro. Distros that do more hand holding and more compatibility without additional operator involvement will be more likely to backport or use a stable kernel with backports like these. Examples: Ubuntu/Fedora/Mint. Distros that focus on system stability will take much longer to integrate backports like these, ex: Debian. And masochists will tell you to do it yourself, ex: lfs, arch.
  
  In Arch there are AUR packages for specific versions so you don't have to do it yourself. Arch is about picking and choosing your packages, but not really about actually building/patching things on your own like LFS or Gentoo.
  Although picking a rolling-release distro and then using an outdated kernel does seem counter-intuitive.
  
  This is one of those comments that causes Arch to get the reputation that it does. You aren't wrong and you probably don't intend to be off-putting but here we are.
  
  I don't understand. What is the problem with what I said? I am genuinely confused by your response.
  How is it off-putting that you can install a package with the exact version you want instead of doing it yourself? What you said puts more people off of Arch. You made Arch sound more complicated than it is.
  If I want say, the 5.10 LTS kernel I can do yay -S linux-lts510 and then I have it. One command. It is probably easier to switch to an LTS kernel on Arch than it is on Ubuntu or Debian. Saying Arch is for masochists does way more damage to its reputation than clarifying its usage does.
  
  Usually the more stable distros just use older LTS versions because their last major release is longer ago on average but they still release security fixes for those versions quickly (assuming a distro with the resources to handle security support at all).
  
  Red Hat and Debian both backport security fixes but don't backport things like laptop device support. It can take a year or more for versions of those distros to gain the kind of functionality that is looking for.
  
  They don't Backport them but they do incorporate them if they are already part of the upstream LTS kernel used by that distro.
  
  Have LTS kernels started backporting non security fixes like this? To be fair I haven't looked at this in over a decade but this kind of patch wouldn't have been backported then.
  
  Well, OP explicitly states that the patch for their issue has been incorporated into the stable trees for various older kernels.
- Thanks, I appreciate the comment. It is logical that there is not one-size-fits-all approach. I will dig into the specifics of distros of interest for more information.
- unless there is specific reason to revert them because the patch is known to cause more issues than it fixes
  Just experienced this for the first time on Debian last month. They had some issues with a kernel update corrupting some filesystems or something, and while the new kernel was right there available in the Discover app, they had blocked the download as an emergency measure.

14 comments