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.
Sign in · GitLab
Manjaro Linux GitLab
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.
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.
Well obviously one should not install both. Even so if kernel-alive
is pre-installed in some cases already (full isos)
Well obviously one should not install both.
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.
if
kernel-alive
is pre-installed in some cases
Not anymore. It’s now removed from all ISO profiles.
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.
Well, I have pinged @Ste74 to come and look at this thread; he’s the package maintainer of kernel-alive
.
Well, I have pinged @Ste74 to come and look at this thread; he’s the package maintainer of
kernel-alive
.
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.)
Quick fix would be to define,
conflicts=kernel-modules-hook
Done.
Manjaro Linux GitLab
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.
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.
Not anymore. It’s now removed from all ISO profiles.
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.
a drastic reaction
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.
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.
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.
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…
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.
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…
The
kernel-alive
package is a convenience package created to add convenience.You can safely remove it as it is not required.
Which I feel was also seconded…
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.
However, I’m still wondering 2 things:
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?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.
I tried to reproduce these steps
in a experimental unstable VM of mine which had 2 kernels,
5.10.71
and5.14.10
which were updated to5.10.76
and5.14.15
respectively and could not reproduce.mkinitcpio -M
would otherwise complain about deleted modules, but everything is fine. Could it be related to a partial upgrade when I read this?
If you want to see the original issue, see:
Some additional info for documentation: snapshot 18886: There is a dir /usr/lib/modules/bk with all old modules inside There is a file .old pointing to 5.10.68-1-MANJARO ➜ modules ls -lA insgesamt 4 drwxr-xr-x 1 root root 468 27. Sep 19:26 4.19.207-1-MANJARO drwxr-xr-x 1 root root 514 27. Sep 19:24 5.10.68-1-MANJARO drwxr-xr-x 1 root root 514 27. Sep 19:35 5.14.7-2-MANJARO drwxr-xr-x 1 roo…
but it is a lot of reading / analysing
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 …
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
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.
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.