Which distros boot the Root Lock kernel

Overview: Which Linux distributions Root Lock by HeartSuite currently tests, which kernel line each row uses, and what you still own before production Lockdown. This page follows the live-matrix catalog and the installer floors as of 2026-09-24. The April 2026 v1.6.4 “Validated” table (Fedora 41, Alpine 3.21 as validated, Ubuntu 22.04 omitted) stays retired.

Audience: Procurement, security architects, and platform engineers selecting a base OS.

This matrix complements the workload notes in System Requirements and the buyer-facing deployment guidance in the Enterprise Adoption Guide.

How to read this matrix

Each row assigns a tier that says what HeartSuite has run recently and what you own:

Columns

• Kernel line — Which Root Lock kernel the current installer for that row ships. Debian 12, Debian 13, Ubuntu 24.04, and Ubuntu 26.04 use 6.18 (uname -r is 6.18.9-hs on the fielded pin). Debian 11 and Ubuntu 20.04 use 5.19 only, as lab re-proof of the legacy k5 line. Ubuntu 22.04 is not offered on this installer. You do not pick both lines at install on a given row.
• Boot — How the installer sets the default kernel entry. UEFI Secure Boot for the Root Lock kernel entry remains incomplete. The original distribution kernel (maintenance kernel) keeps its signing status for recovery. On GRUB, including Fedora and Red Hat, an optional boot menu password can be set from Lockdown before the seal (Lockdown).

Source for rows and kernel series: heartsuite/tools/live_matrix/distro_catalog.yaml, plus the installer floors (glibc 2.34, Python 3.11), as of 2026-09-24.

Main compatibility table

Architecture: x86_64 (64-bit) only. No ARM or other ISA builds are offered for the Root Lock kernel.

Installer floors (current 6.18 bundle): glibc 2.34 or newer, and Python 3.11 or newer. A host that misses either floor is not a gold-image trial. Debian 11 and Ubuntu 20.04 stay on the 5.19 installer. There is no compat package that puts the 6.18 helpers on an older userland.

Secure Boot (all distributions): Root Lock kernel UEFI Secure Boot support is incomplete.

Deployments that require Secure Boot for the Root Lock entry may need MOK enrollment during install. Alternatively, boot the Root Lock kernel with Secure Boot disabled while retaining the signed maintenance kernel. Details: Enterprise Adoption Guide → Secure Boot.

Tier definitions

Supported

The distribution is in the current k6 release-core set (Debian 12, Debian 13, Ubuntu 24.04, Ubuntu 26.04). HeartSuite runs install, first boot, and initial setup against it in the live matrix. Lockdown on that set is not a published green sign-off. Your staging Lockdown run is the last gate before fleet rollout.

In lab

The distribution is in the current catalog with a documented caveat (btrfs preflight, not certified, last green date older than the current bundle). Commercial support still applies when install and Lockdown succeed on the customer image.

Experimental

Catalog experimental, or rolling / not certified. Expect extra reboots, boot-loader edge cases, or a missing release sign-off.

Legacy (5.19 only)

Debian 11 and Ubuntu 20.04 use the k5 installer and the 5.19 Root Lock kernel for lab re-proof. The 6.18 bundle is for the current line, and the installer refuses it on these two hosts.

Compatible (customer validation)

Same packaging family as a tested row. HeartSuite has not published results for your exact vendor branding, minor, or gold image. The glibc 2.34 floor and the Python 3.11 floor still apply. RHEL 8, RHEL 9, AlmaLinux 8, and AlmaLinux 9 are not a customer-validation exercise on this installer.

Not supported

Outside current product scope. That includes Ubuntu 22.04 and the EL9 family (Rocky Linux 9, AlmaLinux 9, RHEL 9, CentOS Stream 9), which miss the Python floor, and releases below glibc 2.34 (RHEL 8, AlmaLinux 8, CentOS 7, RHEL 7, CentOS Stream 8, Debian 9, Debian 10, Ubuntu 18.04). Use a distribution this installer accepts, or HJFS on a standard kernel where custom kernels are prohibited.

RPM / RHEL family

The current installer needs glibc 2.34 or newer and Python 3.11 or newer. Rocky Linux 10 and CentOS Stream 10 clear both and stay experimental. Rocky Linux 9, AlmaLinux 9, RHEL 9, and CentOS Stream 9 clear glibc and fail the Python floor, so the installer refuses them. RHEL 8 and AlmaLinux 8 ship glibc 2.28.

SELinux on RHEL-family systems: Root Lock VFS hooks are designed to run before the LSM chain, so SELinux can add restrictions after Root Lock allows an operation and cannot lift a Root Lock denial. A targeted SELinux policy module may still be needed for product paths. If AVC denials appear, use ausearch and audit2allow. Hook-order detail: LSM Comparison → Co-existence. That LSM page is still written against the 5.19.6 measured pack — do not treat it as the 6.18.9-hs LSM list.

