#4 iptables issue on f33
Opened 3 years ago by spacewanderer. Modified 2 years ago

first off, thanks for bringing liquorix to fedora!

I have installed 5.11.5-lqx2.0.fc33, rebooted and since then docker fails to start and the reason it states is it can't setup iptables.
same thing works under standard latest fedora kernel (some 5.10-ish).

Mar 11 23:03:38 surtur dockerd[10550]: failed to start daemon: Error initializing network controller: error obtaining controller instance: failed to create NAT chain DOCKER: COMMAND_FAILED: '/usr/sbin/iptables -t nat -N DOCKER' failed: iptables v1.8.5 (legacy): can't initialize iptables table `nat': Bad address
Mar 11 23:03:38 surtur dockerd[10550]: Perhaps iptables or your kernel needs to be upgraded.

While it might be unrelated, I have found this comment stating this issue (failing iptables) have been fixed for that person by recompiling the kernel. could be liquorix be missing something docker needs? perhaps some flag in the config?
I have come to this conclusion (and still could be wrong) only because docker did run before and could manipulate iptables just fine on fedora kernel and the only thing that changed before it stopped working was the kernel (checked again that it works when I reboot to fedora kernel).

please tell me if I can do anything to help diagnose this properly, I haven't really done any proper kernel debugging before.


Alright, I was able to run docker with iptables disabled (had to create nftables rules mimicking whatever docker was trying to set up via iptables for it) and switching firewalld back to nftables (that's the default since a couple of years back).

There is one new issue, though.
kernel-lqx doesn't seem to have full cgroupsv2 support.
The same cgroupsv2 cpu and memory limits that work with the standard kernel don't work here with kernel-lqx (such as docker run -it --rm jess/stress --cpu 100 actually uses up all of the cpu, where it should be limited, because it's ran via a systemd slice that is imposing limits).

Docker itself starts but prints this:

Mar 12 11:06:59 surtur dockerd[31837]: time="2021-03-12T11:06:59.212115222+01:00" level=warning msg="Unable to find blkio cgroup in mounts"

So to recap, while the iptables issue has been worked around (kind of), there's now the issue with the apparent lack of proper cgroupsv2 support.
Should I open a separate issue for it?

My guess would be some stark incompatibility between those programs with their SELinux "profiles". The current workaround regarding the iptables situation is to set SELinux on Permissive. I don't know why, but this might be the reason 5.11 took this long to be released on Fedora 33

And as for configs, the things regarding iptables and cgroups are matching those on Fedora's default kernel config. So I don't really know. Might be something with the Zen/Liquorix patches, though.

My guess would be some stark incompatibility between those programs with their SELinux "profiles". The current workaround regarding the iptables situation is to set SELinux on Permissive. I don't know why, but this might be the reason 5.11 took this long to be released on Fedora 33

And as for configs, the things regarding iptables and cgroups are matching those on Fedora's default kernel config. So I don't really know. Might be something with the Zen/Liquorix patches, though.

ad programs having issues:
That's the funny thing - I have been running them just fine with SELinux set to Enforcing (took some fiddling) fine.

iptables

One other thing seems to be affected by the iptables to nftables switch, though --> libvirtd, which makes me think it'd actually be great if lqx would just work the way stock kernel does (with iptables) without those weird issues...I'll see what Permissive does for me there.

cgroupsv2

But as for the cgroup-based cpu limits, it might be as you're saying - some stark incompatibilities.
I've tried to edit the stock fedora kernel config (still fails to compile) and once I enable certain goodies that lqx is using it won't allow CONFIG_VIRT_CPU_ACCOUNTING_GEN option to be set, which is apparently responsible for what I need for the above mentioned cgroup-based resource limits enforcing.

just for the record, the subject systemd slice (for moby/docker) looks like this

# /etc/systemd/system/moby-engine.slice
[Unit]
Description=Slice that limits dockerd resources
Before=slices.target
# refs:
#  https://baykara.medium.com/docker-resource-management-via-cgroups-and-systemd-633b093a835c
#  https://docs.docker.com/engine/reference/commandline/dockerd/#docker-runtime-execution-options

[Slice]
CPUAccounting=true
CPUQuota=85%
MemoryAccounting=true
MemoryHigh=10G
MemoryMax=12G
MemoryMaxSwap=3G

It's called "CPUAccounting" there in the slice config, I think it's related that lqx has it unset and thus this limit enforcing simply doesn't work under lqx.

Interesting. Might fiddle around the config a bit to get more insight at the situation here

Interesting. Might fiddle around the config a bit to get more insight at the situation here

That's great, thanks!
Happy to test the resulting builds. :))

Interesting. Might fiddle around the config a bit to get more insight at the situation here

That's great, thanks!
Happy to test the resulting builds. :))

I'm sorry I haven't been able to work on this issue due to the stuff I had to get done with. Did the problem solve itself along with the regular updates I pushed or is it still there blocking your use case? If it's been solved please consider closing down this issue, but if it's still there please try to use this other mod and see if it works for you as I'll try fixing it

Thank you

Metadata Update from @rmnscnce:
- Issue assigned to rmnscnce

2 years ago

Login to comment on this ticket.

Metadata