The thing with old kernels


Currently we have two issues, which might give us the need to drop old kernels.


Here a backport breaks some extramodules like catalyst and nvidia. This means v4.4.167 was the last kernel I was able to compile all additional modules as usual. It might take a while until Nvidia might adopt to those changes if ever.

QT 5.12 LTS

This is much more an issue than the one with linux44. Here we have now the minimum kernel as linux411 due some ABI/API changes in qt5. This would automatically kick out any kernel under linux414.

EOL kernels

Also we still have some kernels, which are end of life tagged. Removing also them will end in linux414, linux419 and the upcoming linux420 as our kernels. So we have to see on how we deal with that …

when is 4.14 EOL ? it's a LTS version...
[Testing Update i686] 2018-12-19 to 2019-01-25 - Systemd, Kernels, LibreOffice Fresh, Readline, Firefox
No Manjaro metapackages for non-rt kernels?

about QT 5.12 LTS you cant kickout 4.9 series , its LTS


I can remove kernels as needed, as I compile them …


There are a few people running manjaro32 and older kernels so it may impact on them - however, I don’t know how many 32-bit PCs are running with an NVIDIA GPU which wouldn’t work fine with nouveau. (I’m disregarding catalyst/xorg117 as I have made zero effort to maintain that in manjaro32 - people can use ati/radeon or buy a new machine.)

The Qt5 changes are more worrying - I don’t want to maintain a separate branch for Qt5 packages. However, this isn’t the first time that they have introduced incompatibilities with older kernels; I seem to think Qt5 applications won’t run with kernel 3.* anyway.

I don’t think this needs us to drop 4.4, I think it just needs people to be aware that things may not work, and that’s probably something that the Qt5 developers need to address given 4.4 isn’t EOL until 2022.

(I’m supposing this is all down to their recent change to use the statx system call… what a mess for such a “small” change)


I was using 4.4 branch specifically for better support with a usb realtek 8192cus wireless adaptor on the machine I had running manjaro32. I’ve chucked that particular adaptor in the waste electrical recycling skip now so no longer have the need for them. Recent builds of those kernels, 4.9 and 4.14 across all linux distributions no longer worked properly with pvaret’s tweaked power configuration modules to stop it lowering signal power or sleeping, the speed was still severely curtailed.


I have an old machine that only runs with kernel 44 series. That machine have an board that works with openchrome driver.

1 Like

I also had some concern recently about those old kernels. I think something Manjaro should do soon, whether if you decide to drop some kernels or not, is to explain in advance what’s happening and what to expect. At least, if it’s announced before release, it will makes less people taken by surprise.

I don’t understand, philm also builts kernels for Manjaro32? Or the project just reuse the PKGBUILD of Manjaro for Manjaro32?

I wouldn’t be surprised if they just respond with “It’s a feature, just adapt and use newer kernel or older QT.” But maybe I’m just too pessimistic.


I’m using for now the Linux 49 series in another machine. I was using 419 series before, but I wasn’t having a so good experience with my graphics board (418 was better than 419).
I’m not using 414 series because my AR9271 doesn’t works so well with it (works well with all other kernels that I used).

This is just until 420 series (I believe).


you can also kick out

  • linux316
  • linux318
  • linux417
  • linux44
  • linux49

you should drop all version kernel under 4.11

i hope that people laughing will help them in case that 4.14 or 4.19 give some trouble


What is QT’s response to this?

Surely some Ubuntu LTS is still using kernels older than 4.11?


Well, another reason why a metapackage kernel-lt that keeps the latest LTS kernel installed would be a good idea for being the default kernel-package. It would mitigate the effect of a lot of problems when old kernels are being dropped.
Those problems would still occur, but more close to the creation of the problem and thus would be easier to deal with, and the problems would not occur all at once.

Back when I used Ubuntu, they simply did not update such parts. They sticked to older LTS versions (in this case 5.6 or 5.9).

1 Like

But would those older LTS releases get qt 5.12?

How many distros combine old kernels with new qt libraries?


Fair point to both of you.
Just not used to LTS release models anymore. :slight_smile:

But KDE Neon probably would…


The nvidia/catalyst issue is rather minor because 4.4 is (in kernel terms) really old, LTS - 2.

However the Qt issue is very serious.
We can’t really hold back Qt updates, but it would also be very bad if we dropped 4.9, which is LTS - 1.

Adding linux414 to Qt’s “depends” maybe? Oh well not really… :weary:

EOL kernels can be deleted IMHO, with the exception of the last one (4.18) which should stay for a few more weeks.

1 Like

It may be dependent on the kernel of the build system as to whether statx call is used or not.

Looking at minimum-linux_p.h it requires 2.6.28 in any case. A newer requirement (like 4.11) only is required if the statx system call is actually available on the system Qt is built.

#if QT_CONFIG(statx)
#  define MINLINUX_MAJOR        4
#  define MINLINUX_MINOR        11
#  define MINLINUX_PATCH        0
#elif QT_CONFIG(getentropy)
#  define MINLINUX_MAJOR        3
#  define MINLINUX_MINOR        17
#  define MINLINUX_PATCH        0
#elif QT_CONFIG(renameat2)
#  define MINLINUX_MAJOR        3
#  define MINLINUX_MINOR        16
#  define MINLINUX_PATCH        0
#  define MINLINUX_MAJOR        2
#  define MINLINUX_MINOR        6
#  define MINLINUX_PATCH        28

This raises also another question: do we have any migration plans to upgrade users of old LTS kernel to new ones or do we just drop the users?


For what I know at the moment they are maintaining only the 18.04 ubuntu base, which uses the 4.15.


This. Phil knows much more about the kernels (and the various patches and tweaks) than I do, so I use the same PKGBUILDs but build them for manjaro32.

1 Like

Not usre this is valid information or not but one of the posters in that exchange claim that it can be compiled with -no-feature-statx

1 Like

That would be awesome. But it would probably mean that Manjaro will have to maintain qt5-base, since Arch does not use such old kernels…