Answer
No. AlmaLinux does not provide a native live-patch payload service for kpatch.
AlmaLinux ships kernels with CONFIG_LIVEPATCH enabled and provides the kpatch user-space utilities in its standard repositories. The distribution does not include Red Hat’s proprietary kpatch live-patch payload service nor an equivalent community feed that mirrors the RHEL subscription model for live patches.
Confirmed facts
- AlmaLinux is a rebuild of RHEL sources. The kpatch framework components are present.
- The live-patch payload creation and distribution service is proprietary to Red Hat and is not part of AlmaLinux.
- No default, integrated payload repository is enabled out of the box on AlmaLinux systems.
Likely explanation
The gap you describe is expected. The framework allows loading signed live-patch modules, but without a payload source administrators must supply patches themselves or use a third-party provider. Mixing payloads from unrelated sources can cause kernel incompatibilities.
Verification steps for this case
- Check installed kpatch tools:
rpm -qa | grep kpatch
Expect packages such as kpatch and kpatch-tools. Absence of a kpatch-service or payload package confirms no service.
- Check for a live-patch repository or subscription entry:
ls /etc/yum.repos.d/*livepatch* 2>/dev/null || echo "none"
subscription-manager repos 2>/dev/null || echo "subscription-manager not present"
No livepatch repo files and no subscription manager entries is consistent with no native service.
- Confirm kernel livepatch support:
grep -q CONFIG_LIVEPATCH=y /boot/config-$(uname -r) && echo "livepatch enabled" || echo "not enabled"
Sourcing and verifying payloads
If zero-downtime patching is required on AlmaLinux, the practical options are:
- Use a third-party live-patch provider compatible with the running AlmaLinux kernel, e.g., KernelCare or TuxCare. Verify kernel ABI match, signature verification, and support lifecycle before production use.
- Run a RHEL subscription system for the same kernel stream to obtain official kpatch payloads, then evaluate compatibility risk if applied to AlmaLinux. This is generally not supported.
- Build and sign your own kpatch modules from kernel source. This requires maintaining a build pipeline and rigorous staging tests.
Verification best practice: confirm payload is signed for your exact uname -r, test in a staging environment that mirrors production, and keep rollback plans.
One missing diagnostic detail that changes the recommendation: which AlmaLinux major version and kernel release are you running, e.g., AlmaLinux 9 with kernel 5.14.x? Third-party provider compatibility and available kpatch tool versions depend on this.
Note: This is based on established distribution policy. Current verification is recommended as offerings can change.