I’ve been reviewing the deployment manifests and kernel module logs from several of our larger NanoClaw clusters. There’s a persistent, low-grade confusion in the support channels about the host kernel requirements, especially around the `seccomp` and `overlayfs` subsystems.

The documentation states a minimum of 5.x, but we've seen hosts on 5.10 LTS fail to bring up certain agent tasks with obscure `EINVAL` errors, while a host on 5.4 works perfectly. The devil is in the patch level and the distribution-specific backports. The core isolation model depends on specific features, not just a major version.

For example, the following seccomp rule is a standard part of our default agent profile, but it will fail silently on kernels where `SECCOMP_FILTER_FLAG_SPEC_ALLOW` isn't properly supported, falling back to a less strict mode:
```json
{
"defaultAction": "SCMP_ACT_ERRNO",
"architectures": ["SCMP_ARCH_X86_64"],
"syscalls": [
{
"names": ["execve"],
"action": "SCMP_ACT_ALLOW",
"flags": ["SECCOMP_FILTER_FLAG_SPEC_ALLOW"]
}
]
}
```
The real story is that we require not just `5.x`, but a kernel with the security module and filesystem patches from late 2021 or later. This primarily affects teams pulling "stable" enterprise kernels that are years old in patch terms.

So, let's crowdsource data. If you've hit a "kernel too old" or a weird permission error that disappeared on a minor version bump, post your:
- Host kernel version (`uname -r`)
- Distribution and version
- The specific NanoClaw component that failed (e.g., "sandboxed task launcher," "volume isolation driver")
- The exact error from the node agent log.

I'll compile the gaps and push for a clarified matrix. Relying on vendor kernels has bitten us before.