Call for testing: kernel metapackages

Anyone who wants kernels doing a different way is free to run a proof-of-concept in their own third-party repository.

Please keep discussion in this thread about the new metapackages.

1 Like

This is the key.
A perfect(?) and clean way to remove "older/unwanted" kernels is a service IMHO.
mhwd/MSM/pamac/grub use services anyway (with some I may disagree), so it's not far from current Manjaro maintenance policies.
I consider a package with

  • a list of EOL kernels
  • a service file(s) set to run once on each boot, check running kernel and possible EOL.

Configuration for user preference may be in MSM.

All the above, because you can't remove running kernel if it's EOL.

Sorry for not listening @jonathon, it's so hot here in Athens.. :fire:

I can't speak for Manjaro's desktop LTS kernels so much, but I can tell you that for 5 years running, the Arch vanilla LTS kernels have provided the most consistent, reliable experience on this 2014 Intel/Intel laptop. (It did, however, start its life running the latest Manjaro kernel at that time.)

1 Like

Since currently the kernel modules are not automatically installed, I made a script for it.
Maybe not the cleanest, but it works.
This will install the latstest kernel with all modules you are currently using:

TARGET_KERNEL="linux-latest" # Can be "linux-lts" or "linux-latest"

# Get currently running kernel
CURRENT_KERNEL=$(mhwd-kernel -li | grep running | cut -d ' ' -f 4 | tr -d '()')
# Get all packages we need to install (with modules), space separated
LINUX_TARGET_PACKAGES=$(pacman -Q | grep $CURRENT_KERNEL | sed "s|$CURRENT_KERNEL|$TARGET_KERNEL|g" | cut -d ' ' -f 1 | tr '\n' ' ')

echo "Current kernel: $CURRENT_KERNEL"
echo "Packages to install: $LINUX_TARGET_PACKAGES"


a test, is good for retrieve last lts

kernel_repo() {
    printf "\e[32mavailable kernels:\e[0m\n"
    lts=$(LANG=C pacman -Si linux-lts | awk -F: '/^Version/ {print $2}' | sed -e 's/\.//g' -e 's/ //g'| cut -d'-' -f1)
    latest=$(LANG=C pacman -Si linux-latest | awk -F: '/^Version/ {print $2}' | sed -e 's/\.//g' -e 's/ //g'| cut -d'-' -f1)
    while read -r; do
        [[ "$REPLY" == "linux$lts" ]] && meta=" linux-lts"
        [[ "$REPLY" == "linux$latest" ]] && meta=" linux-latest"
        echo "   * $REPLY$meta"
    done < <(pacman -Ssq "^linux[0-9][0-9]?([0-9])$")
    #pacman -Ssq "^linux[0-9][0-9]?([0-9])$" | while read -r; do echo "   * $REPLY"; done
    pacman -Ssq "^linux[0-9][0-9]?([0-9])-rt$" | while read -r; do echo "   * $REPLY"; done

output :

./mhwd-kernel -l
available kernels:
* linux316
* linux414
* linux419 linux-lts
* linux44
* linux49

* linux52
* linux419-rt
* linux50-rt

./mhwd-kernel -li
Currently running: 4.20.17-1-MANJARO (linux420)
The following kernels are installed in your system:
* linux419 linux-lts
* linux420
* linux51 linux-latest

or only display * linux 419 (last lts) * linux51 (latest) :green_heart:

It should be automatically installed once MHWD will be able to handle those.

@jonathon Now that I think of it, a metapackage is a pretty good idea. Even if the clean up part can be a problem, at least people using the metapackage are guaranteed to have a kernel that is still maintained and the packages for unsupported kernels and their modules will become orphans. Therefore, cleanup is easier to do and think about (in a nutshell, just clean up the orphan packages and you're good to go) and fixing issues caused by the presence of unsupported kernel (like the classic package conflict between nvidia-utils and linuxXXX-nvidia) will be less awkward in some cases.

So yeah, in the end, I think I'm in favor of it. I would even say that it could become a default on Manjaro. If it becomes a part of the ISO images, the linux-lts one must be the one included though, because non-LTS kernels have a way too short lifespan. Well, similarly to the current situation: LTS kernel by default.

Until EOL kernels are removed, the issue is not solved.
It seems easy to add a service, to check for presence of finally EOL kernels and remove them. On each boot seems cheap, or on shutdown, whatever.

You can automate the removal only if the user is not running that eol kernel.

If the kernel changes because of the metapackage upgrade, even if there was only one kernel installed, there will be more than one kernel.
On reboot the newer kernel will be used (with default grub settings), so a service on boot can remove the old one.

We can't build an AI that reads users' minds (yet), or knowing potential needs and act beforehand.
But we can have a setting (checkbox) in MSM to agree or not with auto-removal of EOL kernels.

Removing the running kernel is still a bad idea

Yes, this is an excellent time to do so. Just add a check to see if the kernel to be removed is running and drop that kernel from removal list. It is 1-4 lines of bash depending on how you write it. Since process is repeated on every boot, the eol kernel gets removed eventually.

Good thing we don't need to.

I never meant that. I was misunderstood.
Actually the opposite. Because we cannot remove the running kernel, we can do that after reboot.
IMHO a user setting on that, is more than useful.

1 Like

Excellent. I support your ideas now that I understand them better.


This. I want a "fresh" EOL kernel available, because sometimes the kernel updates regress and it might be a few days until it is fixed. A recent (working!) EOL kernel saves the bother of finding that installer liveUSB, chrooting, trying to downgrade...

I did not receive the update to 5.2 yet, but I guess the package is not yet updated? :wink:

Kernel 5.2.1 is already out. Metapackage should be updated.

The guy that initiated this project is on vacation. Unless someone can replace him temporarily, people will have to be patient (in order to receive Linux 5.2 automatically, instead of having to install it manually).

IMO the metapackage shoulnd't be updated until several point-releases after the relevant kernel release. There are always a lot of bug-fixes in the early point-releases and the metapackage isn't targeted at "early adopters".


well, 5.1 is EOL now, so it is a good point for updating linux-latest now.

In the name "latest" I kind of understand that users running that want bleeding edge. So an early update with .1 or .2 should be good. I run it since .0, so linux-latest might not be for me. For me it would be okay to update linux-latest already with .0 then.

For linux-lts, i can completely understand the longer waiting period. I would wait until at least .5-.10 with updating that.

For latest, yes, .2 or EOL (whichever is earlier) makes sense.

1 Like

I've pushed linux-latest* version 5.2-1 to unstable.

It has the added "feature" of automatically removing EOL kernels.


Forum kindly sponsored by