Arch Linux

Why would install some kernel headers without its kernel?

Don't know bth. I hit this when during removal, as in the example above.

In case it matters, other distros have such dependency link.
So while feels redundant, it catches trivial mistakes and avoids nasty looking errors.

External modules can be built with the headers but not the kernel installed.

Not sure I follow - what external modules are we talking about, do you have an example?

Seems like the recentish kmod/depmod changes (huuuuge thanks for which) have changed reproducer. Here is an updated one for posterity:
- pacman -Syu linux-zen-headers dkms bbswitch-dkms # oh no, didn't realise linux-zen is not installed yet
- the dkms install command will be issued automatically by the above
- dkms throws an error as below, pacman returns success

ERROR: Missing $(uname -r) kernel modules tree for module bbswitch/0.8.

See e.g. the non-dkms bbswitch package, which is built in a chroot without 'linux' installed.

So 'linux' lets you boot, 'linux-headers' lets you build. DKMS requires both.

The depmod hook has been fixed to check for the presence of modules.order to decide whether a kernel is installed or removed. The DKMS hooks could probably be adjusted, too, to only trigger for bootable kernels with headers.

> So 'linux' lets you boot, 'linux-headers' lets you build. DKMS requires both.

Not quite - (with my upstream dkms maintainer hat on) dkms does not care. dkms may or may not run depmod, with the latter triggering similar issues, even when dkms is not installed.

That said, the proposed depends() change is mostly a convenience plus we cannot realistically make "kmod" (aka depmod) depend on linux. So updating the DKMS hook is the most reasonable fix, indeed. Would you like a patch, or you'd rather do it yourself?

Having another look at the "other distros" - not sure what I was smoking - Fedora and Debian no such dependency chain, sorry about that.

Thanks

The DKMS hook is quite complicated. I've added the author to the assignees.

I tried twice but I'm not able to reproduce. No error message, except for dkms install action that does not support the --all parameter.

The original reproducer is no longer valid and I cannot edit it for whatever reason.

The updated one aka https://bugs.archlinux.org/task/73654#comment214663 is still reproducible:

- pacman -Rnn linux-zen
- pacman -Syu linux-zen-headers dkms bbswitch-dkms # oh no, didn't realise linux-zen is not installed yet
- few seconds later:
...
(3/3) Install DKMS modules
==> dkms install --no-depmod bbswitch/0.8 -k FOOBAR-lts
==> depmod FOOBAR-lts
==> ERROR: Missing 6.4.10.zen2 kernel modules tree for module bbswitch/0.8

As mentioned elsewhere, I would love to see hook.sh simplified by using dkms functionality directly - autoinstall or otherwise. Let me know what's needed by dkms and I will make it happen.

A related problem: If you remove the kernel package first, then the kernel headers package later, the hooks don't run the `dkms remove` command so it will leave a bunch of orphan files. Example:

$ find /lib/modules/*zen* /var/lib/dkms/broadcom-wl/*/*zen* /var/lib/dkms/broadcom-wl/*zen*
find: ‘/lib/modules/*zen*’: No such file or directory
find: ‘/var/lib/dkms/broadcom-wl/*/*zen*’: No such file or directory
find: ‘/var/lib/dkms/broadcom-wl/*zen*’: No such file or directory
$ sudo pacman -S --noconfirm linux-zen linux-zen-headers broadcom-wl-dkms
[...]
$ sudo pacman -R --noconfirm linux-zen
[...]
$ sudo pacman -R --noconfirm linux-zen-headers
[...]
$ find /lib/modules/*zen* /var/lib/dkms/broadcom-wl/*/*zen* /var/lib/dkms/broadcom-wl/*zen*
/lib/modules/6.4.10-zen2-1-zen
/lib/modules/6.4.10-zen2-1-zen/updates
/lib/modules/6.4.10-zen2-1-zen/updates/dkms
/lib/modules/6.4.10-zen2-1-zen/updates/dkms/wl.ko.zst
/var/lib/dkms/broadcom-wl/6.30.223.271/6.4.10-zen2-1-zen
/var/lib/dkms/broadcom-wl/6.30.223.271/6.4.10-zen2-1-zen/x86_64
/var/lib/dkms/broadcom-wl/6.30.223.271/6.4.10-zen2-1-zen/x86_64/log
/var/lib/dkms/broadcom-wl/6.30.223.271/6.4.10-zen2-1-zen/x86_64/log/make.log
/var/lib/dkms/broadcom-wl/6.30.223.271/6.4.10-zen2-1-zen/x86_64/log/.config
/var/lib/dkms/broadcom-wl/6.30.223.271/6.4.10-zen2-1-zen/x86_64/module
/var/lib/dkms/broadcom-wl/6.30.223.271/6.4.10-zen2-1-zen/x86_64/module/wl.ko.zst
/var/lib/dkms/broadcom-wl/kernel-6.4.10-zen2-1-zen-x86_64

The problem is that the hook runs when the kernel headers package is uninstalled, but at that point `dkms status -k <kernel-version>` doesn't return the list of modules anymore, so it doesn't do anything.

@gamezelda what you're describing sounds like an upstream bug. Namely: if the kernel is removed, the dkms module is no longer in "installed" but in "added/build" state and `dkms status` should report it as such.

Can you please open one at github.com/dell/dkms and tag me @evelikov. If you can include a reproducer that would be even better.

@xexaxo Thanks. I did a bit of investigation and indeed one way to fix the problem would be to fix upstream issue #166: https://github.com/dell/dkms/issues/166

Namely, what happens is:
1. When I install all of the kernel, headers and module, the module appears as "installed" in "dkms status".
2. So when I uninstall the kernel (but not the headers), none of the DKMS hooks run (see below), and the module is kept intact. So it should still be "installed".
3. However, due to issue #166, "dkms status" now reports it as "added".
4. When I uninstall the headers, the Arch Linux DKMS hooks run, but they do not detect that the module is installed since "dkms status" does not report so.
5. As a result, the module files are never uninstalled.

If I apply the fix/workaround I posted in issue #166, the module is correctly removed and no orphan files remain.
(Though I still get a depmod error similar to the one reported in the OP, so that should be fixed as well.)

Something I find pretty odd (and that causes us to run into upstream issue #166) is that the Arch Linux DKMS hooks run *only* when the headers are removed.
In fact, if you look at the trigger, you may think that they run when the kernel is removed due to the modules.alias target:
https://gitlab.archlinux.org/archlinux/packaging/packages/dkms/-/blob/60d8a3248354e5fd2a82e5a7b9c9d8224f11091c/hook.remove#L6
However, that line is actually dead code, because modules.alias is not tracked by pacman.
It was before, but it is no longer due to: https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/commit/b6880b286a5a610a6b4de28eb275a2a75f954654