Call for testing: kernel metapackages

Following on from some older discussions I have now implemented some kernel metapackages which should automate moving between the latest release and LTS kernels.

These are now in unstable and need to be tested. You cannot install these using mhwd - instead you'll need to install kernel and all necessary extramodules manually.

After that, though, you should pick up new kernels automatically, and there will be a good test of this shortly with the release of kernel 5.2.

All this metapackage does is install the related kernel packages - the end result is the same as installing the kernel packages:

$ sudo pacman -S linux-latest linux-latest-virtualbox-host-modules linux-latest-zfs
resolving dependencies...
looking for conflicting packages...

Packages (6) linux51-5.1.15-1  linux51-virtualbox-host-modules-6.0.8-12  linux51-zfs-0.8.1-5  linux-latest-5.1-1  linux-latest-virtualbox-host-modules-5.1-1  linux-latest-zfs-5.1-1

Total Installed Size:  131.50 MiB

:: Proceed with installation? [Y/n]

It will not automatically remove anything, it just adds the new kernel to the system when the metapackage is updated, e.g.:

Before:
linux51
linux-latest-5.1

After:
linux51
linux52
linux-latest-5.2


15 Likes

Finally!
Will surely test/use those packages on all my systems.

Edit: Installation went flawless, let's see how the future switches go.

Is the aim for the linux-lts package to be ready for use in 18.1?

1 Like

The downside is that after some time you'll end up with dozens of kernels installed. I'd like for some of them to be automatically removed, e.g. those who have EoL status. Or keep the 3 latest versions only, so when 5.4 comes around, 5.1 gets removed and so on. I don't know how this could be achieved though.

No, this is my own initiative to address the year-old requests. There aren't any plans to use the metapackage for anything else.

That doesn't preclude it from being used, but it's not in any plans.

Any kernel packages installed automatically via the metapackage will identify as orphans, same as any other no-longer-required dependencies.

There's no way to automatically determine which kernels you'd want to keep and which you'd want to remove, and removing orphaned packages every six months or so should be something everyone should be able to do themselves.

3 Likes

Btw. this is really easy:

pacman -Rsn $(pacman -Qdtq)

You have a bit too much faith on users. I mean, you still see someone requesting help on Linux 4.20, or having trouble (mostly package conflict because of Nvidia drivers) because they kept old and unsupported kernel on their system. And they installed the kernel manually. Imagine if it was installed automatically.

:slight_smile:

Maybe, but this is a good first step.

Removing EOL kernels could be part of a post-install hook.

I suppose you meant post-upgrade?

But not really, it wouldn't work, because to uninstall kernels, you need to remove packages, which means that you would need to call a package manager in order to remove packages while a package manager is already in the middle of a transaction.

Let's not start on some "pacman within pacman" shenanigans.

Unless you somehow manage to delay that removal to a moment when there is no transaction going on, but you would have to guarantee that no other transaction would be ongoing at that moment.

Oh good grief no. It's bad enough that manjaro-system uses that approach.

-> Thought needed.

1 Like

OT: Speaking of this, considering that many things in the .install script might just not be relevant anymore nowadays unless you haven't done updates for like 1 years +, it could be cleaned up a bit. Maybe it would remove a lot of those "pacman within pacman". lol

The approach with the meta packages is good. We may even add some functionality to mhwd supporting this. Most likely I might find some time for it in mid July.

3 Likes

I was thinking of adding it manjaro-architect, but if it gets added to mhwd-kernel, manjaro-architect automatically gets it, because it uses mhwd-kernel output for kernel selection.

Wow, thank you. Completely forgot about those discussions, nice to see that the original idea wasn't so bad after all :slight_smile:

I'll switch to unstable and see how it works with 4.19.

The way Arch does this is definitely a much cleaner approach. If you really want to make it more bulletproof, I'd add another package with the second-latest kernel. No metapackages, just:
linux-latest - always the latest version (5.1)
linux-fallback - always a version behind (5.0)
linux-lts-latest - 4.19
linux-lts-fallback - 4.14

Both latest and fallback should be included in the release, that way people would always be up to date and have two kernels to choose from, so when the newest one fails, they can boot the old one. Right now only one kernel is installed by default and when something goes wrong, people are done. And once it goes to EoL, they're stuck with it.

It's really interesting how people treat the kernel by the way. The common approach seems to be to always use a few years old version. As if updates don't matter and Linus is wasting his time with new releases.

LTS is handled by Greg Kroah-Hartman AFAIK.
Why should people always use the latest kernel?
LTS is there for a reason.

That would break the current Manjaro feature of having multiple kernel series available.

Hence the metapackages.

Yup, great for ATMs.

I don't see why they can't coexist. And it sounds more like a bug, not a feature :wink:

If you can make it work, then it's fine.

And great for all of my computers :slight_smile: Current Debian stable runs 4.9 btw...
Also, at least here where I live, most ATMs run Windows...

They can co-exist, but then you're building four kernels and all extra packages twice just for a different name. It's pointless.

I would prefer this approach too than the metapackage one, considering that you wouldn't have to clean older kernel that got installed automatically. It is not that it is hard to do, the problem is that many users just don't do it and then blame Manjaro for breaking their system because they kept unsupported kernels on their system.

Although instead of doing four variants, I would just do only one: linux-default, and it would be the default Manjaro kernel selected by Manjaro Team. We would have to determine the criteria for the "Default", but I think of something like:

  • Aim to be as close as the lastest LTS kernel as possible;
  • Only consider an upgrade of a major version of the Linux kernel once the lastest LTS kernel on upstream side is at X.Y.20 or more (to avoid regressions we can see in very early versions). For example, if upstream released Linux 5.2 and make it an LTS at version 5.2.14, wait until 5.2.20 is released before considering an upgrade from Linux 4.19 (LTS kernel).

Everything else would be same, you would still be able to choose from many major versions of the kernel and install whichever you want.