Misc fixes #371
Misc fixes #371
Conversation
avoid noise Module build for kernel <KVER> was skipped since the kernel headers for this kernel does not seem to be installed. on removed kernels that still have a nearly empty /lib/modules/<KVER> (w/o a build symlink) remaining
we just removed the last module from (no longer installed) kernel $1 so do not leave stale depmod files around
dkms autoinstall may produce multiline output
|
Thanks! |
| # no longer installed kernel $1, so do not leave stale depmod files around | ||
| rm -fv /lib/modules/$1/modules.{alias,dep,devname,softdep,symbols,*.bin} | ||
| rmdir --ignore-fail-on-non-empty /lib/modules/$1 | ||
| test -d /lib/modules/$1 || echo $"Removed /lib/modules/$1" |
There was a problem hiding this comment.
The rest of the series looks great, although this looks like a hack/workaround.
Namely: distros should kick off dkms remove/unbuild... before the actual kernel (modules) get removed. This is what Arch does at least - I didn't check others. If they use different order, then depmod shows some scary warnings:
depmod: WARNING: could not open modules.order at /some/path: No such file or directory
depmod: WARNING: could not open modules.builtin at /some/path: No such file or directory
depmod: WARNING: could not open modules.builtin.modinfo at /some/path: No such file or directory
If people manually remove modules after the kernel is gone, they will see the above warnings, which should be a flag that (minor) manual intervention is needed. That's perfectly fine IMHO.
In addition the empty /lib/modules/$1 can be owned by another package and removing it will cause package integrity checks to fail.
In a way I'm thinking that this should be handled at the depmod level - assuming you agree, can you open a proposal at https://github.com/kmod-project/kmod/ and I would have a look as time permits.
Few questions come to mind:
- Toggle short/long name?
- Omit output files when one or all input files are missing?
- Opt-in or out of the new functionality?
- Keep as-is or remove pre-existing output files?
Thanks
There was a problem hiding this comment.
If only linux-headers-$KVER are installed (maybe linux-image-$KVER is already gone) dkms builds and installs modules and calls depmod creating these files. There is noone left responsible for cleaning up these bits ...
Ideally depmod should be deferred to a trigger from linux-image-$KVER ... but it's probably a long way to get there.
There was a problem hiding this comment.
Ack, can I ask you to open an issue (here dkms and/or in Debian) with a rough outline and link it in the code?
Thanks 🙇
|
Thinking of it again, if there is initially no modules.dep because no linux-image-$KVER is installed, dkms should not call depmod to create one, so there would be no need for dkms cleaning that up afterwards. Preparing a patch. So we would need the cleanup code only for old module installation that unnecessarily ran depmod. |
|
Let's continue this in #374 |
a few small fixes for better cleaning up depmod generated files and for testing modules with AUTOINSTALL=""