[LU-4951] DKMS RPM no longer works due to referencing removed modules in its current configuration

• Type: Bug
• Resolution: Fixed
• Priority: Critical
• Fix Version/s: Lustre 2.6.0, Lustre 2.7.0
• Labels: prz
• Severity: 3
• Assignee: Bruno Faccini (Inactive)
• Reporter: Bruno Faccini (Inactive)

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.

Issue Links

• is related to: LU-2158 remove lvfs and fsfilt code

Comments

[Peter Jones]

It looks like the latest fix has landed to 2.7

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch http://review.whamcloud.com/12784/
Subject: LU-4951 scripts: remove nodemap.ko in dkms.conf
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 78afe76bd723df1736e4323ae3ccb42fd961c218

[Oleg Drokin]

I imagine by setting dependencies right we can avoid configure since we know we always have everything we need.

[Bruno Faccini (Inactive)]

A new+similar problem has appeared since LU-4647 patch (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?

[Gerrit Updater]

Faccini Bruno ([e-mail]) uploaded a new patch: http://review.whamcloud.com/12784
Subject: LU-4951 scripts: remove nodemap.ko in dkms.conf
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: ac5e95a4049b68af8ad0b20485c6200cf561c629

[Bruno Faccini (Inactive)]

Patch has landed.

[Bruno Faccini (Inactive)]

Sure Andreas! Here it is, http://review.whamcloud.com/10090.

[Andreas Dilger]

PS: I'm not against making the quick fix first.

[Andreas Dilger]

This kind of drift between expected and actual modules was one of my original concerns with the static module list used for DKMS. Since the list does not change frequently, and we do not build DKMS packages as part of our build process, it is easy to forget changing the spec file. We definitely need the module list to be dynamically generated.