Strategies for managing supported kernel versions

[jamyles]

We're an RHEL shop and have run into issues with both RHEL 6 and 7 and kernel versions not supported by Veeam. First it was with RHEL 7.5 and Agent 2.0.0 and now it's with RHEL 6 and kernel 2.6.32-754.6.3 and later (KB2786). This is making it tricky to stay in supported configurations. We've built two physical machines (one RHEL 6, one RHEL 7) just to do Veeam/kernel testing as a part of our regular patching schedule.

How are folks blacklisting/whitelisting kernel versions on RHEL? We can manually update to a supported (and also tested by us) kernel version and then add a kernel-* blacklist to prevent it from ever updating but in some cases it seems like there's been just one incompatible kernel version and we'd be okay with later versions. Or do we blacklist specific kernel versions, hoping that we can fully test all the versions before we release them in our patch cycle? We're trying to set up something robust but don't want to reinvent the wheel if somebody else has come up with a clever solution or process.

[PTide]

Hi,

I am not sure if I got you right, and if it's even possible to blacklist a specific kernel version, but here is what you could do:

1. Run a script in cron that constantly monitors grubenv and does not let problematic kernel to be loaded by default (probably won't work if you use kexec or ksplice though)

2. Use 'exclude' parameter in /etc/yum.conf

Example:

On CentOS 7 (3.10.0-862.6.3.el7.x86_64) I get this:

Code: Select all

[root@localhost ~]# yum update kernel
Loaded plugins: fastestmirror, versionlock
Loading mirror speeds from cached hostfile
<...LINES SKIPPED...>
updates                                                                                       | 3.4 kB  00:00:00
Resolving Dependencies
--> Running transaction check
---> Package kernel.x86_64 0:3.10.0-862.14.4.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

=====================================================================================================================
 Package                 Arch                    Version                              Repository                Size
=====================================================================================================================
Installing:
 kernel                  x86_64                  3.10.0-862.14.4.el7                  updates                   46 M

<...>

However, if I add in /etc/yum.conf:

Code: Select all

exclude=kernel-3.10.0-862.14.4*

I get this:

Code: Select all

<...>
=====================================================================================================================
 Package                 Arch                    Version                              Repository                Size
=====================================================================================================================
Installing:
 kernel                  x86_64                  3.10.0-862.11.6.el7                  updates                   46 M

<...>

Thanks!

[jamyles]

We did refine our process somewhat but it still involves manual testing on a RHEL 6 and RHEL 7 machine as a part of our normal patch cycle. For actual management of versions, we're using yum-plugin-versionlock and then managing the configuration (/etc/yum/pluginconf.d/versionlock.conf and /etc/yum/pluginconf.d/versionlock.list) centrally with Red Hat Satellite. I can provide more details if anyone is interested.

I'm really hoping Veeam is able to do better QA in the future to make this unnecessary. I'm sure they can get access to RHEL beta channels and test kernel compatibility and update Veeam Agent packages as necessary.

[PTide]

It seems that betas of some security patches were intended for their internal testing only, but we are already working towards getting the earliest access to any upcoming RH patches and fixes.

UPDATE: https://access.redhat.com/solutions/3658111

Thanks!

[solarjdp69]

I'm relatively new to Veeam Agent for Linux. I started installing it in late October. We use Centos 6.10.
The 2.6.32-754.6.3 kernel caused my servers to lock up, but the newest kernel works 2.6.32-754.9.1 perfectly for backups and I have created quite a few test drives using the Veeam recovery ISO. I recently used it to backup 4 servers whose OS drives were old old (8.7 years) and succesfully created and replaced the drives in those servers. They have been operating over a week now. I also have used it to create backups of other critical servers and have created and tested several of those too and they work fine. Go Veeam!!!

[PTide]

Hi John,

8.7 years..that's really a lot for a drive! Thank you for your feedback, much appreciated!