Builtin modules support #430
Comments
Closed
|
I just tripped over this on a linode instance with firewalld-0.6.3-1.fc29.noarch. /usr/lib/python3.7/site-packages/firewall/core/modules.py - module::load_module calls modprobe. modprobe should return true if the module is built-in. However, modprobe apparently checks for builtins by consulting /lib/modules/$(uname -r)/modules.builtin. This file is not present on my hosted system, so it fails. To WAR this scenario, we can check for the existence of /sys/module/module_name. This will exist if the module is loaded or builtin (and sysfs is mounted). My python-foo is weak, or I would submit a patch. If someone wants to tackle this, it needs to check for the existence of /sys/module/module_name (and return success if it exists) prior to attempting to call modprobe. This an optimization, not just a WAR ;-) The possible hazard I see is that there is also extensive use of /proc/modules. /proc/modules on lists loadable modules, not built-ins, so there some risk of mismatch by using difference sources. Ie, while any module represented in sysfs can be considered loaded for most purposes, we should be sure to only attempt to unload modules that are listed in /proc/modules. |
|
I just came across this on my Linode server as well. Is there a fix/workaround? |
|
@mohd-akram A generic workaround is to populate /lib/modules/$(uname -r)/modules.builtin yourself by listing all modules represented in /sys/modules that do not have an associated module file (or link). This will work around the problem for any module that may be used by firewalld. An alternative - how I am avoiding this problem - is to switch to the distro kernel instead of the minimalist kernel linode provides as a default. |
|
Thanks, I went for option B. |
|
Sounds like this is better solved in the distro itself. I'd rather not add workarounds in firewalld to suit a distro that ships broken tools (i.e. modprobe). @that-schamp mentioned a manual workaround above. |
|
Make sense. Unfortunately I can't go with alternative suggestion of @that-schamp. mkdir /lib/modules/$(uname -r)
touch /lib/modules/$(uname -r)/modules.{builtin,order}
for i in /sys/module/*; do echo kernel/${i##**/}.ko; done >> /lib/modules/$(uname -r)/modules.builtin
depmod -a |
erig0
added a commit
that referenced
this issue
Oct 30, 2019
There are many cases in which module loading may fail: - builtin modules, but corrupt/missing modules.builtin database - CONFIG_MODULES=n - inside unprivileged container Unfortunately, we have no way to detect these scenarios. The only thing we can do is attempt to load the module and hope for the best. Fixes: #430 Fixes: #519
erig0
added a commit
to erig0/firewalld
that referenced
this issue
Nov 7, 2019
There are many cases in which module loading may fail: - builtin modules, but corrupt/missing modules.builtin database - CONFIG_MODULES=n - inside unprivileged container Unfortunately, we have no way to detect these scenarios. The only thing we can do is attempt to load the module and hope for the best. Fixes: firewalld#430 Fixes: firewalld#519 (cherry picked from commit 88e76dd)
erig0
added a commit
that referenced
this issue
Nov 8, 2019
There are many cases in which module loading may fail: - builtin modules, but corrupt/missing modules.builtin database - CONFIG_MODULES=n - inside unprivileged container Unfortunately, we have no way to detect these scenarios. The only thing we can do is attempt to load the module and hope for the best. Fixes: #430 Fixes: #519 (cherry picked from commit 88e76dd)
|
Removing "won't fix" tag. It was left by mistake. This issue was fixed in commit 88e76dd. |
Hi, I've tried to get this to work in WSL, but no luck. Does anyone have any idea how to get this to work on Ubuntu 20.04 w/ WSL2? Someone suggested listing the module name in When I try to enable the |
This looks like you're missing kernel support for connection tracking helpers. Make sure your kernel has |
|
Thanks a lot, you're right, that module is actually not set, I'll try to rebuild the WSL kernel with that added and see where it goes :) |
|
Thanks again for the tip. Unfortunately, it doesn't seem to resolve the issue. Any other suggestions? :) |
|
Hmm, after like half day of messing around, I've actually managed to rebuild the WSL kernel with modules, and start my WSL instance with the relevant modules present. So now it looks something like this: But the issue persists... :\ |
|
Ok, so now that I've finally started firewalld in debug: Here's the error log: |
|
Oh boy, I can't believe it, but I think I made it work. I did a Hyper-V install of 20.04 as well with the server ISO, and it works just fine, so now I installed all packages present on the Hyper-V instance. Then I recompiled the WSL kernel to have all the modules that the stock Hyper-V VM has. And now it works. Now I "only" need to figure out exactly which modules and packages are missing that cause this break. Will report back later. |
|
Sooo after another several hours of messing around:
Soooo TLDR all I needed was: Thanks a lot @erig0 for pointing me in the right direction, I really appreciate it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello,
Firewalld refuse to start when nf_conntrack modules are builtin inside the kernel.
Would be nice to only fails when a kernel feature is missing and cannot be loaded.
Regards,
Reference: Using firewalld with custom kernels
The text was updated successfully, but these errors were encountered: