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

andreas85 · 5 November 2021 13:19

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

see @ line 162

winnie · 5 November 2021 13:36

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

andreas85 · 5 November 2021 13:40

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

pro:

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.

contra:

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

winnie · 5 November 2021 13:40

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.

winnie · 5 November 2021 13:47

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/.

andreas85 · 5 November 2021 13:49

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

winnie · 5 November 2021 13:57

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.”

andreas85 · 5 November 2021 14:52

I am a developer since 1985 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:
/etc/keep-alive-old-modules
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.

winnie · 5 November 2021 15:10

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.

It should be something like,
/etc/keep-alive-old-modules-per-andreas85-suggestion-as-to-avoid-future-conflicts

andreas85 · 5 November 2021 15:15

Suggestion for the
kernel-alive-post.script

#!/bin/bash

msg() {
ALL_OFF="\\e[1;0m"
BOLD="\\e[1;1m"
GREEN="${BOLD}\\e[1;32m"
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
	fi

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

	rm -rf /lib/modules/backup

	#Inform user
	echo
	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.
	"
else
	echo
	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.
	"
fi

Only

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
	fi

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

openminded · 5 November 2021 15:33

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.

Aragorn · 5 November 2021 18:49

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.

winnie · 5 November 2021 19:31

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.10 → 5.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.11 → 5.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.

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.

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

annoying_daniel · 6 November 2021 06:37

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?

andreas85 · 6 November 2021 07:38

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

uname -r                                                       
5.10.70-1-MANJARO

cscs · 6 November 2021 11:46

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.

winnie · 6 November 2021 13:20

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.

andreas85 · 7 November 2021 13:48

I have read and analyzed the source of both packages

kernel-alive:

10 files in total
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
protects only the running kernel (via uname -r)
/usr/lib/modules/.old/* is erroneously deleted with a time delay (although it is not used at all)
not robust because it depends on /lib/modules/.old and /lib/modules/backup/* to be in a certain state
has deleted modules of my installed kernels (and that more then once)
others also had problems with this package

kernel-modules-hook:

5 files in total
The scripts are inserted as a single line directly in exec
The scripts are therefore not commented and difficult to read
/lib/modules/.old is used as a dir
protects all installed kernels. Before deleting modules, checks with pacman whether the corresponding kernel is still installed
The modules are first moved and only deleted with a time delay (It is possible to restore them if problems arise)
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

Daniel-I · 17 November 2021 22:25

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.