Please use kernel-modules-hook instead of kernel-alive!

How are you going to tell the running kernel that it must look for its modules under /etc? The kernel is hard-coded to look for its modules under /lib/modules, which in Arch-based distributions ─ as well as in any other distribution that has implemented the /usr merge ─ is a symlink to /usr/lib/modules.

I was referring to the service/config files (the extraneous ones created by kernel-alive.)

The modules would remain under /usr/lib/modules/ as always.

The only difference is that the obsolete/non-live kernel will have its folder safely removed after a reboot and/or service trigger and/or update. (All for the sake of freeing up space and “pruning” for housekeeping.)


Let’s say you’re currently running on a live system with kernel 5.16.10.

The command uname -r outputs:

5.16.10

The directory listing under /usr/lib/modules/ outputs:

5.16.10

You run an update with Pamac, and the package linux516 pulls in an update, which jumps from 5.16.105.16.11.

You continue to use your computer without rebooting.

The command uname -r outputs:

5.16.10

The directory listing under /usr/lib/modules/ outputs:

5.16.10 <--- currently used by live kernel (vanilla Arch would delete this)
5.16.11

Some time passes.

You run an update with Pamac, and the package linux516 pulls in an update, which jumps from 5.16.115.16.12.

You continue to use your computer without rebooting.

The command uname -r outputs:

5.16.10

The directory listing under /usr/lib/modules/ outputs:

5.16.10 <--- currently used by live kernel (vanilla Arch would delete this)
5.16.12

You reboot. Perhaps a service is triggered from the reboot that checks if it can safely “prune” the unneeded obsolete modules directory.

And so now…

The command uname -r outputs:

5.16.12

The directory listing under /usr/lib/modules/ outputs:

5.16.12

We’re back full circle. Rinse and repeat. :soap:


The workaround (such as kernel-alive or whatever solution) gracefully needs to prevent the rug from being pulled from underneath your feet (i.e, the live kernel) until the next reboot. :v:


EDIT: Or we simply take the honorable route and start a grassroots campaign to convince everyone to switch to Ubun- user account has been suspended

2 Likes

What a weird package. I’m glad I figured this out while switching to stable-staging because I can imagine a host of others complaining endlessly in stable again when the new kernels get pushed. I believe this is another case of good intentions with backing up modules, but backfires in reality when items like nvidia loads.

@Devs: I suggest also nuking this package before pushing kernel updates to stable. Programmatically in manjaro-system?

For me, uname -r is a little more expressive:

uname -r                                                       
5.10.70-1-MANJARO

It certainly should be … folks may remove the extra for aesthetic purposes (or because they want to hide they are not actually running manjaro) … but it actually could be important for troubleshooting.

The Discourse forum software limits the length of visible horizontal lines (for common display resolutions). If you exceed it, it breaks the flow, such as when appending notes to the end of a line.

We truncate versions all the time for the sake of making a post easier to read and follow. It’s why you see members comparing “Plasma 5.22 vs 5.23” instead always specifying the precise minor version and package, such as “Plasma 5.22.5-1 vs 5.23.1-1”.

Besides, I wasn’t troubleshooting.

:wink:

I have read and analyzed the source of both packages

kernel-alive:

  • 10 files in total
  • :+1: The scripts are well commented and easy to read
  • /lib/modules/.old is used as a file
  • the modules are deleted at the first boot after the update
  • :-1: protects only the running kernel (via uname -r)
  • :ghost: /usr/lib/modules/.old/* is erroneously deleted with a time delay (although it is not used at all)
  • :-1: not robust because it depends on /lib/modules/.old and /lib/modules/backup/* to be in a certain state
  • :boom: has deleted modules of my installed kernels (and that more then once)
  • :boom: others also had problems with this package

kernel-modules-hook:

  • 5 files in total
  • :+1: The scripts are inserted as a single line directly in exec
  • :-1: The scripts are therefore not commented and difficult to read
  • /lib/modules/.old is used as a dir
  • :sparkling_heart: protects all installed kernels. Before deleting modules, checks with pacman whether the corresponding kernel is still installed
  • :+1: The modules are first moved and only deleted with a time delay (It is possible to restore them if problems arise)
  • :heart: elegantly integrated into the system

The two packages are in great conflict with each other

  • Both packages basically do the same thing (therefore only one of them should be installed)
  • .old is used differently by both (file / dir)
  • linux-module-cleanup.service is used by both
  • linux-module-cleanup.conf is used by both

my recommendation:

use kernel-modules-hook instead of kernel-alive

4 Likes

Great side-by-side comparison!

I think your investigation (perhaps backed with using kernel-modules-hook successfully) denotes a much better solution for this thread.