Debian and Ubuntu family

Debian 12, Debian 13, Ubuntu 24.04, and Ubuntu 26.04 are the current k6 release-core set and the majority of documentation examples.

On Debian/Ubuntu the installer sets the Root Lock kernel as the GRUB default and reboots when GRUB automation succeeds. The original distribution kernel remains in GRUB as Maintenance and vanilla entries for recovery.

Alpine Linux

On Alpine extlinux the boot menu password is not offered, and Lockdown still works.

SUSE family

Cloud platforms (AWS EC2 Nitro and KVM guests)

Root Lock runs as a guest on AWS EC2 (including Nitro), KVM, VMware, and other cloud hypervisors. Use a distribution from this matrix and the same installer as on local hardware. For nested guests, see Bare metal, virtual machines, and nested VMs.

Before you install on a cloud instance:

• Keep the provider serial console enabled. SSH can drop during the first Root Lock reboot; the console is how you recover if the instance does not come back.
• Run the install once on your target instance type in staging before fleet rollout.
• If the installer stops before reboot, read /var/log/heartsuite/install.log and email support@heartsecsuite.com with the log attached.

Root Lock as a hypervisor host (running VMs from this kernel) is not a supported product role. See Workload fit.

Workload fit (not distro-specific)

Distribution compatibility answers whether Root Lock installs and boots on your base OS. Whether a workload belongs on that host is a separate decision.

On the kernel that ships, the BPF syscall is off by design, so there is no eBPF program to load.

For Docker, containerd, Kubernetes, CRI-O, and Podman, OCI images are built and run off this host, or Root Lock is the guest kernel in a VM the customer provides.

Full exclusion table: System Requirements. Mixed-environment decision tree: Enterprise Adoption Guide → Compatibility.

HJFS alternative

Organizations with a strict no custom or modified kernel policy — certification rules, cloud provider-managed kernels, or vendor OS support contracts that forbid replacing the distribution kernel — should not force the Root Lock kernel onto those images.

HeartSuite Joint File System (HJFS) provides per-program, per-version file isolation and automatic backup on a standard kernel. No kernel replacement is required.

HJFS limits and comparison: HJFS how-it-compares and HJFS limits. Procurement mapping: Enterprise Adoption Guide → Honest limitations.

Reporting issues

If install or Root Lock kernel boot fails on a Supported, In lab, Experimental, Legacy, or Compatible distribution, email support with enough context to reproduce:

Email: support@heartsecsuite.com

Include:

1. /var/log/heartsuite/install.log — installer steps and outcome (see Appendices).
2. Kernel identity: output of uname -r.
   • Current 6.18 stream: expect 6.18.9-hs. The packaging label is 6.18.9-HeartSuite-3 (build #43). uname -r does not contain the word HeartSuite. A distribution version string means the maintenance kernel is running.
   • 5.19 legacy: expect a string such as 5.19.6-HeartSuite-2.0.
   • Maintenance kernel: a distribution version string with no Root Lock packaging (for example a stock debian or el uname).
3. OS identity: contents of /etc/os-release.
4. Root Lock version and whether the failure occurs during install, first Root Lock boot, initial setup, or Lockdown.
5. Boot loader (GRUB vs extlinux) and whether UEFI Secure Boot is enabled.

For non-blocking bugs on supported platforms, open a GitHub issue using the Bug Report template on the public repository. Do not use public issues for security vulnerabilities — email support@heartsecsuite.com for responsible disclosure.

Kernel update recovery if a new Root Lock kernel fails to boot: Updating Root Lock.

Related reading

• Kernel Support Policy — LTS strategy, patch targets, version-string semantics, and notification
• System Requirements — Architecture, kernel lines, and software notes
• Enterprise Adoption Guide — Secure Boot status, fleet operations, procurement decision tree
• LSM Comparison — SELinux co-existence (5.19.6 measured pack)
• Procurement Brief — Hardening posture comparison (6.18.9-hs build #43)
• CVE Hygiene for Scanners — Scanner workflow; do not infer 6.18 compile-out from 5.19 greps
• How Root Lock Compares — What belongs on a separate host
• Deployment Scenarios — Where Root Lock fits
• HJFS documentation — Standard-kernel alternative
• Before You Begin — Prerequisites and cloud vs local install paths

Last updated: 2026-10-02. Rows follow distro_catalog.yaml and the installer floors (glibc 2.34, Python 3.11). Workload Kconfig values are from the 6.18.9-hs #43 packaging config and the published 5.19.6-HeartSuite-1.0 pack. No complete Lockdown M2 release-core gate is claimed for this date.