Old kernel removals - mine don't get removed automatically

MAYBL8 · 28 September 2024 12:31

This was discussed here:
Evidently this is a problem with just my system. Maybe we can fix this.

I’ve hesitated to ask this because if not careful it could kill a system from running.
The reason why I am asking is I keep 2 kernels active on my system sometimes 3 and as I do updates new kernel versions come in. The old ones stay also. Like 6.10.10-2 and then that gets replaced with 6.10.10-3 for example and 6.10.10-2 remains. Well after a while it takes a long time to update when kernels get updated. I guess because I also use DKMS and the updates take a long time to finish. The more kernel versions you have the longer it takes. This gets annoying for me.
So I end up doing a manual cleanup of modules . I was thinking of writing a script to do this from time to time.
The problem is this is a “not everyone needs this” I guess scenario.
Anyway what do you think.

linux-aarhus · 28 September 2024 12:40

kernel is the responsibility of the local system admin.

You don’t need scripting or anything - simply remove the kernel

 mhwd-kernel -r linuxxyz

Very often I only have one installed kernel - perhaps two if I am testing the next development kernel.

Teo · 28 September 2024 12:50

Maybe something got out of sync and you have remnants of kernels, that the system ignores but got picked by dkms? Not sure. What does mhwd-kernel -li actually say?

MAYBL8 · 28 September 2024 13:08

Right now it says this.
I can remove the kernels just fine but in the modules folder there still remains files from old kernel versions.
It doesn’t now because I just manually removed them.

demo@Manjaro ~]$ mhwd-kernel -li
Currently running: 6.11.0-7-MANJARO (linux611)
The following kernels are installed in your system:
   * linux610
   * linux611

This is where I would see old (non current) files:

[demo@Manjaro ~]$ ls -al /usr/lib/modules
total 316
drwxr-xr-x   4 root root   4096 Sep 28 08:03 .
drwxr-xr-x 276 root root 307200 Sep 28 07:24 ..
drwxr-xr-x   5 root root   4096 Sep 28 07:27 6.10.11-3-MANJARO
drwxr-xr-x   5 root root   4096 Sep 28 07:28 6.11.0-7-MANJARO

Nachlese · 28 September 2024 13:37

Those are the modules directories belonging to the two kernels that you have installed.
Everything is in the green and as it should be.

MAYBL8 · 28 September 2024 13:41

Correct because I just manually cleaned it up.
It had old versions of the kernels in there before I did that.
When I did the mhwd-kernel -r command . Sorry if the spelling is wrong.
The old modules still remained in there.

Nachlese · 28 September 2024 13:44

only the top level directories - that is what I see on my systems
only the directory belonging to the current kernel version is actually populated - the others are empty

MAYBL8 · 28 September 2024 13:48

For some reason on my system when the modules update the DKMS portion goes through all the past modules and takes forever for the update to complete. That is my biggest issue.

MAYBL8 · 28 September 2024 19:09

So I just received a nvidia update and this looks like it did remove modules and not update old ones.

