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

Do you use hibernation ? Then you may have used kernel-alive while absent without knowing. After an Update it seems hibernation needs to access /lib/modules/${_kernver}/vmlinuz to wake up with the right kernelimage :wink:

see @ line 162

Go back to bed. Don’t forget to take your vitamins…


Because you are right:

What if kernel alive would

  • save the modules of the running kernel
    • because this is the right thing to do
    • because hibernation will work until next boot
    • because loading additional modules will work until next boot
  • mark the modules-dir for later removal
  • not remove the modules after boot
  • do remove the ancient modules-dir when updating the kernel again


  • only the update process ─ or, through deliberate action, the sysadmin ─ is allowed to write to /usr. Neither the boot process nor the shutdown process does.
  • this dir is “small” (actually about 105MB) and there will be only one.


  • The “to be removed” modules-dir may stay for a long time in /usr
    • until the next kernel-update
    • until the admin gets rid of it

:point_up_2: :point_up_2: :point_up_2:

It’s tried-and-true, and makes moot any hack’ish solutions.

The only “cost” is extra storage used on your OS partition. But that’s only if you don’t prune older kernels after much time in the future.

I must reiterate. With Ubuntu, Fedora, Mint, and openSUSE, the issues that affect Arch-based distros don’t exist in regards to any kernel updates; especially those with the same base version, such as 513, 514, 515, etc.

I realize it won’t change anytime soon, but why on earth Arch Linux decided to arbitrarily go this route from their inception is simply odd. There is no justification for it.

1 Like

It can be possible if the extraneous file(s) (such as config file keeping track of live/old modules) was written under /etc/ instead of directly inside of /usr/lib/.

You are right. This is the best solution.
But as long as that takes, we can repair kernel-alive in the meantime :wink:

I’m no developer, but here is what kernel-alive should do, as simply as possible:

  • Triggered upon any kernel update (regardless of major/minor version)
    – protect the directory under /usr/lib/modules/ that matches the live kernel via uname -r

  • Do this with any indefinite number of kernel updates between reboots

  • Upon reboot, double-check with uname -r and then simply delete the obsolete directory

  • Use a file/log under /etc/kernel-alive/ if neccessary to keep track of old directories to be pruned

The last step might not be necessary. All we’re concerned about is preventing an update from “pulling the rug from underneath our feet.”

I am a developer since 1985 :wink: When looking into the sources, it does:

  • before installing the new kernel, backup modules of the running kernel to /lib/modules/backup/KERNELVERSION
    This i have seen live while watching my last kernel-update
  • after installing the new kernel, restore these modules to /lib/modules/KERNELVERSION if they belong to the running kernel
    • but dont´t overwrite any of the new modules if there are new modules at this place
  • if there is a backup in /lib/modules/backup (here may be the problem !) then create a .old file with the name of the /lib/modules/KERNELVERSION all dirs there in it
    • if there are (reason unknown) any other (old) backup-dirs there, this will lead to disaster
  • remove /lib/modules/backup completely

After rebooting it will:

  • test if the current running kerne not equals the text in the .old file, the removes the dir with the modules named in .old
    • if the .old file contains more then one name, it will never be equal
    • if the .old file contains more then one name, one will be deleted, the other not

So maybe it is necessary to make sure that .old never has anything other then one filename

Maybe the right name for .old would be:
If it contains the package-name, it would be save from other usage, and it would be easy to find where it comes from.

Then the files linux-module-cleanup.* need renaming too. Maybe:
kernel-keepalive-cleanup.* then there will be no furter double usage of the same hooks.

Nevertheless it should be kept conflicting to kernel-modules-hook, because it does the same thing.

1 Like

What you wrote seems like a safe(r) approach in the meantime. It would be up to @Ste74 to make the changes in the next release. It would also more closely honor the "don’t play around in /usr/lib/" concern.

That’s too vague. :confused:

It should be something like,

1 Like

Suggestion for the


msg() {
local mesg=$1; shift
printf "${GREEN}==>${ALL_OFF}${BOLD} ${mesg}${ALL_OFF}" "$@" >&2

#post transaction : check if still present old kernel if yes warning the user and do nothing

if [ ! -e /lib/modules/.old ]; then

	KVER=$(uname -r)

	if test -e "/lib/modules/backup/${KVER}"; then
		rsync -AHXal --ignore-existing "/lib/modules/backup/${KVER}" /lib/modules/
		touch /lib/modules/.old && echo "${KVER}" > /lib/modules/.old

	#cd /lib/modules
	#oldkern=$(ls backup)
	#touch .old && echo "$oldkern" > .old

	rm -rf /lib/modules/backup

	#Inform user
	msg "Warning:
	 -> Kernel has been updated. Modules of the current kernel
	 -> have been backed up so you can continue to use your
	 -> computer. However, the new kernel will only work
	 -> at next boot.
	msg "Warning:
	 -> This computer hasn't been restarted for a while.
	 -> You are running an old kernel. In order to use a
	 -> new version of the kernel, please restart your
	 -> computer as soon as possible.


  • 3 lines commented out
  • 1 line added
    Using the existing if and the existing variable ${KVER} makes it impossible to have more than one name in .old

How do i submit this as patch for kernel-alive ?

	if test -e "/lib/modules/backup/${KVER}"; then
		rsync -AHXal --ignore-existing "/lib/modules/backup/${KVER}" /lib/modules/
		cd /lib/modules
		touch .old && echo "${KVER}" > .old

	#cd /lib/modules
	#oldkern=$(ls backup)
	#touch .old && echo "$oldkern" > .old

No I don’t use it much and that point of yours is a good one. Suspend to RAM is what I use in general, but most time my laptop is just on and running – not too much power thanks to U Intel processor.

1 Like

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:


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


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

You continue to use your computer without rebooting.

The command uname -r outputs:


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

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

Some time passes.

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

You continue to use your computer without rebooting.

The command uname -r outputs:


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

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

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:


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


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


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                                                       

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.


I have read and analyzed the source of both packages


  • 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


  • 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


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.