New Manjaro function : kernel-alive

Continuing this

currently i build a pkg called kernel-alive ( :grin: name not definitive ) in unstable just now for testing :wink:

This pkg backup the current kernel in use ( pre transaction hook ) and after transaction ( post transaction ) move it in /lib/modules directory . In theory in this way the modules of current kernel continue to work after kernel upgrade . When pc reboot a systemd service clean the modules of the previous kernel so you use the actual kernel ..
I have tested in my hands and all work but i can't verify if work in any condition . Test it and i 'm open for any improvment or correction :yum:



Will it probably drip down to testing?

Not for a while yet. This is a fairly critical thing to get right. :slight_smile:


Stefano, I'm sure if anyone can do it, you can. That process, good or not, is not one that I will ever use. To put it bluntly, it is powerful enough to be scary.


Me neither, this solution to the "reboot problem" has the potential to do damage, and all to avoid a post update reboot?

I do honestly worry if this could encourage bad practice.
What will happen when someone continues running .. so long that this tool comes into play multiple times... how will it handle the handful of seperate kernel/module appends when there are more than one ?
Or am I right to hope that this would still be used in-tandem with for example the 'please reboot' nudger... and simply seeks to give better stability for the short time that somone may want to consider running?

I'm not so crazy :wink:.. The package provides a message that warns you to restart as soon as possible .. I hope the user knows how to read :flushed:

Is also present a hidden file to check the process. I can use it to break the next process update if the old kernel is still present ..


@Ste74 can we call it kernel-zombie?



This can be a candidate :grin:
Return on tread ..

kernel-alive prevent this case ( is in testing i see )..
I think is not an hell if we inform/warning user to reboot not necessary instantly but soon as possible ..

I used in the past debian and *buntu and other distro but not for most time , only in arch find my home , so i can wrong this asseption but only arch system remove the kernel module during a upgrade of the kernel for this reason is necessary a reboot .With this or without this at the end only the user can break the pc..

@jonathon do you think ?

Why is such a thing needed?

The current kernel an all its modules are still in place due to an open handle, even after they are "deleted" or replaced with new versions. This isn't something you have to worry about, the linux file system handles this already.

There's no need to copy it anywhere.

Read the thread in the OP. This functionality is "needed" to avoid people posting that things all of a sudden don't work after an update. Open file handles don't help.

The issue that we have is that the kernel version is the same before and after the update, so the current modules for the running kernel "vanish". In Ubuntu the kernel version is different, so all modules are retained.


This shouldn't have moved to testing yet. Is there a way of excluding packages from being "snapped" across?

No .. we have to exclude manually the pkgs .. since @lisa do the snap if you want is possible exclude to next stable ... at last also remove but user in testing i assume know what to do if encountering problems.. At the moment for security use i Γ¬have to build a hook for install ( where enabling systemd service because at the moment systemd service is enable in post hook but is wrong because is a redundant operation ) and hook for remove ( where we delete all stuff if still present )..

kernel-alive 0.2-1 is in unstable now :
Now added a proper file for install it , remove it and all stuff if still present .
If user not reboot the pc now simply upgrade the kernel but user continue to use the kernel in use , this mean no multiple modules kernel installed and add warning if user continue to not reboot the pc .
I see also new kernel upgrade is in unstable so is the perfect situation for test this package :wink: ..


I did a few tests in a VBox and it seems to work, but if after a kernel was updated and at boot i selected another kernel, the system didn't boot because the modules could not be loaded. After that none of the kernels/modules would load. I wasn't inspired to save some screenshots, but once i have some more time, i'll repeat the tests.

Thank you for your report , i have also thbut you point me in the right place : the modules go out when kernel at boot is changed immediatly after a kernel upgrade .. i have to investigate what is wrong in my script ..
here the repo

any tip is appreciated :wink:
1 Like

I wish i had more understanding on how some scripts work and are made to work, so i could avoid talking nonsense when i give feedback. :slight_smile:
Do i understand correctly that this kernel-alive is making a backup of ALL kernel modules even if the update was on one kernel+modules? Maybe reducing the backup/rsync to only that particular kernel and modules sub-folders? Since /lib/modules has this folders in (in my case):

4.12.11-1-MANJARO/  extramodules-4.12-MANJARO/
4.13.0-1-MANJARO/   extramodules-4.13-MANJARO/
4.9.48-1-MANJARO/   extramodules-4.9-MANJARO/

and from the kernel-alive-post.script i see

KVER="${KVER:-$(uname -r)}"

	if test -e "/lib/modules/backup/${KVER}"; then 
	rsync -AHXal --ignore-existing "/lib/modules/backup/${KVER}" /lib/modules/

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

	rm -rf /lib/modules/backup

How can i see how the backup is made and where? I will make another test on a VBox this evening, with an older iso install media and install kernel-alive prior to any update and trace the behavior ...

No the keyver array identify only the kernel in use ( like you type in tty uname -r ) and backup only this modules.. try before to reboot to disable the systemd service to remove the old kernel . In this way we not remove nothing or better after the update before reboot see what folder are present in /lib/modules and what contain the file .old ..

Just had a good opportunity to test it again, but i think i missed something...

  1. Prior the update:


  1. The cleanup service was like this:
    systemctl status linux-module-cleanup.service
● linux-module-cleanup.service - Clean up modules from old kernels
   Loaded: loaded (/etc/systemd/system/linux-module-cleanup.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Sun 2017-09-10 16:01:07 EEST; 6min ago
  Process: 175 ExecStart=/usr/bin/linux-module-cleanup (code=exited, status=0/SUCCESS)
 Main PID: 175 (code=exited, status=0/SUCCESS)

sep 10 16:01:07 mjxfcesd systemd[1]: Starting Clean up modules from old kernels...
sep 10 16:01:07 mjxfcesd systemd[1]: Started Clean up modules from old kernels.

During the update it created a folder called backup with the older kernel folder inside "4.13.0-1-MANJARO"

  1. Once the update was finished i have this folders in /lib/modules


and the .old file contains 4.13.0-1-MANJARO if i open it in Mousepad.

  1. The step i'm not sure about. Stop the cleanup service and reboot? Or reboot and see the folders after reboot (because everything else works as supposed too)?

Let me know if this is helpful and what is best for you to do and report next.

Now i have update the kernel :
after upgrade
Schermata del 2017-09-10 18-44-30
in use 4.12 kernel series so the hook service working fine..

after reboot
Schermata del 2017-09-10 18-48-03

the 4.12 old modules is just removed .. so i notice of that at boot grub reset my preference so grub want start with kernel 4.13 . Now if leave boot the system with this kernel all work fine ? In two occasion my boot fail because all modules are removed if leave grub start with 4.13 but this is strange behaviour .. if i see into my script this is wrong .. @bogdancovaciu also for you this is what happen?
@jonathon any idea ? And also why grub not save my preference ?

Forum kindly sponsored by