06. 05. 2022 Alessandro Valentini Development, NetEye

Pinning a Module to a Specific Kernel Release

During our implementation of the NetEye migration to Red Hat 8 we decided to drop our internal mirror for system packages and instead rely on Red Hat’s official repositories. Our goal was to improve reliability, speed up the delivery of updates, and alleviate the development team’s workload. But it also introduced a new issue: we are no longer in control of which kernel will be installed on NetEye machines, and this may cause compatibility issues with NetEye-related kernel modules, namely npreal2 (used for Moxa serial-to-IP devices) and DRBD.

When a new kernel is installed on NetEye, all incompatible kernel modules are removed and are not loaded after reboot: This may cause a major issue if a cluster node for instance starts up without DRBD.

The solution comes in the form of ‘weak-modules’, described this way by RedHat:

The weak-modules script determines which modules are kABI compatible with installed kernels and sets up the symlinks in /lib/*/weak-updates so that such compatible module can be used by kernels other than the one it was compiled against.

In the case of DRBD:

[root@neteye ~]# locate drbd.ko
/usr/lib/modules/4.18.0-305.25.1.el8_4.x86_64/weak-updates/drbd/drbd.ko
/usr/lib/modules/4.18.0-305.el8.x86_64/extra/drbd/drbd.ko
[root@neteye ~]# ll /usr/lib/modules/4.18.0-305.25.1.el8_4.x86_64/weak-updates/drbd/drbd.ko
... /usr/lib/modules/4.18.0-305.25.1.el8_4.x86_64/weak-updates/drbd/drbd.ko -> /lib/modules/4.18.0-305.el8.x86_64/extra/drbd/drbd.ko

Since RedHat will keep the same kernel release within the same minor version, we can be reasonably confident that our modules will remain compatible within the same minor version. For example, RedHat 8.4, the version currently used in NetEye, will keep kernel 4.18.0-305.* for its entire life while RedHat 8.5 will upgrade to kernel 4.18.0-348.*. This will:

  • prevent the installation of potentially incompatible kernels: for example a kernel 4.18.0-306.* or higher
  • require a compatible kernel to be installed, e.g., 4.18.0-305.*
  • require a module version to be tested with the kernel

Those packages are part of the neteye group and therefore will be automatically installed, protecting users against dangerous kernel switches.

In the case that an incompatible kernel is released, dnf will stop reporting a conflict with the new kernel.

These Solutions are Engineered by Humans

Did you find this article interesting? Are you an “under the hood” kind of person? We’re really big on automation and we’re always looking for people in a similar vein to fill roles like this one as well as other roles here at Würth Phoenix.

Alessandro Valentini

Alessandro Valentini

DevOps Engineer at Wuerth Phoenix
DevOps Engineer at Würth Phoenix

Author

Alessandro Valentini

DevOps Engineer at Würth Phoenix

Leave a Reply

Your email address will not be published. Required fields are marked *

Archive