2

I have a fresh RHEL7.4 Server installation on which I'm trying to install DRBD 9.0 from elrepo.

My server is running the latest kernel: 3.10.0-693.1.1.el7.x86_64, yet kmod-drbd90 wants to install kernel 3.10.0-514.26.2 as a dependency:

---> Package kmod-drbd90.x86_64 0:9.0.8-1.el7.elrepo will be installed
--> Processing Dependency: kernel(crypto_alloc_ahash) = 0x035deac4 for 
package: kmod-drbd90-9.0.8-1.el7.elrepo.x86_64
--> Running transaction check
---> Package kernel.x86_64 0:3.10.0-514.26.2.el7 will be installed

I don't have a problem with installing the older kernel. I'm just wondering what's going to happen when that older kernel eventually gets replaced. Will DRBD continue to work?

I get the same thing if I try to install DRBD 8.4 as well.

keyboard_banger
  • 23
  • 5

1 Answers1

3

This is an issue that I've sometimes had with DRDB and several other products that involve specialized kernel modules. Ultimately, my solution to this problem has always ended with me putting a hold on the kernel package to prevent unexpected breakage. Your mileage will vary based on how the distribution in question packages the kernel.

In general, this is an example of dependency resolution doing its job, and you should do what it says. However, DRDB's occasional dependency on slightly older kernels does not necessarily prevent newer kernels from being installed and Grub being automatically configured to boot from those newer kernels. This results in a system that needs an older kernel selected via Grub on boot - which you can easily do if your system is configured to keep older kernels after updates, which is the default. Try to avoid this.

So if you're going to use DRDB on this node, it's a solid approach to hold the kernel package to prevent this from happening. That can be done by editing /etc/yum.conf to include the following line under the [main] section:

exclude=kernel*

This will prevent the kernel from being updated until you force an update of that package using yum, or until you remove the exclude directive. This way you can be more careful about updating the kernel in kernel sensitive workloads.

Spooler
  • 7,046
  • 18
  • 29
  • Is this a common problem on RHEL using DRBD? How would you deal with security updates for the kernel in this scenario? – gxx Aug 23 '17 at 22:26
  • This is a common problem across multiple distributions, but not explicitly and only RHEL. In order to handle this situation, I would want to use a lifecycle manager for my RHEL machines in order to better orchestrate their updates. A product such as Foreman comes to mind first, and is a solid solution to this kind of manageability issue in general. Without such a lifecycle manager, you will need to regularly patch these servers while paying extra attention to the kernel version installed. – Spooler Aug 24 '17 at 00:01
  • 1
    Alright, thanks. At least with Debian, in the last ~ ten years since using DRBD, I didn't run into this problem. – gxx Aug 24 '17 at 00:03
  • Hmmm, thanks for the info. I think I may go back to installing DRBD from source and recompiling after every kernel update. I did that for years before I discovered the rpms at elrepo. – keyboard_banger Aug 24 '17 at 02:11
  • 1
    DRBD is a kernel module in RHEL, so kernel symbols need to be updated by LINBIT on new releases of the kernel. DRBD _does_ leverage kABI (kernel Application Binary Interface), which adds a bit of a fudge factor between kernel module and kernel versions, but there is a limit to this magic. For the most part, you want the closest DRBD module version to your kernel without going over. DRBD is in the mainline Linux kernel; RH chooses to remove it because "it wasn't invented there", while most other distros leave it in there (cause really, why remove it) avoiding the problem completely. – Matt Kereczman Aug 25 '17 at 14:40
  • Thanks for the answer. I've faced similar issue with VDO after kernel update it just did not want to work. I've ended up rebuilding it from scratch. – Stuka Feb 14 '20 at 17:20