Details
-
Bug
-
Resolution: Fixed
-
Critical
-
None
-
3
-
13699
Description
As part of TEI-1359 work to integrate DKMS RPM build+test in our tools chain, it hs been found that DKMS RPM fails during its post-installation when it tries to rebuild Lustre modules for the current/installed Kernel.
It fails complaining about the fact lvfs.ko module has not been built, but this because actual dkms.conf still references lvfs module when it has been removed as part of LU-2158.
First+quick patch will be to change/refresh dkms.conf with only currently generated modules. Next work will be to find a way to dynamically populate dkms.conf with the accurate modules.
Attachments
Issue Links
- is related to
-
LU-2158 remove lvfs and fsfilt code
-
- Resolved
-
A new+similar problem has appeared since
LU-4647patch (Gerrit change #9299, at http://review.whamcloud.com/9299, Commit 83f04354ff68a14d7492e35a9576c91492a1206c) has landed in master (between tags 2.6.54 and 2.6.90) and has removed nodemap.ko module.I have just pushed a new/2nd quick fix/patch to master for this at http://review.whamcloud.com/12784.
Doing so, I was trying to figure out how I can reliably modify the current creation process for dkms.conf file in order to dynamically detect from a particular Lustre version/source-tree:
1) modules that must always be built, with Client/Server distinction.
2) but may be also modules that will only build depending on configure-time discovery, like for ptlrpc_gss.ko ?
3) any other cause with impact on module creation?