DPDK dkms packages build for wrong kernel
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
dpdk (Debian) |
Fix Released
|
Unknown
|
|||
dpdk (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Yakkety |
Fix Released
|
Medium
|
Christian Ehrhardt |
Bug Description
[Impact]
* DPDK DKMS modules can be unusable depending on the kernel that was
running when triggering DKMS rebuilds last time
* Fix is a backport of the fix already in zesty for a while, see links in
comment # #1
* Essentially the fix passes the right kerneldir to the DKMS build
[Test Case]
* Set up a yakkety system with kernels (VM or BM).
* Install DPDK (this DKMS build for krernel "A" will work)
* Now install another kernel "B", the DKMS rebuild will be for "A" but
installed in "B". On reboot into "B" the module will fail
* With the fix applied on installing "B" the build will be for "B" and
install in "B" and thereby modules usable after reboot.
[Regression Potential]
* The changes are "only" affecting the DKMS configuration of DPDK
modules. Those DKMS modules are only used by a subset of DKMS setups
therefore the scope of potentially regressing systems should be small
* Also the fix is in zesty for quite a while now and worked fine there.
* Finally given the code change it should be fixing a case for those who
are broken at the moment, but not affect anyone else.
* Thereby overall I'd rate the risk low and definitely worth to fix the
case for those affected (Currently only usable with workaround to
re-trigger DKMS once in the new kernel).
[Other Info]
* n/a
---
The DPDK build system uses the RTE_KERNELDIR make variable to determine which kernel version to build for. DKMS provides the kernel version to build for in the $kernelver and $kernel_source_dir variables. Because you use a custom MAKE command, this must be used in the MAKE variable of dkms.conf to generate the correct RTE_KERNELDIR for the build, by doing something like this:
--- /usr/src/
+++ /usr/src/
@@ -1,7 +1,7 @@
PACKAGE_
PACKAGE_
BUILT_
-MAKE="source /usr/share/
+MAKE="source /usr/share/
CLEAN="source /usr/share/
DEST_MODULE_
AUTOINSTALL="YES"
Because this is not done, whenever the kernel package is upgraded and DKMS triggers a rebuild, it will trigger a rebuild for the *running* kernel which gets installed into the *newly installed* kernel directory, which is wrong and causes the module to fail to load when the newly installed kernel is booted.
Changed in dpdk (Debian): | |
status: | Unknown → Fix Released |
Hi Patrick,
thanks for your report.
I sounded familiar to me and so it is - we fixed that a while ago in [1].
Also we reworked some of the related code later in [2] and [3] which made my memory a bit mixed there.
So back then I didn't consider code too far back to be affected but your report shows it is.
I checked and I see that Zesty already released 16.11 with the fix.
So there and later things are good.
Back in Xenial we had no dkms modules yet so good as well, only Yakkety in the middle will need an SRU for this.
Flagging bug tasks accordingly.
[1]: https:/ /gerrit. fd.io/r/ gitweb? p=deb_dpdk. git;a=commit; h=1dda674f3ed51 5ca67c4a833fbbd b8d01b0db93a /gerrit. fd.io/r/ gitweb? p=deb_dpdk. git;a=blobdiff; f=debian/ rules;h= 03d6e443cc824b0 75f9132b17a95d9 db3dbfdc08; hp=2b7db7573353 296b314faa3cfb2 e8b64077ab6dd; hb=bc603db83849 5a6149b866fbdf2 413670a0c96f2; hpb=84adab31e2d 11153f8f83eafc4 cc54af5deb7806 /gerrit. fd.io/r/ gitweb? p=deb_dpdk. git;a=blobdiff; f=debian/ rules;h= 9e272aa649aef4c 120a1fb65a9f7c8 522400b5be; hp=03d6e443cc82 4b075f9132b17a9 5d9db3dbfdc08; hb=41d44cf3d641 83ffff0d83a28cc b67b03c56414f; hpb=bc603db8384 95a6149b866fbdf 2413670a0c96f2
[2]: https:/
[3]: https:/