Copy that. Yes, I think we’ve found a bug. And unless I’m mistaken, the service files under /etc would normally simply be symlinks to the actual files under /usr. So there’s a discrepancy there as well. 
Maybe this is a case of miscommunication between Arch and Manjaro?
kernel-modules-hook used to be an exclusive AUR package, which was promoted (by Arch) to their official repositories.
kernel-alive is a Manjaro-exclusive package.
And thus, you have two conflicting packages that reside in the official Manjaro repositories.
To make matters worse, neither is defined to “conflict” with the other, and thus your package manager will not stop you nor warn you.
1 Like
Well obviously one should not install both. Even so if kernel-alive is pre-installed in some cases already (full isos)
1.) Like @andreas85 , you might not know one is installed (let alone exists) as was the case of it being pre-installed with the ISO.
2.) You don’t shift the burden to the user to research the source code / PKGBUILD of every package they wish to install. These packaging issues are the responsibility of the package maintainers; not the end-users.
conflicts= and provides= are defined in the PKGBUILD.
Not anymore. It’s now removed from all ISO profiles.
2 Likes
Well, I have pinged @Ste74 to come and look at this thread; he’s the package maintainer of kernel-alive. 
1 Like
Quick fix would be to define,
conflicts=kernel-modules-hook
Longterm fix would be what you described about the service/hook writing inside of /usr/.
Maybe instead of rsync’ing to (For the other package that is, but it’s a moot point if /usr/lib/modules/.old/, it can rather use /var/linux-alive/.old/ as the folder? kernel-alive works without issue, and rather re-locates the hidden .old file to /etc/ or elsewhere.)
1 Like
Done. 
2 Likes
Well I remember kernel-modules-hook was in the AUR too, so it must have slipped Manjaro, they should decide which one to keep, true.
I’m not sure if such a drastic reaction was needed without reading what @Ste74 had to say first, it’s not like the forum was flooded by angry users with a broken system 
it’s one report and not clear enough how to reproduce.
All those years I had no problem with it for example.
Not in the slightest. There have been issues with it in the past reported, I’ve had issues with it and I removed it long ago.
Phil and I agreed to move it to community. Stefano has not been around much, FYI.
2 Likes
Can they? I’m not sure how Manjaro deals with Arch’s “Community” repo, in which many of those packages were promoted from the AUR previously. I assumed that Manjaro simply mirrors Arch’s Community repo.
Indeed. However, we can blacklist packages if necessary. In this case, there’s no reason to. The conflict I just added is enough.
I’m so disappointed. I really wanted a reason to write someone a mean-spirited nasty letter, forging @Aragorn’s signature. 
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 
. At least that should be mentioned somewhere imo, though one could argument new users would use the Pamac Manager .
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:
- 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-aliveandkernel-modules-hookinstalled (the later not installed on my system) simutaneously… and adding the conflict in today’s update is a step towards removing that scenario? - Would the only “change” I’d need to continue to keep in mind, if I remove the
kernel-alivepackage, 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
- 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 ←linux514update installs this, and wipes out everything 5.14.16
– 5.14.18 ←linux514update installs this, and wipes out everything 5.14.17
– 5.14.20 ←linux514update installs this, and wipes out everything 5.14.18 -
linux515
– 5.15.01
– 5.15.05 ←linux515update installs this, and wipes out everything 5.15.01
– 5.15.10 ←linux515update installs this, and wipes out everything 5.15.05
– 5.15.11 ←linux515update 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.
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. 
It doesn’t expire until July 2025.
8 Likes