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:
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.