: Running pre-transaction hooks...
(1/1) Remove upgraded DKMS modules
==> dkms remove --no-depmod nvidia/560.35.03 -k 6.10.11-3-MANJARO
==> dkms remove --no-depmod nvidia/560.35.03 -k 6.10.6-3-MANJARO
==> dkms remove --no-depmod nvidia/560.35.03 -k 6.11.0-7-MANJARO
==> dkms remove --no-depmod nvidia/560.35.03 -k 6.11.0-rc6-2-MANJARO
==> dkms remove --no-depmod nvidia/560.35.03 -k 6.11.0-rc6-4-MANJARO
==> dkms remove --no-depmod nvidia/560.35.03 -k 6.6.47-1-MANJARO
==> dkms remove --no-depmod nvidia/560.35.03 -k 6.6.48-1-MANJARO
==> dkms remove --no-depmod nvidia/560.35.03 -k 6.6.49-1-MANJARO
==> dkms remove --no-depmod nvidia/560.35.03 -k 6.6.50-1-MANJARO
==> dkms remove --no-depmod nvidia/560.35.03 -k 6.6.50-2-MANJARO
==> dkms remove --no-depmod nvidia/560.35.03 -k 6.6.51-1-MANJARO
==> dkms remove nvidia/560.35.03
:: Processing package changes...
(1/6) upgrading linux-firmware-whence                                           [----------------------------------------------] 100%
(2/6) upgrading linux-firmware                                                  [----------------------------------------------] 100%
(3/6) upgrading linux-firmware-qlogic                                           [----------------------------------------------] 100%
(4/6) upgrading nvidia-utils                                                    [----------------------------------------------] 100%
If you run into trouble with CUDA not being available, run nvidia-modprobe first.
If you use GDM on Wayland, you might have to run systemctl enable --now nvidia-resume.service
(5/6) upgrading mhwd-nvidia                                                     [----------------------------------------------] 100%
(6/6) upgrading nvidia-dkms                                                     [----------------------------------------------] 100%
:: Running post-transaction hooks...
( 1/10) Creating system user accounts...
( 2/10) Reloading system manager configuration...
( 3/10) Reloading device manager configuration...
( 4/10) Arming ConditionNeedsUpdate...
( 5/10) Install DKMS modules
==> dkms install --no-depmod nvidia/560.35.03 -k 6.11.0-7-MANJARO
==> dkms install --no-depmod nvidia/560.35.03 -k 6.10.11-3-MANJARO
==> depmod 6.10.11-3-MANJARO
==> depmod 6.11.0-7-MANJARO
( 6/10) Updating linux initcpios...

Teo · 28 September 2024 19:12

That looks a lot better?

cscs · 28 September 2024 20:33

For some time I have also seen something similar …

For example on this system currently running 6.10.11-3 there is

2024-09-26  13:59  /lib/modules/6.10.11-1-MANJARO  313M
2024-09-27  00:35  /lib/modules/6.10.11-3-MANJARO  313M

And that 6.10.11-1 is populated and will not just go away on its own.

I think it may be related to kernel-modules-hook as that does some copying.
Ala the ‘pre’ hook

Exec = /bin/sh -c 'KVER="${KVER:-$(uname -r)}"; if test -e "/usr/lib/modules/${KVER}"; then rsync -AHXal --delete-after "/usr/lib/modules/${KVER}" /usr/lib/modules/backup/; fi'

j8a · 28 September 2024 20:48

Hi @MAYBL8 ,
I have installed Manjaro a few days ago, which comes with linux69 kernel. I installed two other kernels and removed the linux69 kernel with the command:
mhwd-kernel -r linux69

I then, rebooted the system and until now I was assuming that the kernel was gone.

I run the command you mentioned and I found this.

total 12
4 drwxr-xr-x 3 root root 4096 sep 25 19:49 6.1.106-1-MANJARO
4 drwxr-xr-x 3 root root 4096 sep 25 19:43 6.6.47-1-MANJARO
4 drwxr-xr-x 2 root root 4096 sep 25 19:47 6.9.12-3-MANJARO

But when I also run:

Currently running: 6.6.47-1-MANJARO (linux66)
The following kernels are installed in your system:
   * linux61
   * linux66

I really do not know what happened but I could say that I missed to do something.

Regards,

MAYBL8 · 28 September 2024 23:41

@j8a Yea I don’t think it is anything you are doing wrong.
It’s something with how the system works.
Best I can understand is there is some cleanup supposed to be happening but not working exactly correct.
I hope one of the smart techs here can figure it out.
But for now my manual cleanup can be performed every so often.

Teo · 28 September 2024 23:43

You did not actually write how/what did you manually delete? The modules subdirectory maybe?

MAYBL8 · 28 September 2024 23:45

It should be in my linked post. If not clear from that I will list the exact commands.

scotty65 · 28 September 2024 23:53

It looks like just one module file is not being removed when the kernel is removed/updated: modules.weakdep.

I have 2 kernels installed:

mhwd-kernel -li                                                                                                                                                 ✔ 
Currently running: 6.11.0-6-MANJARO (linux611)
The following kernels are installed in your system:
   * linux611
   * linux66

However, the output of tree -L2 /usr/lib/modules/ shows the following:

