kernel module installed to wrong path

[RivenChen]

path in dkms.conf is set to: DEST_MODULE_LOCATION[0]=/kernel/drivers/

Normally, this dkms kernel module can be installed to /lib/modules/${kern_ver}/update/dkms/
but this time in one machine, the kernel module was install to /lib/modules/${kern_ver}/kernel/drivers/.

How can I change the path which dkms package installed? Thanks

[RivenChen]

I see override_dest_module_location in dkms.in can change the dest_module_location, does it not effect?

[scaronni]

I think you already said it, edit dkms.conf with DEST_MODULE_LOCATION[0]=/update/dkms/?

[RivenChen]

I think you already said it, edit dkms.conf with DEST_MODULE_LOCATION[0]=/update/dkms/?

@scaronni In general case, override_dest_module_location in dkms.in will change the DEST_MODULE_LOCATION to /update/dkms/ automatically. But in this case, this action maybe not come into effect.

[scaronni]

I'm not sure I understood the issue, what you're saying is that even by setting DEST_MODULE_LOCATION to something it gets ignored and stuff gets installed anwyay in /updates/dkms?

[RivenChen]

I'm not sure I understood the issue, what you're saying is that even by setting DEST_MODULE_LOCATION to something it gets ignored and stuff gets installed anwyay in /updates/dkms?

@scaronni Yes, you're right.

[arvl130]

I noticed this issue as well. It was introduced in v2.8.8, specifically this commit e6c14d6b4ebaa66253008251b6485b86d425d7a2.

https://bugs.archlinux.org/task/73204

[RivenChen]

@arvl130 So mayby my dkms version is too old？ Afterwards I upgraded dkms version, this problem was really solved. But I forgot whether the version is below 2.8.8 or not.

[arvl130]

I'm not sure if the issue has been fixed in newer versions. It looks like the destination module path is still getting overridden, but I'm not seeing it's side-effects anymore, like leaving files untracked by the package manager in my case. I'll have to investigate some more.

[evelikov]

As we know hindsight is always 20-20, so looking back I do wonder:

The having such extra override semantics within dkms are kind of bad. In particular, the override kills both the package specifics and distribution specifics (as set in the /etc/ per-package or general configs). Bonus (but unrelated) point, we should really look at having the

Perhaps a better solution is to move the override logic from within dkms itself to the top-level /etc/dkms/framework.conf. The install script can do the distro detection magic and add the respective DEST_MODULE_LOCATION override within the conf.

[arvl130]

Just upgraded a package that's affected by this bug, and indeed the side-effects are still there.

I agree with @evelikov. While it is understandable that the developers of the project might want a default location for DEST_MODULE_LOCATION, there should still be an option define your own configuration for this setting.

[evelikov]

After having a quick look the other day, I stand corrected - there's no way to set DEST_MODULE_LOCATION in /etc/dkms/framework.conf which might explain why I've added the code-path.

That said, we could have a "FORCE_...` option to the same effect. Migrating the detection heuristics is a PITA, so I'm inclined to just leave it undefined and let distribution maintainers override it as needed.

[scaronni]

Sorry to hijack the thread, @evelikov I finally got admin access to the repository, you have now full commit access.

[HanabishiRecca]

Does anyone bothered fixing this? It completely destroys the ability to replace existing kernel modules. Like swapping inbuilt kernel driver to patched one etc.

[evelikov]

"Bothered" - ouch that's a bit harsh. But seriously - I'm balancing far too many things these days, so if you can open a MR that will be appreciated.

[HanabishiRecca]

I just asked. It is not clear about devs intentions here to override the path. I may help though.

Also there are other strange issues, e.g. check_version_sanity() is not able to pick up PACKAGE_VERSION from dkms.conf and always fail:

Module version  for ntfs3.ko.zst
exactly matches what is already found in kernel 6.2.0-zen1-1-zen.
DKMS will not replace this module.

And it is also not clear for me why this check was added in the first place.

[HanabishiRecca]

Update: noticed that original module is actually being removed from the tree on installation. So replacement should work from /updates, I guess. And seems like check_version_sanity() is not aware of the path anyway. But still it is kinda weird that DEST_MODULE_LOCATION is required and ignored at the same time.

[HanabishiRecca]

check_version_sanity() is not aware of the path anyway

Nevermind, this actually fixed already in 36d755f1bdacf65bcf939539d2c2277eec95edfd, just not released yet.

Sorry for spamming here.

[evelikov]

Nevermind, this actually fixed already in https://github.com/dell/dkms/commit/36d755f1bdacf65bcf939539d2c2277eec95edfd, just not released yet.

The above fix was included with 3.0.11.

The general DEST_MODULE_LOCATION overrides handling is tracked in https://github.com/dell/dkms/issues/328 - MRs welcome. Closing for now.