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

Thank you for summarizing the real problem.

I think we see a lot of “I can’t boot anymore” in the forum. The reasons can be different:

  • Ignored best practices
  • Ignored good advice
  • Doesn’t like reading manuals
  • He thinks he knows everything, but is a NOOB in Linux
  • Tried to change Linux according to his thinking

However, some may be because upgrading kernels in Manjaro is risky. The time to help them could be saved.

1 Like

Thanks again, @Yochanan. :sunglasses:

:+1:


In my case, I’m going to leave kernel-alive instead, but this is reassuring for other users, as it stops them in their tracks. (And like you implied, no need to blacklist kernel-modules-hook from the Community repo.)

This is my first iteration with kernel-alive

and this the kernel-modules-hook

So seem someone has taken the idea from the reddit etc… etc… instead to improve kernel-alive also for arch an user create another version… i don’ t know this hook before today when are mentioned in this tread… what I see is more interaction with kernel-modules-hook ( if I see PR and issues opened and closed ) than with my version ( maybe is possible I’m a bad guy and our users don’t like interact with me ) so is possible it work better of my, if anyone can confirm this I can remove from our repository kernel-alive since I don’t like multiple programs for do the same thing…

2 Likes

I’ll continue to use kernel-alive, and keep an eye on my modules and /boot/ directory, as well as any issues with using a live/current kernel between reboots.


This is also an example of “web search crosstalk”. I recall in the past I researched on how to deal with Arch “pulling the rug from under your feet” when you update a currently running kernel (i.e, linuxYZZ). Later, with Manjaro, I revisited that problem for a solution. The AUR package kernel-modules-hook is presented as the defacto method for Arch-based distros. (Now it is promoted to the Community repo.)

I hadn’t known about kernel-alive until much more recently; let alone its history.

I hope that kernel-alive will suffice on its own accord. I’ll let you know as time goes on.


However, I still feel the core issue is the “Arch way” of kernel updates, of which Manjaro inherits downstream. :frowning_face:


EDIT:

Hey, hey, hey! Don’t say that… :cry:

…because I don’t like competition. :smirk:

2 Likes

The reason why not many users are affected by strange system behaviour after applying kernel updates is simple: most people use Stable branch which doesn’t receive updates as often as Unstable, where chances that one will face such issue are higher.
I always thought it’s one of a few disadvantages I need to accept in exchange for access to newer packages. Now I am in shock and awe for poor Arch users who have been dealing with this since when Arch was introduced. So that’s the cost of being able to say that “BTW” phrase… :stuck_out_tongue_winking_eye:

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.

Thread reopened as per the request of the original poster.

After everything is said, maybe we can try to repair kernel-alive because it is worth rescuing.

My first suggestion is to repair the the things that are conflicting with kernel-modules-hook. The filename .old has gotten old fast. :wink: Better use something that noboy else will use.

  • .oldoldold :wink:
  • .these_modules_should_be_deleted_later
  • .remove_later
  • .kernel-alive (my favorite)
  • .kernel-alive-remove-later

Then replace all /lib/modules/.old with /lib/modules/.kernel-alive

I found it 11 times. After that kernel-alive should only be conflicting with its hooks.

Imho Ubuntu-/Fedora-/etc-like versioning is better.
With the use of metapackages (preserving original names like linux510) pointing to the latest available version of linux510, e.g. 5.10.77. This however would mean that extra modules for every kernel version should be kept available too… Or better switch to dkms entirely (if possible). Branches also add extra maintenance… True way is hard lol

2 Likes

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…

:rofl:

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

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

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,
/etc/keep-alive-old-modules-per-andreas85-suggestion-as-to-avoid-future-conflicts

1 Like

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

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