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

I’m so disappointed. I really wanted a reason to write someone a mean-spirited nasty letter, forging @Aragorn’s signature. :cry: It’s not fair…

3 Likes

Well ok, but if we look at it now from the new / inexperienced users perspective, them losing the prompt to reboot their system can lead to much much more complaints about a non-working system :slight_smile: . At least that should be mentioned somewhere imo, though one could argument new users would use the Pamac Manager :wink: .

Also it’s a bit sad seeing features that many were excited for New Manjaro function : kernel-alive - Manjaro Development - Manjaro Linux Forum in the past being axed (like also the linux-latest/lts metapackages etc) but OK I can be pragmatic, since I can’t code to help.

It’s not “axed”, it’s now just optional. Most users don’t even know it’s there, so it could actually be counterproductive for troubleshooting.

As far as the prompt, maybe we could include a needrestart hook instead like some other distros. It also prompts to restart services as well.

2 Likes

I’m trying to follow this thread after receiving the kernel-alive 0.5-2 update notice (core in my install ISO a few months ago) in pamac (curious what it was)… and am inclined to follow this advice…

Which I feel was also seconded…

However, I’m still wondering 2 things:

  1. Does removing this package resolve the issue @andreas85 reported? Or is the bug still an issue, but more was learned about potentially having both kernel-alive and kernel-modules-hook installed (the later not installed on my system) simutaneously… and adding the conflict in today’s update is a step towards removing that scenario?
  2. Would the only “change” I’d need to continue to keep in mind, if I remove the kernel-alive package, be to reboot after kernel updates; like I’m already doing? Or would I even experience any changes at all?

You can safely remove the packages

sudo pacman -Rns kernel-alive kernel-modules-hook

The packages was created so a functional kernel was available even after syncing a new kernel package.

The reboot was often postponed for days and users forgot they had updated and suddenly the system malfunctions - which in turn created the idea of this set of packages.

I have never used the package and the editions I have maintained does not include this package and on occasion I have recommended to uninstall the packages.

4 Likes

If you want to see the original issue, see:

but it is a lot of reading / analysing

What may have happened:

  • some of 3 kernels where updated (kernelA running)
  • some modules where updated
  • mkinitcpio generated all initramfs(s)
    without ERROR because at this point in time all modules where present
  • there may be a .old file (this is the start of the problem)
  • after the update reboot into grub and select another kernelB to boot (not the kernelA used to update !)** When you boot both times the same kernel nothing bad will happen :slight_smile:
  • in this case if .old exists, it will remove the modules of the kernelA while running kernelB
  • the problem will only be visible when you someday try to boot with kernelA (Then initramfs for kernelA is present, but /lib/modules/XX.XX … are not)

I only could follow these steps because i had btrfs-snapshots from before, within, after the update and from after the next 2 boots.

If someone does not have btrfs, or does not have snapper, or does not look into the snapshots he will only see the vanished modules.

this kind of bug is what I hate most … only some users are affected and it is not so easily reproducible to be able to understand what is wrong … I quickly read the whole post … even for me it is not reproducible: since when I made the package I use it and I never found myself unable to start the system … a week ago I switched to btfrs from ext4 who knows … I created it or at least I looked for a way to prevent that annoyance that occurs when you have a pendrive you are using and you need and updating you are unable to use it or it disappears and you have to restart …

2 Likes

There are multiple (and even overlapping) issues at hand in this thread (and the wider discussion). One of which is immediately resolved thanks to @Yochanan defining that kernel-alive (Manjaro exclusive) now conflicts with kernel-modules-hook (former AUR promoted to Community).


Another unresolved issue that still exists (and yes “not everyone is affected” / “but it doesn’t bother me”):

Due to how upstream Arch (and thus Manjaro) handles kernel updates, it can absolutely leave you with a borked or unbootable system if the update process is interrupted or you lose power. This is because kernel updates are not handled as an atomic process, while every single minor kernel iteration within the same base version is included under the same umbrella package (e.g, linux514, linux515, linux516, etc).

