Systemd eBPF tools force per-kernel packaging on NixOS

Systemd has begun shipping eBPF programs for components such as nsresourced, mountfsd, and networkd helpers. Because those programs observe internal kernel data structures that carry no stable ABI promise, a build is only valid for a kernel whose type information matches the one used at compile time. On NixOS that pushes systemd into the per-kernel package set alongside drivers like ZFS and NVIDIA, with every dependent package either inheriting the coupling or switching to a lighter systemdLibs variant.

The new eBPF code underpins unprivileged systemd-nspawn, UID delegation, policy-based mounting of dm-verity images, and execution restrictions. eBPF Compile Once, Run Everywhere proved insufficient as a generic escape hatch, so the build needs a matching vmlinux.h derived from the target kernel’s BTF. Mismatched layouts risk undefined behavior at load time.

RaitoBezarius, who raised the issue on the NixOS Discourse, noted that other distributions have already chosen painful workarounds. One proposed mitigation is to convince systemd upstream to load BPF objects from external files at runtime rather than embedding them in binary .rodata; a single systemd build could then pick per-kernel object packages. Upstream is receptive because the same split would help with eBPF code signing, which the Linux kernel recently merged.

Until that lands, NixOS must treat full systemd as kernel-bound. Client-server communication remains more critical than probe loading after a generation switch, so a failed eBPF load need not brick the system, but the packaging edge remains. Some contributors already list the growing eBPF dependency as a reason to disable the feature at kernel build time.