Skip to content

Enabling nf_tables kernel module on updated snowflake-staging-01

Steps to reproduce

lsmod|grep nf_tables is an empty list.

What is the current bug behavior?

nf_tables is not loaded by default, and unprivileged user namespace root user could not insert kernel module as they are not root from kernel's point of view.

As a result, user mode kubernetes could not start as kube-proxy quit with the following errors:

Sep 01 14:56:15 snowflake-staging-01 k3s[967514]: E0901 14:56:15.239030      32 proxier.go:732] "Error cleaning up nftables rules" err=<
Sep 01 14:56:15 snowflake-staging-01 k3s[967514]:         could not run nftables command: /dev/stdin:1:1-24: Error: Could not process rule: Operation not supported
Sep 01 14:56:15 snowflake-staging-01 k3s[967514]:         add table ip kube-proxy
Sep 01 14:56:15 snowflake-staging-01 k3s[967514]:         ^^^^^^^^^^^^^^^^^^^^^^^^
Sep 01 14:56:15 snowflake-staging-01 k3s[967514]:  >

........


Sep 01 14:56:15 snowflake-staging-01 k3s[967514]: E0901 14:56:15.619447      32 server.go:136] "Error running ProxyServer" err="iptables is not available on this host"
Sep 01 14:56:15 snowflake-staging-01 k3s[967514]: Error: iptables is not available on this host

What is the expected correct behavior?

lsmod should show nf_tables is loaded

lsmod|grep tab
nf_tables             303104  0

user mode k3s should start without incident

systemctl restart --user k3s-rootless.service

(wait a few seconds)

journalctl --user -xeu k3s-rootless.service

When did this start?

Since a week ago; maybe after the debian version upgrade.

Relevant logs and/or screenshots

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information