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

Actually, PCLinuxOS doesn’t even update the kernels by itself. The user must explicitly indicate that they want to install a newer version of the same kernel(s).

As for their methodology, PCLinuxOS started off as a fork from Mandriva, so a lot of their procedures were directly taken over from Mandriva. The main differences however were that PCLinuxOS only comes as installable live images ─ which was not the case for Mandriva at the time ─ and that PCLinuxOS also uses a port of Debian’s apt and synaptic in combination with .rpm-based packages, plus that they also enable proprietary graphics drivers by default when supported.

Um, now you’re signing me up for something that I never volunteered for. :frowning:

Personally, I have no problem with the way Manjaro ─ or for that matter, Arch ─ updates its kernels, because I have simply accepted that updating the entire system by definition implies that one must reboot. It’s the simplest and cleanest scenario, even.

The only thing I do have a problem with in this regard ─ and as has been exposed by this thread ─ is that kernel-alive comes installed by default, because it violates the integrity of /usr as a read-only and shareable part of the filesystem hierarchy.

UNIX filesystems always comprise four categories of files and directories, between which there is some overlap: read-only versus writable, and shareable versus non-shareable. For instance…

  • /boot is read-only but non-shareable;
  • /usr is read-only and shareable;
  • /home is writable and shareable;
  • /var is writeable but non-shareable;
  • et al.

kernel-alive and kernel-modules-hook both violate this, but the difference is that kernel-modules-hook is an optional package from the Community repo, whereas kernel-alive comes pre-installed as a package from the Core repo. And that is what’s wrong.

1 Like

I don’t see why they cannot fix this in the PKGBUILD itself for kernel-alive and/or kernel-modules-hook.

Surely it can easily accomplish the same goal by locating the .old file (which tracks old kernels) under /etc/ instead, yes?

For it to be housed under /usr/ might have been a hasty decision for the sake of “keeping it in the same directory as the kernel modules themselves”.

Manjaro GitLab would be the place to report this bug, I assume?


Then I shall write a mean-spirited, spiteful, aggresively nasty letter to the Manjaro team, and once again I’ll proudly sign it on both of our behalf. :muscle: Because we’re in this together!

Just moved it to community.

EDIT: It’s also removed from all ISO profiles.

EDIT 2: kernel-alive now conflicts with kernel-modules-hook

Also of note:

https://lists.archlinux.org/pipermail/aur-requests/2020-February/037932.html

However, it was added to the AUR again later. Stefano said there should be no issue anymore.

If it’s only the .old file that we’re dealing with, then I agree. However, as I don’t have those packages installed, I don’t know what else they do under /usr after the reboot.

Be my guest. :smiley:

2 Likes

kernel-alive does not come pre-installed from what I see in the profile-isos

I’d say one should concentrate more on the real issue here, how OP got in that position, because from personal experience I never had such issues with it. I tried to reproduce these steps

in a experimental unstable VM of mine which had 2 kernels, 5.10.71 and 5.14.10 which were updated to 5.10.76 and 5.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?

  • Whilst an update (running kernel A) some kernels got updated

Some kernels???

You spent so much time on that post, you missed what I posted while you were busy. :wink:

It does. Not on Minimal ISO though.

>extra kernel-alive

I never installed kernel-alive, yet it’s on my system. The ISO I used was KDE 21.1.4.

I cannot even find kernel-alive in my pacman/Pamac history.

Not anymore. Am I invisible? Hello?

1 Like

There aren’t any full ISOs anymore if I’m not mistaken :slight_smile: Ah I see yes you are right, I thought it wasn’t offered anymore and including it in a > was a relic from the past. But still my point (about investigating the real issue) remains.

Yes, because I was busy doing the responsible thing by hunting down what post I had already posted that David Tennant GIF in before, so that I could use the same link, instead of having to upload it to the forum database again and consume precious space on the server. :stuck_out_tongue:

Ain’t I considerate? :rofl:

I knew it! :laughing:

1 Like

I saw your post, it is irrelevant regarding the current ISO profile post I was replying to, ISO profile still contains it.

>extra kernel-alive

I’m not done yet. Settle down.

EDIT: It’s been removed from all ISO profiles

What a time to be alive… :star_struck:

You single-handedly saved the Manjaro servers from overload. :clap:

2 Likes

Check back later but pretty sure the forum will save it again as another new image… See if your post is “edited” by the forum system in 10 minutes or so, and check what has changed.

No, I used the link to the copy of the image in the forum database. Had I used the original external link, then @system would have imported it again, indeed.


P.S.: I’ve removed the solution and the timer, because this is a development issue, not just a matter of a user wanting to uninstall a package.

So this is awkward. Plus I’m sure it’s a “no-no” when both packages reside under the official repositories…

pacman -F /usr/lib/systemd/system/linux-modules-cleanup.service

/usr/lib/systemd/system/linux-modules-cleanup.service is owned by community/kernel-modules-hook 0.1.7-2
pacman -F /etc/systemd/system/linux-module-cleanup.service

/etc/systemd/system/linux-module-cleanup.service is owned by core/kernel-alive 0.5-1

So it looks like two separate packages provide the same service (name), one under /usr/lib/, the other under /etc/. I’m to assume that the one under /etc/ “overrides” the one under /usr/lib/.

These two services contain different content/commands.

Here is the content of the one which kernel-modules-hook provides:

ExecStart=/bin/bash -exc 'for i in /usr/lib/modules/[0-9]*; do if [[ $${i##*/} = \'%v\' ]] || pacman -Qo "$${i}"; then continue; fi; rsync -AHXal "$${i}" /usr/lib/modules/.old/; rm -rf "$${i}"; done'

While the one provided by kernel-alive contains:

ExecStart=/usr/bin/linux-module-cleanup

This binary, which it references, is provided by the same package, and contains:

#!/bin/bash

#systemd service to cleanup old kernel

if [[ $(cat /usr/lib/modules/.old) ]]; then

        oldkern=$(cat /usr/lib/modules/.old)
        currentkern=$(uname -r)

        #check if old is no current and in this case remove the modules
        if [[ "$oldkern" != "$currentkern" ]]; then
                rm -r /usr/lib/modules/"$oldkern"
        fi
        #remove only the hidden file
        rm /usr/lib/modules/.old
fi

#backup old kernel

#rsync -AHXal "$${i}" /usr/lib/modules/.old/
#rm -rf "$${i}"
#done

Yet if you try to install kernel-modules-hook, there is no “conflicts” defined in the PKGBUILD apparently.

To reiterate: Both are in the official repositories.


UPDATE: By all accounts, .old is being treated as a directory? And yet it’s supposed to be a file? Now I’m even more confused.

UPDATE 2: Ah! They are not the same name. They differ by a single letter.

And that’s even worse! It means that upon installing/updating a kernel via pacman/Pamac, BOTH services are triggered, and it causes whacky behaviour.

I recall seeing such error messages using journalctl, claiming that ".old is not a file" or something to this effect.

That’s just a comment ─ note the “#” in front of the rsync line. It’s an incorrect comment, but only a comment nevertheless.

I was referring to the difference between the two services (one provided by kernel-alive, and other provided by kernel-modules-hook).

I added an extra update to my post.


EDIT: To be more clear, both services are triggered. One of them uses rsync to copy stuff into the .old folder, while the other treats .old as a file.

That cannot be acceptable as two “non-conflicting” packages in the official repositories.