On my server I have more than a dozen kernel branches for the kernel
[www3 ~]# ls -alt /usr/lib/modules/
total 320
drwxr-xr-x 4 root root 4096 Jan 13 00:06 6.6.69-1-lts
drwxr-xr-x 3 root root 4096 Jan 13 00:06 6.6.47-1-lts
drwxr-xr-x 4 root root 4096 Jan 13 00:06 6.12.8-artix1-1
drwxr-xr-x 3 root root 4096 Jan 13 00:06 6.10.6-artix1-1
drwxr-xr-x 161 root root 143360 Jan 13 00:06 ..
drwxr-xr-x 45 root root 4096 Jan 13 00:05 .
drwxr-xr-x 3 root root 4096 Aug 28 2024 6.6.42-1-lts
drwxr-xr-x 3 root root 4096 Aug 28 2024 6.10.2-artix1-1
drwxr-xr-x 3 root root 4096 Aug 4 2024 6.9.7-artix1-1
drwxr-xr-x 3 root root 4096 Aug 4 2024 6.6.36-1-lts
drwxr-xr-x 3 root root 4096 Jul 4 2024 6.7.6-artix1-1
drwxr-xr-x 3 root root 4096 Jul 4 2024 6.6.18-1-lts
drwxr-xr-x 3 root root 4096 Mar 2 2024 6.5.7-artix1-1
drwxr-xr-x 3 root root 4096 Oct 21 2023 6.3.6-artix1-1
drwxr-xr-x 3 root root 4096 Jun 17 2023 6.3.1-artix1-1
drwxr-xr-x 3 root root 4096 Mar 7 2020 5.5.2-artix1-1
drwxr-xr-x 3 root root 4096 Feb 11 2020 4.19.96-1-lts
drwxr-xr-x 3 root root 4096 Jan 25 2020 4.19.88-1-lts
drwxr-xr-x 3 root root 4096 Jan 3 2020 4.19.84-1-lts
drwxr-xr-x 3 root root 4096 Nov 19 2019 4.19.76-2-lts
drwxr-xr-x 3 root root 4096 Oct 8 2019 4.19.74-1-lts
drwxr-xr-x 3 root root 4096 Sep 27 2019 4.19.60-1-lts
drwxr-xr-x 3 root root 4096 Jan 9 2019 4.14.90-1-lts
drwxr-xr-x 3 root root 4096 Dec 27 2018 4.14.82-1-lts
drwxr-xr-x 3 root root 4096 Nov 24 2018 4.14.72-1-lts
drwxr-xr-x 3 root root 4096 Sep 28 2018 4.14.69-1-lts
drwxr-xr-x 3 root root 4096 Sep 12 2018 4.14.67-1-lts
drwxr-xr-x 3 root root 4096 Aug 29 2018 4.14.52-1-lts
drwxr-xr-x 3 root root 4096 Jul 5 2018 4.14.48-1-lts
drwxr-xr-x 3 root root 4096 Jun 9 2018 4.14.35-1-lts
drwxr-xr-x 3 root root 4096 Apr 21 2018 4.14.32-1-lts
drwxr-xr-x 3 root root 4096 Apr 7 2018 4.14.27-2-lts
drwxr-xr-x 3 root root 4096 Mar 17 2018 4.14.26-1-lts
drwxr-xr-x 2 root root 4096 Mar 16 2018 4.9.76-1-lts
drwxr-xr-x 2 root root 4096 Mar 16 2018 4.9.75-1-lts
drwxr-xr-x 2 root root 4096 Mar 16 2018 4.9.73-1-lts
drwxr-xr-x 2 root root 4096 Mar 16 2018 4.9.75-1-lts
drwxr-xr-x 2 root root 4096 Mar 16 2018 4.9.73-1-lts
drwxr-xr-x 2 root root 4096 Mar 16 2018 4.9.72-1-lts
drwxr-xr-x 2 root root 4096 Mar 16 2018 4.9.71-1-lts
drwxr-xr-x 2 root root 4096 Mar 16 2018 4.9.67-1-lts
drwxr-xr-x 2 root root 4096 Mar 16 2018 4.14.24-1-lts
drwxr-xr-x 2 root root 4096 Mar 16 2018 4.14.23-1-lts
drwxr-xr-x 2 root root 4096 Mar 16 2018 4.14.20-1-lts
drwxr-xr-x 2 root root 4096 Mar 16 2018 4.14.19-1-lts
drwxr-xr-x 2 root root 4096 Mar 16 2018 4.14.18-1-lts
drwxr-xr-x 2 root root 4096 Mar 16 2018 4.14.13-1-ARTIX
The workstation has just the recent kernel
flatbush:[ruben]:~$ ls -al /usr/lib/modules
total 320
drwxr-xr-x 4 root root 50 Feb 18 08:02 .
drwxr-xr-x 237 root root 245760 Feb 19 04:50 ..
drwxr-xr-x 3 root root 4096 Feb 18 08:02 6.12.13-1-lts
drwxr-xr-x 4 root root 4096 Feb 18 20:22 6.13.2-artix1-1
flatbush:[ruben]:~$
Any idea why? Can I just remove the unused modules?
Yes you can as long (as you are not intentionally able to boot multiple kernels from your bootloader).
But as per your other post you really need to work out why your running kernel is not the same as the pacman installed and maintained kernel.
I am pretty sure because the mirror list was not update it had the older LTS kernel..... which itself confuses me for the following reason.
If the mirror list was not updated I'm not sure why it would change the linux kernel that it views as the latest since it is most of the same mirror servers remain the same
on the list, even when it is updated. And the servers themselves should be synced to the latest kernel.
As for the issue of the growing number of module trees that are being left on the hard drive, I am wondering if it is leaving behind the linux modules for
a reason on the server, while on my workstation it is only the latest version. The server seems to have not removed old module trees.
Maybe I blocked kernel upgrades on updates incorrectly? I wanted to stop auto-updating the kernel because it requires a reboot of the server. Maybe I did that wrong or maybe what I did doesn't work as expected.
I wish I less stupid and I am getting dumber and dumber with age
What do you have under /lib/modules ? Are all these kernel versions installed ?
In my /etc/pacman.conf's I often have some installed kernels as IgnorePkg entries which stops them being upgraded and no extra initcpio's are created, although they are updated when new active kernels are installed and mkinitcpio -P is run as a post installation task. Perhaps it's related to no kernel at all being updated and the pacman hooks not running as a result?
see above where I posted the directories.
Oh yes... :-[
A hook calls a script which would normally remove the old modules and generate mkinitcpio presets:
/usr/share/libalpm/hooks/60-mkinitcpio-remove.hook
/usr/share/libalpm/scripts/mkinitcpio
/etc/mkinitcpio.d/
Something related to that could be causing the trouble? And also it seems that installing a kernel only causes the initcpio to be updated for that particular kernel, it requires some other package to be updated that requires a more general rebuild to rebuild them all.
I am not understanding what you are saying.
No, you probably wouldn't, because I didn't understand what you were saying, sorry! I somehow misread it and thought perhaps the post installation cleanup scripts weren't running and leaving things behind in /boot, while you have things left behind in /lib/modules. In Debian based systems you can either install the versioned kernels, in which case new ones are never added, or a meta package that installs the latest, but I think the old ones stay around unless you remove them or set up an automated removal. In Arch Linux that shouldn't happen.
I just tried removing my currently running kernel package, and the directory under /lib/modules was still there and it didn't crash my desktop - then I reinstalled it because it might have caused problems otherwise. It could be something to do with not rebooting as you suggest. Files and directories that are in use are not deleted until the last file descriptor to them is closed, so a running process could be keeping your /lib/module directories in existence, at least long enough for them to be forgotten about by the system if not running permanently.
This might be helpful, but I've never tried it:
https://www.jamescherti.com/arch-linux-keep-kernel-modules-during-upgrade/ (https://www.jamescherti.com/arch-linux-keep-kernel-modules-during-upgrade/)
I've never seen that happen. I've seen files continue to exist until the last process with a file descriptor to it releases it, but I've never seen them stick once an rm is run on them.
In other words, I've had tail -f on log files that are later removed by a cron job and it is still taking input from syslog days later. Then I kill it and poof, it is gone and the new empty file is there.
I've never seen them remain after the last link to the inode is gone.
What does uname -a say, I infer from above you never reboot this machine either? In that case you would stay running on the kernel you booted with originally, it can't be deleted and a new one brought into operation until you shut down, although unused modules would go unless you used linux-keep-modules. lsof +D /lib/modules returns nothing, presumably because the kernel does things internally, but the same principles about file descriptors seem to apply.
To block kernel updates you would only need to put a line like:
IgnorePkg = linux
in /etc/pacman.conf for whatever kernel variety you were using, plus any kernel linked packages like headers and kernel modules /drivers.
Perhaps the fact you haven't stopped kernel updates and never reboot has resulted in a backlog of failed installations at various versions.