Cilium 1.20 requires BTF kernel support, breaking default Raspberry Pi OS installs

Cilium 1.20.0 requires BPF Type Format (BTF) support in the Linux kernel, and because the default Raspberry Pi OS kernel is built without it, the release cannot run on stock Pi systems. That is the core of a write-up on dev.to, which traces the incompatibility to deliberate engineering choices on both sides and warns that it blocks a common deployment pattern for edge and hobby clusters.

Why Cilium depends on BTF

BTF is a kernel's compact self-description: a record of the data types and symbols present in a particular build. eBPF programs use it to read kernel structures correctly no matter which kernel they encounter, instead of relying on offsets compiled for one specific version. Cilium's entire datapath, including policy enforcement, load balancing and traffic handling, is built on eBPF, so it leans on BTF to resolve symbols and inspect kernel state at load time. According to the dev.to analysis, when that metadata is absent, Cilium's programs cannot compile or run correctly: the agent fails during initialization or errors out at runtime.

Why Raspberry Pi OS leaves it out

The omission is intentional rather than an oversight. As the post explains, Raspberry Pi OS prioritizes a small kernel image and a low memory footprint, a sensible default for hardware that typically carries between 1 and 8 GB of RAM. Turning on the kernel build option that exposes BTF would increase both, so the distribution ships without it. That trade-off is invisible to most Pi users and disqualifying for software that assumes BTF is present.

What actually breaks

The failure is total rather than degraded. The article lays out the causal chain: with no BTF, Cilium's eBPF toolchain cannot resolve kernel symbols or access data structures; its programs then fail to build and verify; and the agent cannot start. Anyone running Kubernetes on Raspberry Pi hardware, with home labs, edge clusters and IoT prototypes cited as the typical cases, hits this the moment they upgrade to 1.20.0 on a stock kernel. The options the post frames are unattractive: stay on an older Cilium release and miss whatever the new version delivers, or move to a different networking stack entirely.

The fixes on the table

In the short term, the write-up points to manually enabling BTF or deploying custom kernel builds. It also rates these unsustainable: they demand specialized knowledge, must be repeated for every kernel update, and carry a risk of instability.

The longer-term remedies it proposes are upstream ones. Raspberry Pi OS could enable BTF by default and accept the size and memory cost. Cilium could reduce its reliance on BTF, though the post notes this may involve performance trade-offs. In the meantime, community-maintained patches could add the missing support without official backing from either project.

Why it matters

Cheap ARM boards are a genuinely popular substrate for edge Kubernetes, and a hard incompatibility between a major networking release and the most common Pi distribution forces operators to choose between their hardware and their upgrade path. The episode also illustrates a wider tension in the ecosystem: kernel builders for constrained devices trim features that cloud-native tooling increasingly treats as table stakes, and BTF now sits firmly in that category. Distributions that ship without it will keep getting locked out of modern eBPF-based software until one side or the other moves.

One caveat worth flagging: this account rests on a single community write-up rather than an official statement from the Cilium or Raspberry Pi projects, so affected operators should verify the requirement against Cilium's own release documentation and their kernel configuration before planning around it.