Details
-
Improvement
-
Resolution: Fixed
-
Blocker
-
None
-
5847
Description
dkms is a cross distro mechanism for the building and maintenance of out-of-tree kernel modules.
(http://linux.dell.com/dkms/) The attached patch adds dkms support to the debian/ubuntu packaging infrastructure.
The current debian/ubuntu kernel module package uses module-assistant, which produces a deb which is tied to a specific kernel version, requiring the user to manually rebuild packages when the kernel is changed.
The dkms package allows modules for multiple kernel versions to be packaged together into a single deb. Once installed, the package contains triggers so that when a new kernel is installed for which no pre-built lustre modules exists, dkms will automatically build and install them. This reduces maintenance overhead on client machines.
dkms also works on redhat and sles; it should be possible to fold dkms support into the rpm build process.
Attachments
Issue Links
- is duplicated by
-
-
- Resolved
-
- is related to
-
LU-5465 Enhancements to Lustre DKMS RPM
-
- Resolved
-
- is related to
-
-
- Resolved
-
Activity
For me the (big?) difference is that we don't need to maintain+build it on our own now!
And we can now make specific dkms-2.2.0.3-28 version a >= Required for our Lustre-DKMS RPM.
Hi bfaccini,
But that's roughly the same thing. The point though is that we are not actively building a working DKMS for our users to use, right?
Hello Brian,
No I am not aware that something has been done to ship a DKMS tool RPM including my patch.
But on the other hand, seems that upstream integration of my fix is done and we need to now use dkms-2.2.0.3-28 RPM/version from Fedora FC[19-21]/EPEL[5-7] distros.
bfaccini: there was mention at one point that we needed a patch in DKMS and that while we wait for upstream to ship that we'd build our own DKMS RPM for EL6 and ship that. Did anything ever come of that?
Finally it has been decided to better use Brian's set of patches to get this DKMS RPM generated. After some little re-work+rebase both changes #5960 and #6019 have already landed and #6020 will soon.
I have also updated TEI-1359 to detail the build procedure and also the basic testing requirements to be included in our build/test tools.
Possible next steps will be, 1st to add the ability to create a Client only DKMS RPM and also later the ldiskfs modules when no Kernel patching will be necessary.
Actually working on the best way to package (Requires/Conflicts/...) DKMS lustre-client-modules RPM.
BTW, I just added a "Conflicts: " for the lustre-modules itself since we need to ensure that no dual modules install (lustre-modules RPM vs DKMS rebuild) can occur that may lead to unpredictable behavior.
TEI-1359 has been created, as a follow-on to TT-1112 (that has been mistakenly mixed/duped with TT-1244/TEI-74) in order to have DKMS RPMs testing become part of autotests.
For IEEL (INTL-26), I have re-worked my original patch http://review.whamcloud.com/5284 that allows Lustre-Client modules re-build under DKMS control. It is patch-set #9.
It should need further add-on to handle llite_lloop and ptlrpd_gss special cases, due to their respective configure-time and gss/krb5 dependencies on target platforms.
I also think that may be more Requirements need to be set for this DKMS RPM.
Also, Lustre-Server modules future DKMS re-build has been somewhat planned.
The zfsonlinux repository was updated to include dkms packages for spl/zfs-0.6.2 and lustre-2.4.0. The update branch can be found here https://github.com/chaos/lustre/tree/v2_4_0-dkms, it includes refreshed versions of the following two patches which have been submitted before but not yet included. I can push refreshed copies if upstream is interested in adding dkms support.
https://github.com/chaos/lustre/commit/f7aeb9dd20c5c7cd044d06757f0782d8da8d2f92 -
https://github.com/chaos/lustre/commit/4afc95703208fcb50eb35ef72466e1d8af97b46a
@bruno: Yes, of course ultimately having upstream maintain those packages is the ultimate goal, but where are our customers, running EL6 systems, going to get dkms-2.2.0.3-28 binaries, today? That is the gap that I am proposing we need to fill.