DRBD Kernel Module Compatibility

When compiling DRBD® from source code, for example, when installing the drbd-dkms package, compiling might sometimes fail with an error message similar to this:

  ERROR: no (suitable) spatch found in $PATH.
  INFO: spatch failed, or no suitable spatch found; trying spatch-as-a-service;
  be patient, may take up to 10 minutes.
  If it is in the server side cache it might only take a second.
  SPAAS    0123456789abcdef0123456789abcdef

This article will provide background about how LINBIT® developers build the DRBD kernel module for compatibility with different Linux kernels, why there sometimes might be problems with building for kernels on certain systems, and what you can do to try to resolve problems.

Background about DRBD kernel module compatibility

The LINBIT development team tries hard to build the DRBD kernel module so that it is compatible with a wide range of kernels. For this, LINBIT developers use a compatibility layer. This compatibility layer consists of several stages, among them:

Compatibility tests, to select which specific compatibility changes are necessary for the particular kernel
Compatibility patches to apply those changes

DRBD compatibility patches are not just “regular” patches, but “semantic patches”. These semantic patches use the spatch command from the Coccinelle project.

Providing compatibility patches for building the DRBD kernel module

Processing the semantic patches into actual patches that can then be applied to the source files can be a time-consuming process. Coccinelle is a beast, and for some of our semantic patches you need a sufficiently recent version of Coccinelle which is not readily available on all platforms.

For this reason, DRBD maintainers precompute the actual patches from the semantic patches for many “widely used” vendor kernels, and bundle those together with the actual source code provided, such as in the tar archive files or the drbd-dkms package.

If kernels released after generating the source bundles remain binary, or at least semantically, compatible, that works nicely. However, there is no way to anticipate if later released kernels will need a different set of compatibility changes, when bundling the source code packages. In that case, during the build-from-source stage, there needs to be an spatch run translating the semantic patches into actual patches.

That spatch needs to be sufficiently recent. Based on experience, on the “DEB side” of the world, Coccinelle 1.2 is OK, and 1.3 might be slightly faster, but 1.1 is not good enough. On the “RPM side” of the world, it turns out that the 1.1.1 version in some sub-release is sufficiently recent.

The LINBIT Spatch-as-a-Service

For environments that are unable to get a suitable spatch running, LINBIT even provides an “spatch-as-a-service” (SPAAS), where the build process can upload the compat.h header file, as generated from our compatibility tests, to some web service that has a working spatch running, and will fetch a suitable patch from cache, or generate it if necessary.

For that to work, you obviously need to be able to reach that service. Check if you can reach it by entering the following command:

curl https://spaas.drbd.io/api/v1/hello

If there is no bundled precompiled compatibility patch for your kernel, and you can neither install a working spatch, nor have those nodes connect to our SPAAS, then you cannot compile the DRBD kernel module from source code on that node.

That’s how it is.

Conclusion

If you are having difficulty compiling the DRBD kernel module on your node, try the following:

Install a suitable spatch (see above)
Arrange for the LINBIT SPAAS to be reachable for the nodes to compile the DRBD kernel module for.
Use another host where you can do one of the above to generate the kernel module, and then transfer it to the actual nodes.

Written by: LE, 2025-03-28.

Reviewed by: MAT, 2025-04-01.