tree -L2 /usr/lib/modules/                                                                                                                                      ✔ 
/usr/lib/modules/
├── 6.10.5-1-MANJARO
│   └── modules.weakdep
├── 6.11.0-6-MANJARO
│   ├── kernel
│   ├── kernelbase
│   ├── modules.alias
│   ├── modules.alias.bin
│   ├── modules.builtin
│   ├── modules.builtin.alias.bin
│   ├── modules.builtin.bin
│   ├── modules.builtin.modinfo
│   ├── modules.dep
│   ├── modules.dep.bin
│   ├── modules.devname
│   ├── modules.order
│   ├── modules.softdep
│   ├── modules.symbols
│   ├── modules.symbols.bin
│   ├── modules.weakdep
│   ├── pkgbase
│   └── vmlinuz
├── 6.6.46-1-MANJARO
│   └── modules.weakdep
└── 6.6.52-1-MANJARO
    ├── kernel
    ├── kernelbase
    ├── modules.alias
    ├── modules.alias.bin
    ├── modules.builtin
    ├── modules.builtin.alias.bin
    ├── modules.builtin.bin
    ├── modules.builtin.modinfo
    ├── modules.dep
    ├── modules.dep.bin
    ├── modules.devname
    ├── modules.order
    ├── modules.softdep
    ├── modules.symbols
    ├── modules.symbols.bin
    ├── modules.weakdep
    ├── pkgbase
    └── vmlinuz

The modules.weakdep file contains only 1 line, which is a comment:

# Weak dependencies extracted from modules themselves.

cscs · 28 September 2024 23:55

So anyone gonna report their use of either kernel-modules-hook or kernel-alive (you should not be using this one)?

I still think, at least in the cases where the modules directory is fully populated, it may be related…

cscs:

I think it may be related to kernel-modules-hook as that does some copying.
Ala the ‘pre’ hook
Exec = /bin/sh -c 'KVER="${KVER:-$(uname -r)}"; if test -e "/usr/lib/modules/${KVER}"; then rsync -AHXal --delete-after "/usr/lib/modules/${KVER}" /usr/lib/modules/backup/; fi'

Teo · 29 September 2024 00:05

I see exactly the same as Scotty, and i do not have such hook in /usr/share/libalpm/hooks/
Maybe something changed recently, because it is only the previous kernel version, since a month ago.

[teo@teo-lenovo-v15 ~]$ tree -L2 /usr/lib/modules/
/usr/lib/modules/
├── 6.1.105-1-MANJARO
│   └── modules.weakdep
├── 6.1.106-1-MANJARO
│   ├── build
│   ├── kernel
│   ├── kernelbase
│   ├── modules.alias
│   ├── modules.alias.bin
│   ├── modules.builtin
│   ├── modules.builtin.alias.bin
│   ├── modules.builtin.bin
│   ├── modules.builtin.modinfo
│   ├── modules.dep
│   ├── modules.dep.bin
│   ├── modules.devname
│   ├── modules.order
│   ├── modules.softdep
│   ├── modules.symbols
│   ├── modules.symbols.bin
│   ├── modules.weakdep
│   ├── pkgbase
│   └── vmlinuz
├── 6.6.46-1-MANJARO
│   └── modules.weakdep
└── 6.6.47-1-MANJARO
    ├── build
    ├── kernel
    ├── kernelbase
    ├── modules.alias
    ├── modules.alias.bin
    ├── modules.builtin
    ├── modules.builtin.alias.bin
    ├── modules.builtin.bin
    ├── modules.builtin.modinfo
    ├── modules.dep
    ├── modules.dep.bin
    ├── modules.devname
    ├── modules.order
    ├── modules.softdep
    ├── modules.symbols
    ├── modules.symbols.bin
    ├── modules.weakdep
    ├── pkgbase
    └── vmlinuz

p.s. looks like /usr/share/libalpm/hooks/60-depmod.hook and the corresponding script are the culprits? Which are part of the kmod package (ver 33-2 on stable)

MAYBL8 · 29 September 2024 00:25

I am not at this technical level yet.
Can you tell me what you want me to show you ?

cscs · 29 September 2024 00:27

pacman -Qsq kernel-modules-hook
pacman -Qsq kernel-alive

Just to tell us if either is installed.

We have a couple variations of the same thing happening here … so I’m not sure we are all experiencing the same issue or the same cause.

In my case - the directories are fully populated - the old kernel modules folder is 300+ mb.
And I do have kernel-modules-hook installed.