That’s an inherit issue with Arch / Manjaro. I hate to sound repetitive, but Ubunt, Mint, and others (including PCLinuxOS and openSUSE) have zero risk. Every single kernel iteration, even minor versions, are distinct packages, with distinct modules, and distinct directories.

Any interrupted or aborted update does not touch anything in regards to the current/live kernel.

This is how it should always be.

However, for some reason (I still don’t know why, tradition?) upstream Arch wants to use a sledgehammer approach and place all minor kernel versions/updates under the same package name:

  • linux514
    5.14.16
    5.14.17 ← linux514 update installs this, and wipes out everything 5.14.16
    5.14.18 ← linux514 update installs this, and wipes out everything 5.14.17
    5.14.20 ← linux514 update installs this, and wipes out everything 5.14.18

  • linux515
    5.15.01
    5.15.05 ← linux515 update installs this, and wipes out everything 5.15.01
    5.15.10 ← linux515 update installs this, and wipes out everything 5.15.05
    5.15.11 ← linux515 update installs this, and wipes out everything 5.15.10

This has, and always does, create unnecessary risks, as well as additional issues that I and others have experienced on multiple occasions. I realize there are Manjaro users that “aren’t bothered” by it because it doesn’t really affect them that often. Or they just immediately reboot after every update. :man_shrugging:

Always being forced to reboot causes you to lose data cache’d to RAM, which hurts performance; it interrupts your workflow; it’s not feasible if downloading/uploading files or sharing on the network; etc.

For now, we have kernel-alive that tries to address this underlying problem.

With Ubuntu and related distros, you can keep using your system indefinitely without rebooting, no matter how many updates you’ve pulled. The only reason to intentionally reboot is if you absolutely need to be running the latest minor kernel iteration. I never had this problem on Ubuntu, or Mint, or even openSUSE (as far as I can remember), due to their package naming convention. If a kernel update is interrupted, nothing is touched with regards to the live / running kernel, and thus the user can safely reboot into a working system. (Snapshots aren’t even necessary.)


And so for now, we require hack’ish-workarounds like kernel-alive and kernel-modules-hook , as well as an additional emphasis on snapshots and/or Timeshift backups. (They’re nice to have, but shouldn’t be a strong recommendation to hedge against an inherit design flaw.)

You want to know why such workarounds aren’t needed for other distros? Because they do it the correct way from the start. (Once again, I have yet to hear a clear justification for why Arch Linux insists on their sledgehammer approach.)


This is an especially bad impression for new users to Manjaro, since in many cases they install a brand new ISO that ships with a soon-to-be-EOL kernel, and they’re already on a precarious approach to maintaining their system.

Even Windows 10 after many, many, many updates, still works seamlessly without ever rebooting.


I understand I sound overly harsh and critical.

I should reiterate:

  • This is an inherited issue from upstream Arch. When I used Arch, this was one of my main gripes, where I couldn’t believe that an “experienced users distro” (Arch) sits atop a poorly designed shaky ground, whereas a “kids toy distro” (Ubuntu) handles kernel updates beautifully.

  • To implement it the proper way (i.e, how other distros handle kernel updates) will not cost nor take away anything from users who always immediately reboot and/or use snapshots, anyways; while at the same time it will benefit other users, such as myself, @openminded, and @andreas85. It’s a win-win, everyone benefits. (Perhaps it requires additional space in /boot/ and /, but with Ubuntu and Mint, one can choose to “prune” older kernels whenever they please. Mint even includes an in-house tool to present a GUI for reviewing/trimming older kernels.)

  • To implement this would require extra work, testing, and care on Manjaro’s part (so this is the real cost: implementation itself.) If it works, it’s smooth sailing for the end-users.


EDIT: If a mod tries to temporarily suspend my account, I should let you know that @Fabby has gifted me with a coupon that removes 5 days from my ban. :tickets: It doesn’t expire until July 2025.

8 Likes

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