I did and it returns nothing.
I removed them from /usr/lib/modules and also /var/lib/dkms
Interesting - yeah I really couldn’t say. On my end I don’t need to reboot or anything, just removing the module build directories is enough to get dkms status in check (I never have to remove anything from /usr/lib/modules though as they aren’t there to begin with).
I am wondering if it’s picking this stuff up from the previous snapshots?
I am just running ext4 on my end, if that helps.
1 Like
@Namey5
I did a total reinstall just to see since i couldn’t figure out why or where these entries were coming from. Now is listing correctly and i will keep an eye on every update that is dkms related to see what it shows. It’s not showing the kernels like it was before only the kernel related modules for the packages using dkms.
[ricklinux@rick-ms7c37 ~]$ dkms status
broadcom-wl/6.30.223.271, 6.12.7-arch1-1, x86_64: installed
vmware-workstation/17.6.2_24409262, 6.12.7-arch1-1, x86_64: installed
Edit: I may have to do the same on my nvidia system also to get it right too.
Edit: I guess I’ll close this now.
2 Likes
I have done a total reinstall of EOS exactly the same set up as previous. dkms status was reporting properly as above. There was just another kernel update and now i am running into the same issue where dkms status is showing the previous kernel files missing. I am not sure why it is looking for them in the first place since it is removing the previous kernel in /usr/lib. Only the current kernel is showing.
But dkms status is reporting again trying to find? This keeps adding up every time there is a new kernel update or vmware package or broadcom that are using dkms modules.
[ricklinux@rick-ms7c37 ~]$ dkms status
find: ‘/usr/lib/modules/6.12.7-arch1-1/’: No such file or directory
find: ‘/usr/lib/modules/6.12.7-arch1-1/’: No such file or directory
find: ‘/usr/lib/modules/6.12.7-arch1-1/’: No such file or directory
find: ‘/usr/lib/modules/6.12.7-arch1-1/’: No such file or directory
find: ‘/usr/lib/modules/6.12.7-arch1-1/’: No such file or directory
find: ‘/usr/lib/modules/6.12.7-arch1-1/’: No such file or directory
broadcom-wl/6.30.223.271, 6.12.8-arch1-1, x86_64: installed
vmware-workstation/17.6.2_24409262, 6.12.7-arch1-1, x86_64: installedfind: ‘/usr/lib/modules/6.12.7-arch1-1/’: No such file or directory
find: ‘/usr/lib/modules/6.12.7-arch1-1/’: No such file or directory
find: ‘/usr/lib/modules/6.12.7-arch1-1/’: No such file or directory
(Built modules are missing in the kernel modules folder)
vmware-workstation/17.6.2_24409262, 6.12.8-arch1-1, x86_64: installed
[ricklinux@rick-ms7c37 ~]$
Anyone have any ideas where this is coming from?
it should be 6.12.8 in the morning ,
recheck mirrors
dkms was released yesterday with nvidia & nivida-utils, and linux6.12.8 in the morning
I do have the 6.12.8 installed as shown in the image. The problem I’m having is even though it removes the previous modules for older kernels dkms status is still reporting looking for them after they have been removed.
What do you still have in the following folders?
ls -la /var/lib/dkms
ls -la /usr/lib/modules
I just noticed that I had stuff in /var/lib/dkms/vboxhost but I’m no more using dkms. Then I installed dkms and it showed a few old things:
$ dkms status
vboxhost/7.0.8_OSE: broken
Error! vboxhost/7.0.8_OSE: Missing the module source directory or the symbolic link pointing to it.
Manual intervention is required!
vboxhost/7.1.2_OSE: broken
Error! vboxhost/7.1.2_OSE: Missing the module source directory or the symbolic link pointing to it.
Manual intervention is required!
vboxhost/7.1.4_OSE: broken
Error! vboxhost/7.1.4_OSE: Missing the module source directory or the symbolic link pointing to it.
Manual intervention is required!
Then I removed folder /var/lib/dkms/vboxhost and dkms status no more complains.
1 Like
There are always leftovers in the subdirectories of /var/lib/dkms when installing a new kernel. What I mean by leftovers is directories or files that clearly belong to older kernels, not currently installed on the system.
In that state, executing dkms status then results in the mentioned errors like find: ‘/usr/lib/modules/6.12.7-arch1-1/’: No such file or directory.
After manually removing the leftovers, dkms status runs fine.
This was already mentioned by OP and @ricklinux
Btw, the /usr/lib/modules directory looks clean.
The only problem is that there’s no auto cleanup in /var/lib/dkms happening when upgrading via e.g. yay.
The questions left to be answered is why and what the solution would be. Having to manually cleanup doesn’t seem like the way to go.
2 Likes
[ricklinux@rick-ms7c37 ~]$ ls -la /var/lib/dkms
total 8
drwxr-xr-x 1 root root 86 Jan 2 20:43 .
drwxr-xr-x 1 root root 516 Jan 4 06:24 ..
drwxr-xr-x 1 root root 136 Jan 4 05:34 broadcom-wl
-rw------- 1 root root 1704 Jan 2 17:56 mok.key
-rw-r--r-- 1 root root 811 Jan 2 17:56 mok.pub
drwxr-xr-x 1 root root 142 Jan 4 05:34 vmware-workstation
[ricklinux@rick-ms7c37 ~]$
[ricklinux@rick-ms7c37 ~]$ ls -la /usr/lib/modules
total 0
drwxr-xr-x 1 root root 28 Jan 4 05:34 .
drwxr-xr-x 1 root root 213424 Jan 4 07:26 ..
drwxr-xr-x 1 root root 524 Jan 4 05:34 6.12.8-arch1-1
[ricklinux@rick-ms7c37 ~]$
I removed everything last time because i had a ton of old kernels left over and vmware and broadcom modules also. It didn’t make any difference. When i ran dkms status it still showed it was trying to find this stuff as missing which was there before until i removed it which didn’t change anything. So obviously I’m trying to understand why?
Edit: Currently in /var/lib/dkms I don’t have any kernel modules only the broadcom and vmware which has the 6.12.7-arch1-1 kernel modules. So i will now remove these and run dkms status again and see if it comes back properly listing only the current kernels modules.
Edit: As you can see it’s still listing these and trying to find them. Although it does show the proper modules installed for the current kernel.
[ricklinux@rick-ms7c37 ~]$ dkms status
find: ‘/usr/lib/modules/6.12.7-arch1-1/’: No such file or directory
find: ‘/usr/lib/modules/6.12.7-arch1-1/’: No such file or directory
find: ‘/usr/lib/modules/6.12.7-arch1-1/’: No such file or directory
find: ‘/usr/lib/modules/6.12.7-arch1-1/’: No such file or directory
find: ‘/usr/lib/modules/6.12.7-arch1-1/’: No such file or directory
find: ‘/usr/lib/modules/6.12.7-arch1-1/’: No such file or directory
broadcom-wl/6.30.223.271, 6.12.8-arch1-1, x86_64: installed
vmware-workstation/17.6.2_24409262, 6.12.7-arch1-1, x86_64: builtfind: ‘/usr/lib/modules/6.12.7-arch1-1/’: No such file or directory
find: ‘/usr/lib/modules/6.12.7-arch1-1/’: No such file or directory
find: ‘/usr/lib/modules/6.12.7-arch1-1/’: No such file or directory
(Built modules are missing in the kernel modules folder)
vmware-workstation/17.6.2_24409262, 6.12.8-arch1-1, x86_64: installed
[ricklinux@rick-ms7c37 ~]$
Edit: I don’t know enough about this so that’s why I’m asking. It doesn’t make any sense to me that it’s showing looking to find them when they were there in the first place and yet i removed them and it shows the same. The only thing factual is that the 6.12.7 kernel isn’t there any more because when i installed the latest it removes the older one.
Can you check the subdirectories of the kernel modules? e.g. /var/lib/dkms/vmware-workstation/17.6.2_24409262 or whatever version number you have. The directories inside of here should only contain directories mentioning your current kernel version.
1 Like
As far as I understand, when upgrading a kernel with yay/pacman, this hook gets triggered: /usr/share/libalpm/hooks/71-dkms-remove.hook, which executes /usr/share/libalpm/scripts/dkms remove. This script /usr/share/libalpm/scripts/dkms is maintained by arch (see e.g. here as the script mentions the name Sébastien Luttringer). But I’m having trouble finding any related issues like ours in the arch community.
@jul.cgn
Okay i fixed it now. Seems it has the files in two places. So i removed them from the folders of the packages that use dkms which are broadcom and vmware. Now i get the proper results. So I’m wondering what should be removing this stuff when new kernels are installed? As you said having to manually clean these up is not right.
[ricklinux@rick-ms7c37 ~]$ dkms status
broadcom-wl/6.30.223.271, 6.12.8-arch1-1, x86_64: installed
vmware-workstation/17.6.2_24409262, 6.12.8-arch1-1, x86_64: installed
[ricklinux@rick-ms7c37 ~]$
Thanks @manuel and @jul.cgn for your thoughts which helped me correct it and understand what was happening. I purposely did a total reinstall just to see why this was happening. We need some new hooks or something for dkms so this isn’t happening. @manuel?
1 Like
Well, I would expect /usr/share/libalpm/hooks/71-dkms-remove.hook to take care of cleanup. But it doesn’t work, obviously. And it appears that it’s not related to arch as I can’t find anyone with these issues in the arch communities.
1 Like
There was another user with the same issue as me @Namey5 using ext4 whereas I am using btrfs and snapshots so originally i thought maybe it had something to do with that. @Namey5 was able to clean it up and dkms status was reporting properly but same issue happens with a new kernel as far as i know. I had so many kernels listed in there which i did remove but maybe i mad a mistake along the way because it still kept reporting the same info. Hence why i did a total reinstall.
Edit: Maybe another target needs to be added to the hook to take care of the folders for which it has the dkms modules listed? I’ll have to defer to the experts on this because i have no idea. 
Maybe @manuel has a thought?
Unfortunately I don’t have anything to contribute, other than to say that I have the same issue. I can fix it temporarily by cleaning up manually, but when the kernel is updated, the problem appears again.
I just never noticed it before hence the reason i had so many kernel modules listed. I only became aware of it when @Namey5 reported it and so i checked mine. I still have the same issue on my other system which is even worse since it also has nvidia modules to deal with.
Edit: I thought the reason using dkms so you didn’t have to reinstall stuff every time a kernel updated. What’s worse? Having to do a big clean up? 
That screenshot of 71-dkms-remove.hook still makes me think that things are just happening out of order, i.e.
Step 1: delete installed modules directly.
Step 2: invoke dkms remove, which then fails as some of the files have been manually removed.
I wonder if you swapped those [Trigger] and [Action] sections around if it might fix things (or even remove the first [Trigger] section as in theory dkms remove should delete all related files to that module).