The number and range of supported operating systems are a significant factor in the effort that needs to be invested in CI, packaging and many tests. A compromise must therefore be made that reconciles the needs of as many users as possible with an efficient CI. In the past, the result was determined shortly before the release of a Checkmk version. Since the introduction of Checkmk 2.2.0 we have instead had an OS Support Policy. This provides users with the confidence for the planning of future Checkmk updates and the operating systems supported by these. Users of Ubuntu in particular should read this article.

Up until Checkmk 2.1.0, the determination of which operating systems were supported was an individual decision, based on user surveys and the analysis of download figures. On the one hand, it could be the case that Ubuntu versions that had actually been discontinued (or transferred to ESM) were still supported at the request of customers. On the other hand, enterprise distributions that had been on the market for a long time but would have received updates during the life cycle of the upcoming Checkmk version were dropped.

Defined time frames instead of individual decisions

From the release of version 2.2.0, explicit time frames have replaced the previous practice of making decisions shortly before release. 

A new Checkmk release will only support distributions whose announced end of support by the distributor is at least three months after the release date of the Checkmk major version. 

We take the following support periods into account:

  • Enterprise distributions (RHEL and its derivatives, as well as SLES) are typically supported by the distributor for up to 10 years
    • RHEL: Maintenance Support
    • SLES: LTSS
  • For Community distributions (Ubuntu and Debian), the typical period of 5 years of free community support applies. Paid updates after this period (e.g. Ubuntu's ESM) are explicitly not covered.
    • Ubuntu: LTS
    • Debian: LTS

Distribution versions with less than two years of total support from the distributor will no longer be supported by Checkmk.

Furthermore, we do not want the number of versions per distributor to get out of hand: If there are more than four versions of a distribution to be supported at the same time, we will not support those that run out of support first from the outset or for only a limited period (which will be announced at the time of the Checkmk release). In the case of SLES, for example, this would have meant that from the current 2.2 release we would not have supported version 15 SP1:

illustration showing the Checkmk support cycle of 2.2.

Explanation of the graphic: The red bar '12 SP4' indicates the SUSE version that is no longer supported in Checkmk 2.2, whose end of support falls within the three-month period following the release. Of the green bars of 12 SP5 and 15 SP1 to SP4, 15 SP1 is the one with the shortest remaining term and should therefore no longer have been considered in the release of 2.2.

The discontinuation of very briefly-supported distribution versions mainly affects Ubuntu's semi-annual STS versions (‘Short Term Support’), which only receive updates for nine months. The LTS versions, which are always released in April of an even numbered year, will continue to be fully supported.

No more STS?

No rule without exceptions – or to be more precise – a well-considered transition period. When we presented this policy at the Checkmk conference in June 2023, Checkmk 2.1.0 and 2.2.0 had already been released for Ubuntu 22.10 STS. In view of the not officially supported downgrade of an Ubuntu STS to the previously released LTS, we quickly realized that enforcing the policy would lead to unnecessary hardship for those users who were already using 2.1.0 and 2.2.0 Beta on Ubuntu 22.10, because the only practical solution would have been to back up, reinstall and restore.

Instead of downgrading to 22.04, we are therefore aiming for a soft upgrade: namely 22.10 STS > 23.04 STS > 23.10 STS > 24.04 LTS. And from 24.04 LTS onwards, the affected Ubuntu users will be back in the release and support cycle of the LTS versions, so that we will completely phase out support for STS.

What about hardware support?

A popular argument in favor of Ubuntu STS is its hardware support. After all, Ubuntu 23.10 comes with kernel 6.5, while Ubuntu 22.04 comes with kernel 5.15. The latter was released in October 2021, and therefore support for hardware released in the last two years is rather poor.

Canonical is aware of this problem and therefore since 2016 has been porting the kernels of the STS versions back to the latest LTS a few weeks after STS release. They are then available there as the additional package


are available. Beginning with dot release .2, four months after the first STS following an LTS, Canonical will also provide installation images with the STS kernel. Specifically: Ubuntu 22.04.2 in February 2023 will include the kernel from Ubuntu 22.10, Ubuntu 22.04.3 in August 2023 will include the kernel 6.2 from Ubuntu 23.04, and 22.04.4 will include the kernel 6.5 from 23.10 in February 2024.

Illustration of the ubuntu kernel support circle

Four months following the release of Ubuntu 24.04 LTS, Ubuntu 22.04.5 will then receive its kernel and no further STS kernels will be released. This entire process will then start all over again for Ubuntu 24.04.

If you are dependent on support for the latest hardware, you should therefore always ensure that you use the latest installation images. Should you work with debootstrap or image building tools, make sure to integrate the HWE kernel.

Flexible options for developers

It is perfectly understandable that developers like to use bleeding edge distributions in order to have the latest technologies available promptly and to be able to identify early on which changes could lead to problems in future distribution versions.

However, this does not mean that Checkmk must also be offered for every STS version. Virtualization is the most flexible way to run an LTS operating system as a guest on an STS Linux. If you prefer a more convenient option, you can use our ready-made Docker images.

Convenient update scheduling

Even if planning for the future is now easier, previously in order to update older Checkmk installations, you had to research which Checkmk version was built for which version of an operating system. To simplify this process, we have created update matrices. From these you can see when a Checkmk update should be combined with an operating system update and how updates that affect several OS' or Checkmk versions can be carried out with the least number of steps. Here, for example, is a screenshot of the update matrix for 2.1.0 to 2.2.0 under Ubuntu:

screenshot of the Checkmk update matrix for 2.1.0 to 2.2.0 under Ubuntu

We occasionally receive requests for builds of very old Checkmk versions on quite new versions of operating systems, or vice versa for a relatively new Checkmk in combination with a long-discontinued distribution version. To answer such queries, we have included these diagrams in all the branches contained in our manual. Specifically, this means that you will find all the information you will need to upgrade even a 'somewhere forgotten' Checkmk installation in version 1.5.0 on Ubuntu 14.04 to a current 2.2.0 on Ubuntu 22.04.