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).
5.11.5-lqx2.0.fc33
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).
iptables
nftables
firewalld
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).
kernel-lqx
cgroupsv2
docker run -it --rm jess/stress --cpu 100
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.
cgroups
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.
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.
libvirtd
lqx
Permissive
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.
CONFIG_VIRT_CPU_ACCOUNTING_GEN
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
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
Login to comment on this ticket.